Arduino analoge(!) modelbaan sturing

[Timo]

Werkt mijn gedachten kronkel dan zet ik de nummers om in namen, ik zie door de bomen het bos niet meer door alle tekst,de code word voller en voller met tekst.
voor mij is het makkelijker om in de code zo min mogelijk tekst te gebruiken als ik in de code  digitalWrite (28,1)  zet weet ik meteen wat er gebeurd als ik digitalWrite (Sein1Pin,Bezet) raak ik op een gegeven moment  het overzicht kwijt  ( Dyslexie ,leesblind) vandaar.

Okay, vandaar. Ook al is het denk ik ook een vorm van gewenning. Mijn vriendin is ook zo dyslectisch als een deur maar variabele namen vindt ze duidelijker dan nummer. Wat enorm kan helpen is geen namen kiezen die op elkaar lijken. (volgendeWisselInvoer en volgendeWisselUitvoer is dan niet handig  )

Het klopt wat Timo schrijft , alleen zou ik geen pro mini's gebruiken deze processor boardjes hebben geen usb aansluiting, je zult een usb-adapter erbij moeten kopen, ik gebruik zelf de Arduino nano (deze is niet veel duurder dan een pro mini), dit boardje heeft iets meer i/o 8 Analog in (pro mini 6)  en 13 digital out/in en heeft standaard een usb aansluiting.

Ze schelen nog steeds een factor 2 hoor  Voor testen ben ik het wel met je eens dat de Nano dan erg gemakkelijk is. Maar als iets vorm gekregen heeft kan je ook een Pro Mini pakken. Eigenlijk hebben zo'n beetje alle Pro Mini's alle aansluitingen van een Nano. Alleen A6 en A7 wil nog wel eens ontbreken. (Waarbij je op moet letten, A7 is analoog in only)) En het feit dat de Pro Mini kleiner is kan in een permanente opstelling vaak een net iets compactere print opleveren Dus ik gebruik ze lekker door elkaar.

De relais boardjes zijn er in verschillend uitvoeringen als shield met 4 relais , of als 1,2,4,8,16 voudige  uitvoering en daar zijn ook nog verschillende uitvoeringen van "actief hoog" of  "actief laag"  gestuurd, het verschil zit in de schakeltrap met of zonder Optocoupler.

Naar mijn idee zijn de boardjes met opto coupler redelijk zinloos. Tenzij je echt een reden hebt om het relais los te voeden is die met transistor net zo makkelijk.

Een andere manier is het gebruik van solid-state relais, heb daar nog geen ervaring mee.

Die zijn zo goed als nutteloos op de modelbaan omdat ze alleen geschikt zijn voor AC.

Ik ben nog bezig met een keerlus schakeling voor mijn baan ,daarvoor ga ik twee bi-polaire relais gebruiken, in dat geval kost dat vier uitgangen van de Arduino en moet het geheel op een shield of losse print gebouwd worden.

Is dat voor de Arduino gestuurde baan? En waarom wil je met twee relais werken? En waarom bi-stabiel? Misschien heb je er een goeie reden voor hoor  Maar ik mis het, zeker in het licht van de Arduino baan, nog even.

Je kunt ook de Rx/Tx van de Arduino gebruiken om met verschillende Arduino's te communiceren Rx Arduino 1 op Tx arduino 2 en Tx Arduino 1 op Rx Arduino 2, in dat geval kun je beter de AT Mega 2650 gebruiken deze heeft vier hardwarematige RX/TX poorten waardoor het makkelijker is om Arduino's te koppelen.

Om alleen daarvoor de Mega te gebruiken is misschien wat overkill. Op 1 serial bus kunnen makkelijk meerdere arduino's hangen. Als je alleen één master hebt die naar meerdere slaves moet zenden knoop je simpelweg alle RX van de slaves aan de TX van de master. Wil je ook terug kunnen sturen dan een pull up weerstand aan de RX van de master. En elke slave via een diode verbinden (kathode naar slave). Maar ook dit is vooral voor korte afstand.

Wat de I²C betreft, kun je zonder problemen 1 a 2 mtr. kabel tussen de units gebruiken UTP kabel dan werk het nog goed, deze informatie heb ik van het internet gehaald via Youtube, daar staat een filmpje van deze oplossing. Ben allen de link naar het filmpje kwijt.

I2C lengte is sterk afhankelijk van de kabel en de pull ups die gebruikt worden. 1 a 2 meter zou ik echt als max zien. Eigenlijk zou ik zelf onder de modelspoorbaan (= storinggevoelige omgeving) niet verder gaan dan 1 meter.

Andere te gebruiken optie is nog SPI. Stuk sneller dan de I2C maar again, voor korte afstanden. Met wat lengte blijft RS485 in mijn ogen de meest robuuste oplossing en makkelijk en goedkoop te implementeren.


Timo

[Te 2/2]

SLX852, daaraan hangt inderdaad een ander prijskaartje.

Maar om nog even in te breken op dit draadje. Paul is bezig om de methoden uit te testen die in- en uitvoer regelen. Ik zelf denk vooralsnog meer op abstract niveau.

Een treinbaan bestaat in mijn droom uit blokken.  En een blok is een tamelijk abstracte struct, noem het class. Een blok heeft eigenschappen en methoden, en een groot aantal afgeleide structuren, speciale blokken: eenrichtingsverkeer-blok, tweerichtingsverkeer-blok
wisselstraat, dubbele wisselstraat, wisselstraatrijweg, lokparkeerplaats, kopmaak-blok, ontkoppelplaats-blok, overweg-blok, schaduwstation-blokken.
In C zou je dan een struct maken, en structs nesten, in C++ zou je een class maken met afgeleide classes. Dat zou er zo uit kunnen zien, in pseudotaal:

struct(class) blok {
eigenschappen:
rijrichting (links of rechts)
rijrichtingafhankelijke stopplaats (links of rechts),
start/stop toestand
melder(reedcontact) per rijrichting,
seinbeeld (toestand)
verwijzing naar vorige,volgende blok

methoden:
rijden-stoppen
melding geven of negeren
melding volgende,melding vorige
}

En in mijn geval komt er dan nog iets bij voor railtype (2 of 3 rail). En ik zou dan geen reedcontact gebruiken maar een lichtsluis met twee pulsen (begin en eind), whatever.

Als ik nu ga kijken naar dit draadje, dan zouden de eigenschappen worden opgeslagen in flashmemory (in plaats van nu bij mij in bistabiele relais), de meldingen worden afgegeven aan de arduino, en de concrete acties (rijden-stoppen, seinbeelden, ontkoppelen, rijrichting wijzigen, wissels omgooien e.d.) zouden worden uitgevoerd vanuit monostabiele relais, aangestuurd vanuit de arduino. Dat scheelt bekabeling, en dus risico op lastig opspoorbare storingen.

Dus als het Paul lukt om en de melding-verwerking, en de concrete acties voor elkaar te krijgen, dan wordt het zinvol om te kijken naar de abstracte invulling. Tegelijkertijd zie ik de bui al hangen.
Bij de opstart van het systeem moet een dynamisch gelinkte lijst in het geheugen worden geladen, en dat kan lang duren. Bij een grote baan (laten we zeggen een paar honderd meter rails, tafelsegmenten, e.d.) zul je met meerdere arduino's moeten werken die wifi of anders met elkaar communiceren (omdat de bedrading anders te lang wordt). Dus moet je modulair denken, vanaf het begin.

[smits66]

Hoi Volgers,

@Jan Willem

Dat maakt me duidelijk hoe het werkt. Voor rijden/niet-rijden gebruik je de monostabiele relais, voor wissels bistabiele relais. De monostabiele zitten op prefab kaartjes, de bistabiele niet.
Je signalering (reedcontact) verbruikt ingangen, het signaal gaat naar de arduino, en die stuurt (via script) de relais aan. Dus stel je vervangt het reedcontact door een lichtsluis, dan gaat het signaal (of signalen) van die lichtsluis ook naar de aduino. M.a.w. de arduino vormt een extra tussenlaag binnen de bestaande schakelingen, tussen input en output?
 

Dit klopt voor een gedeelte niet, Het bistabiele relais word in de keerlus gebruikt om de baanspanning om te polen zodat de treinen zonder te hoeven stoppen door kunnen rijden de baan op.

Wissels kun je evt. met een monostabiele relais omzetten (korte puls door de Arduino) per wissel heb je dan twee monostabile relais nodig.

Beter is het om de wissels te schakelen met vermogens transistoren.
De blokken worden door monostabiele relais gestuurd dat kost een relais per blok.

De signalering van de blokken kan door : reed-relais, ldr, ir lichtsluis, ir reflectie sensoren of via stroom detectie  er zijn vast meer componenten te gebruiken voor signalering.

De sensoren (lees signalering) worden door mijn systeem via de analogepoort gelezen, zodoende hou ik meer digitale I/O over.

Voor rijden/niet rijden van de locomotief gebruik je motordrivers, deze regelen het optrekken/ afremmen of stoppen van de trein, tenzij je voor elk blok een eigen motordriver gebruikt, dan kun je de blokrelais weglaten, anders heb je de blokrelais nodig om bepaalde blokken spanningsloos te maken.

Als je een reed-relais vervangt voor een lr lichtsluis zal je ook het Arduino programma moeten veranderen, tenzij je digitale ingangen gebruikt dan hoeft dat niet, ik gebruik de analogepoort voor het uitlezen van de sensoren.

De Arduino regelt zelf de sturing van de baan met behulp van sensoren en motordrivers  zelfstandig of als blok gestuurd systeem, in beide gevallen zorgt het programma voor de uitvoering van de sturing.

De sturing die ik probeer te bouwen, moet een blok gestuurd systeem worden.

@Timo

Ze schelen nog steeds een factor 2 hoor   

Dat valt erg mee, voor een Arduino pro mini betaal ik euro 2,56 en voor een Arduino nano betaal ik euro 2,80.

Is dat voor de Arduino gestuurde baan? En waarom wil je met twee relais werken? En waarom bi-stabiel? Misschien heb je er een goeie reden voor hoor  Maar ik mis het, zeker in het licht van de Arduino baan.

Ik gebruik de biploaire relais om de baanspanning voor een gedeelte van de baan om te polen, zodat de trein zonder stoppen door de keerlus kan rijden.
De tweede relais is voor het bedienings-paneel om de toestand van de keerlus/baan weergeven.
Er zit in de schakeling nog twee extra  monostabiele relais om de wissel om te zetten (later ga ik die vervangen door vermogens transistoren) om te testen werk deze opstelling prima en had deze schakeling nog gebouwd liggen.

Mvg Paul

[gvandersel]

SLX852, daaraan hangt inderdaad een ander prijskaartje.

SLX852 is inderdaad een andere catagorie, maar een Arduino als SX-bus master zou met 6 weerstanden een afstand van een meter of 10 kunnen overbruggen in modeltreinland. Helaas is de software voor de Arduino nog niet openbaar.

Groet,

Gerard van der Sel.

[Timo]

Beter is het om de wissels te schakelen met vermogens transistoren.
De blokken worden door monostabiele relais gestuurd dat kost een relais per blok.

Mee eens  Transistors zijn goedkoop, makkelijk en niet mechanisch. Voor een blok is een standaard monostabiele prima.

De signalering van de blokken kan door : reed-relais, ldr, ir lichtsluis, ir reflectie sensoren of via stroom detectie  er zijn vast meer componenten te gebruiken voor signalering.

De mogelijkheden zijn inderdaad eindeloos en de meeste methodes resulteren gewoon in een puls dus zijn gewoon dwars door elkaar te gebruiken.

De sensoren (lees signalering) worden door mijn systeem via de analogepoort gelezen, zodoende hou ik meer digitale I/O over.

Dat is een drogreden Paul  Alle analoge poorten (met uitzondering van A7) zijn prima gewoon als digitale poort te gebruiken! Ze hebben alleen als extra functie dat ze analoog kunnen lezen.

Voor rijden/niet rijden van de locomotief gebruik je motordrivers, deze regelen het optrekken/ afremmen of stoppen van de trein, tenzij je voor elk blok een eigen motordriver gebruikt, dan kun je de blokrelais weglaten, anders heb je de blokrelais nodig om bepaalde blokken spanningsloos te maken.

Prima te combineren inderdaad  Maar zullen we voor het gemak eens termen afspreken om onderscheid te maken? Voorstel, blokken voor alles achter een motordriver en subblok voor alles achter een relais? Is namelijk al een paar keer verwarrend geweest in dit draadje 

De Arduino regelt zelf de sturing van de baan met behulp van sensoren en motordrivers  zelfstandig of als blok gestuurd systeem, in beide gevallen zorgt het programma voor de uitvoering van de sturing.

Hoe ingewikkeld je de sturing maakt bepaal je dus zelf (en zit eigenlijk de meeste uitdaging). 

Dat valt erg mee, voor een Arduino pro mini betaal ik euro 2,56 en voor een Arduino nano betaal ik euro 2,80.

Dan heb je dure Pro Mini's  Ik koop ze voor €1,25... Niet om het gebruik van de Nano af te kraken maar puur om aan te geven dat ze echt nog goedkoper zijn. En dan kun je denken "ach, wat scheelt dat nu?". Maar als Roco dat ook had gedacht kostte de z21 wel iets meer 

En een mooie startersset: hierrr.

Ik gebruik de biploaire relais om de baanspanning voor een gedeelte van de baan om te polen, zodat de trein zonder stoppen door de keerlus kan rijden.
De tweede relais is voor het bedienings-paneel om de toestand van de keerlus/baan weergeven.

Duidelijk.  Maar weet dat een bistabiel relais in een Arduino blok gestuurde baan wel een beetje zinloos is... Als je gewoon zorgt dat de lus een eigen motordriver heeft ben je ook klaar 


Timo

[Te 2/2]

Ik begrijp nog niet alles, maar ik lees me in. Daar is dit een goed draadje voor.

In mijn visie is een keerlus een soort blok (met afgeleide eigenschappen en methoden). Dat betekent dat ik dit type blok van een methode zou voorzien om de rijrichting om te schakelen van een naastliggend (volgend) blok. Ik denk dan aan de Z-schalting (in dit geval twee stroombronnen via een bistabiele keuze), en dat omgezet naar een boolean in de software die de gemaakte keuze vast legt. Het monostabiele blokrelais tapt daarvan af.

In een arduino aanpak, begrijp ik nu, zou ik dat principe los moeten laten, want de motordriver vervangt het blok-relais. Dus moet ik meer weten over het functioneren van zo'n motordriver.
Hoe werkt dat, waarvan betrekt dat ding de stroom en is die broombron op deze manier manipuleerbaar?

Ik vraag me dat af, omdat in mijn old-school analoge relais-gestuurde aanpak ook geschakeld wordt tussen 2-rail en 3-rail, volgens het zelfde principe als rijrichting. Een trein kopieert de toestand (railtype, evt. rijrichting) van het huidige naar het volgende blok zonder dat ik (of mijn paneel) hoef te weten wat voor trein dat is (railtype),  wat de rijrichting is, en dus ook wat het volgende blok is. Als ik dat wel wil weten, is een enkel ledje extra hier of daar genoeg.

Nu weet ik ook wel dat relais overkill zijn, met flipflops (transistors) kan het ook, goedkoper, sneller, beter. Alleen raak je dan de toestanden (state-of-affairs) kwijt als je de stroom uit zet, en dat wil ik niet. Dus ik wil de gebeurtenissen (events) vast kunnen leggen bij stroomuitval. Old-school aanpak: bipolair; arduino op disk (flash of niet), als lijsten.
Daarom zou ik in C, C++, VB (mij een biet) blokken zo coderen dat met een minimum aan ballast (een cijferreeks of string) alle toestanden (eigenschappen) en methoden per blok opgeslagen kunnen worden. Bij modulaire aanpak zou elk blok dus ook een blok-uid, blok-type-id, een module-id, een netwerk-id, en twee boundary-id's hebben, software-matig.

[gvandersel]

Klopt geheel. Dit staat in de struct of de class (properties). De functionaliteit van het blok is vastgelegd in methoden.

Een motordriver (bv L293) zijn in principe 4 transistoren, waarvan er altijd minimaal twee in sper staan. De overige twee kun je pulseren (pulsbreedte modulatie) of permanent open zetten. Alle 4 in sper is 0 volt op de rails, trein staat stil. Je rijdt vooruit met het ene tweetal, en achteruit met het andere tweetal. Bij een keerlus rij (analoog) naar de keerlus met paar A. In de keerlus is ook paar A actief. Bij het verlaten wordt in het oorspronkelijke inrij blok paar B actief. Hierdoor rijdt de trein gewoon door.

Groet,

Gerard van der Sel.

[Te 2/2]

Na een nuttige leesmiddag,
http://www.thebox.myzen.co.uk/Workshop/Introduction.html
http://arduino-info.wikispaces.com/DC-Motors
http://arduino-info.wikispaces.com/DC-Motors-2 (push pull output)
https://www.pololu.com/product/2502/
https://www.pololu.com/docs/0J49 (motor shield guide)
https://learn.adafruit.com/downloads/pdf/adafruit-arduino-lesson-13-dc-motors.pdf
http://luckylarry.co.uk/arduino-projects/control-a-dc-motor-with-arduino-and-l293d-chip/
http://communityofrobots.com/tutorial/kawal/how-drive-dc-motor-using-l293d-arduino
http://tronixlabs.com/news/tutorial-l298n-dual-motor-controller-module-2a-and-arduino
http://elabz.com/brushless-dc-motor-with-arduino/

begrijp ik dat Gerard het heel compact, en juist, heeft uitgelegd. Ondertussen heb ik me gelijk maar eens verdiept in Arduino compatibele lichtsluizen, want als ik ze toch zelf moet maken kan ik ook wel wat geschikte specs meenemen.

[Timo]

Lekker bezig geweest Jan Willem!

In mijn visie is een keerlus een soort blok (met afgeleide eigenschappen en methoden). Dat betekent dat ik dit type blok van een methode zou voorzien om de rijrichting om te schakelen van een naastliggend (volgend) blok.

Daarmee is het toch eigenlijk niet anders dan een normaal blok 

En hoe je de boel dirigeert is aan jou. Is een blok verantwoordelijk om het volgende blok aan te spreken (en moet dus ook weten hoe wissels liggen enz) of maak je een blok een dom ding die alleen subblokken aanstuurt en laat je het hele aansturen aan een externe "controle" classe over?

In een arduino aanpak, begrijp ik nu, zou ik dat principe los moeten laten, want de motordriver vervangt het blok-relais.

Als je mee gaat in mijn eerdere blok en subblok structuur, ja. Maar je zou dus, om motor controllers te besparen, dus meerdere subblokken achter één driver kunnen hangen. Bijvoorbeeld handig voor stationsporen of lange opstelsporen enzo. Maar idee is dan wel dat er maar één trein rijdt per driver. Rest mag natuurlijk wel stilstaan in een subblok maar voor rijden zit je met het probleem dat treinen nogal verschillende snelheden hebben bij verschillende spanning enzo. Zitten ze op één driver kan je ze niet meer individueel regelen.

Daarom zou ik in C, C++, VB (mij een biet) blokken zo coderen dat met een minimum aan ballast (een cijferreeks of string) alle toestanden (eigenschappen) en methoden per blok opgeslagen kunnen worden.

Ook daar ben je natuurlijk vrij. Maar waar wil je dit opslaan? Op een centrale plaats (bijvoorbeeld PC, (Raspberry) Pi of centrale Arduino (met SD-kaart ofzo)? Of wil je dit op de Arduino doen die het blok beheert?

In EEPROM van de Arduino is wel mogelijk maar dan zou ik wel een soort afsluit routine maken want EEPROM heeft geen eeuwig leven. Op een PC of Pi zou het natuurlijk wel continue kunnen maar dan moet je deze data wel steeds versturen (via een bus of postduif ofzo  ) Moet je dus wel rekening mee houden als je dat deel ontwerpt.

Ondertussen heb ik me gelijk maar eens verdiept in Arduino compatibele lichtsluizen, want als ik ze toch zelf moet maken kan ik ook wel wat geschikte specs meenemen.

Schema wat ik ook vond (op gewezen door Frits) is dit schema met de LM567. Andere optie is met de IS471F maar deze is iets duurder, wel simpeler. Beide moduleren de IR led waardoor ze geen last hebben van lampen en zonlicht.


Timo

[Te 2/2]

De link met de LM567 werkt niet.
Je andere link is de http://www.floodland.nl/aim/info_lichtsluis_1.htm

Daar zet ik deze links tegen af. Zelfde principe:
http://www.moba-tipps.de/lichtschranke.pdf
http://www.christian-luetgens.de/eisenbahn/elektronik/ls1/Lichtschranke_1.htm
http://www.christian-luetgens.de/eisenbahn/elektronik/ls2/Lichtschranke_2.htm

Waar het om gaat: de receiver is een transistor die gaat geleiden vanaf een bepaalde
grenswaarde. Als er geen voorwerp zit tussen zender en ontvanger, geleidt de transistor niet.
Zolang er een voorwerp zit tussen zender en ontvanger, en de grenswaarde is bereikt, dan gaat het (monostabiele) relais aan.
En dat wit ik niet.

Wat ik wel wil is dat vanaf de drempelwaarde omhoog gefilterd wordt door een bouwsteen die alleen voor de duur van de stijging signaal doorgeeft aan het relais,en alleen gedurende de daling naar de drempel signaal door geeft aan een tweede (monostabiel) relais.
Dat kan met een dual monostable multivibrator, zoals de CD4098 of latere versies daarvan. Zo'n TTL (of CMOS variant) bouwsteen filtert op de flanken, en geeft alleen de flanksignalen door, niet het tussenliggende gebied, en geeft dus twee korte pulsen, aan het begin en aan het eind van de sessie. Het beginsignaal is nodig om het volgende blok van de juiste rij-eigenschappen te voorzien, het eindsignaal geeft het vorige blok vrij. En voor zover ik weet, bestaat zo'n soort lichtsluis nog niet, en zal ik 'm zelf moeten bouwen. Floodland 's oplossing is dus niet de mijne, maar geeft wel een goed voorbeeld om mijn aanpak in te bouwen.
Ik zou alleen geneigd zijn 5 volt technologie te nemen (goedkoper) en te voeden vanuit een AT-voeding.

Terug naar de motor-driver. Stel je hebt 30 treinen die kunnen rijden op 20 standaard blokken, plus een aantal afgeleide bloktype blokken. Heb je dan 30 motordrivers nodig?

[Timo]

De link met de LM567 werkt niet.

Probeer nog eens. Link werkt hier prima (op twee andere apparaten dan gepost) dus denk dat Benelux Rail gewoon de hik had.

En dat wit ik niet.

Wat ik wel wil is dat...

Uhm, wat denk je allemaal moeilijk!  Dat kan je toch gewoon allemaal bekijken op de Arduino? Hoog actief, laag actief, zo aan te passen. Iets doen als bezet wordt, makkie. enz Als je een microcontroller gebruikt is dat allemaal maar software.

Terug naar de motor-driver. Stel je hebt 30 treinen die kunnen rijden op 20 standaard blokken, plus een aantal afgeleide bloktype blokken. Heb je dan 30 motordrivers nodig?

Je hebt minimaal zoveel motor drivers nodig als dat je individueel de snelheid van rijdende wilt kunnen instellen. Dus als je met 10 treinen wilt rijden en de rest staat stil kan je op papier af met 10 motorcontrollers. Maar goed, dan zijn alle blokken altijd bezet, dus je hebt meer marge nodig. Beter is te bedenken dat je (om iedere trein individueel te sturen) net zo veel motorcontrollers nodig hebt als dat je secties waar 1 trein tegelijk ik moet kunnen rijden.

Maar goed, motor drivers zijn eigenlijk best goedkoop. Niet zo veel duurder dan relais breakouts. De meeste hebben drie pinnen nodig maar again, een Arduino kost ook maar 1,30... Als je twee of drie blokken met één Arduino kan doen is dat op zich prima lijkt me...


Timo

[Te 2/2]

@Paul, bedankt voor het mogen inbreken in je draadje.

@Timo:

Uhm, wat denk je allemaal moeilijk!  Dat kan je toch gewoon allemaal bekijken op de Arduino?

OK, ik leer weer wat bij. Die dubbele puls is nodig in mijn old-school relais aanpak, en is dat misschien of zeker niet in de arduino-aanpak (vanwege de ingebouwde timer, neem ik aan). 

De motordriver kun je apart voeden als de motor meer stroom vraagt dan de arduino intern kan leveren. Handig bij 12-16 vDC rijstroom.

Manier voor 2-3 rail aanpak per blok. Met arduino enerzijds software, anderzijds omleiding van de uitvoer van motordriver naar de spoorstaven van een blok of blokreeks via een extra relais (mono of bi naar keuze). Mmmm, blokreeks, een lijst in een lijst. Moet ik onthouden. Kan ik wel iets mee in Java of C++.

De permanente opslag van gegevens is kennelijk wel een probleem om nog even in te duiken.

[Timo]

(vanwege de ingebouwde timer, neem ik aan). 

Niet zo zeer door de timer. Maar je kan states opslaan en daarmee dus een soort monostabiele / flipfop nabootsen.

Je polled steeds de lichtsluis ingang. En is de state gelijk aan de vorige keer, doe je niets en sla je alleen de state op. Is hij ongelijk (zowel hoog geworden als laag geworden zijn natuurlijk te bepalen) dan kan je de actie uitvoeren. En dit is nu precies wat een microcontroller zo flexibel maakt. Je kan delen hardware inruilen voor software

De motordriver kun je apart voeden als de motor meer stroom vraagt dan de arduino intern kan leveren.

Yep, (de meeste) motordrivers hebben een ingang voor de logische signalen voor de sturing en een ingang voor de spanning om voor de uitgang te gebruiken. Laatste mag dan gewoon 18V zijn.

Handig bij 12-16 vDC rijstroom.

Zullen we dat vanaf nu maar rijspanning noemen  Bij modelspoor is het makkelijker om met spanningssturing te werken dan met stroomsturing.

Manier voor 2-3 rail aanpak per blok. Met arduino enerzijds software, anderzijds omleiding van de uitvoer van motordriver naar de spoorstaven van een blok of blokreeks via een extra relais (mono of bi naar keuze).

Dat is natuurlijk een redelijk makkelijke aanvulling. Gewoon een relais per blok (dus hoeft niet per subblok) toevoegen. Een monostabiele lijkt me prima. Kost minder pinnen dus wel zo makkelijk / goedkoop. Zou ik wel 3-rail aan het NC hangen omdat dat de fail save positie is.

De permanente opslag van gegevens is kennelijk wel een probleem om nog even in te duiken.

Niet zo zeer een probleem, alles is mogelijk. Je moet alleen bedenken hoe je het wilt doen


Timo

[Te 2/2]

Niet zo zeer een probleem, alles is mogelijk. Je moet alleen bedenken hoe je het wilt doen

Alles is mogelijk zolang je de beperkingen niet kent. Onbegrensde mogelijkheden passen nog niet in mijn denkraam. Dus denk ik parallel aan wat er wel is.

Zou ik wel 3-rail aan het NC hangen omdat dat de fail save positie is.

Dat is een doordenkertje.

Ondertussen ben ik benieuwd of Paul met zijn keerlus aanpak uitkomt bij zoiets als
http://www.floodland.nl/aim/info_arduino_keerlus_1.htm , of dat het iets  totaal anders wordt.

[Timo]

Die keerlus oplossing zou niet heel handig zijn. Die is voor een digitale baan. Waarbij het niet uit maakt voor de richting welke polaritiet het signaal heeft. Deze wordt dan ook omgedraaid in de lus terwijl de trein in de lus is. Maar bij analoog kan je niet zomaar de polariteit om draaien. Dus voor analoog is het het makkelijkste om een losse motordriver voor de lus te pakken en als de trein volledig in de lus zit de spanning buiten de lus (dus eerst volgende blok) om te draaien. In dat opzicht is het blok niet anders dan andere blokken en de trein stuurt vooraf gewoon rijrichting en snelheid naar het volgende blok alleen houdt dat nu vanzelf in dat je de spanning ompoolt.


Timo