Arduino analoge(!) modelbaan sturing

[Te 2/2]

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.

Misschien heb ik de mogelijkheden overschat. Ik meende dat, door dit ding anders aan te sluiten dan op de tekening en in de uitleg staat, het relais de stroom kan ompolen buiten de lus in plaats van erbinnen. Ervan uit gaand dat het principe (dus wat het ding doet) gelijk blijft.

[gvandersel]

Je hebt de mogelijkheden niet overschat. Wat jij wilt zou zeker kunnen, maar of dat nu het handigst is. Laat de keerlusschakelingen aan de digitaslisten en de analoge rijders hebben hun eigen oplossing.

Groet,

Gerard van der Sel.

[Te 2/2]

Zelf beschik ik over goedkope bistabiele (2xom) en monostabiele (4xom) relais van minder dan € 1,- per stuk (die Chinezen toch!), en vergelijk ik dat met de kosten van zo'n floodland-torentje arduino's, dan ziet dat eruit als een kanon op een mug afvuren. Er moet dus ook een goedkopere arduino aanpak mogelijk zijn, zelfs als dat 4 pinnen kost.

De stapel hardware bij floodland lijkt inderdaad tamelijk overdone, als je het vergelijkt met deze analoge oplossing van F. Geering. En zelfs die kan goedkoper als je andere aannames doet.

De kracht van het idee van Felix Geering zit in de observatie dat de wisselstand en de rijrichting samenhangen. Daarin lijkt zijn idee afgeleid van dat van de werking van een zelfdenkend wissel, met wat verschillen. http://encyclopedie.beneluxspoor.net/index.php/Zelfdenkend_wissel.

Het tweede aspect van de analoge keerlus (daar zonder oplossing) staat in de encyclopedie bij het de aansluiting van de bovenleiding. Er staat niet bij dat je die uiteraard ook moet isoleren, net als de spoorstaven.

Het derde aspect wordt nergens genoemd: het voortraject van de lus (inrit-uitrit).
Je kunt de inrit-uitrit beschouwen als onderdeel van een enkel keerlus-blok. Immers, zodra de inrit bezet, kan er geen tweede trein meer in. De bezetmelding van een railsegment  bepaalt dan of iets een blok is. In 1 blok kan maximaal 1 trein rijden. Dat lijkt triviaal, maar leidt tot een andere aanpak. De rijrichting van in- en uitrit bepaalt de wisselstand, in combinatie met de rijrichting van de trein in de keerlus.

Voor ik nou verkeerd begrepen word: ik pleit niet voor een simpeler algoritme, maar voor een duidelijker analyse. Wat zou je willen realiseren met een analoge arduino-aanpak voor een keerlus: een bepaald soort keerlus, of meerdere soorten keerlussen:

• alleen een enkele keerlus, op basis van een enkel in- en uitrit-spoor
• een enkele keerlus met een of meerdere passeer-sporen of opstelsporen erin ("station" of  "schaduwstation"), op basis van een enkel in- en uitrit-spoor
• een dubbele keerlus, met een dubbelspoor in- en uitrit, met kruisend spoor
• de driehoek-"keerlus"
• secundair: een oplossing voor functioneel analoge bovenleiding in een keerlus

 

Wat moet zo'n module kunnen? Bij old-school analoog rijden met relais is het ad hoc en vooral niet modulair oplossen van situaties gangbaar. Maar als je streeft naar meer abstractie (object georiënteerd), dan hebben al deze situaties een gezamenlijke situatie met elkaar gemeen, en dat is de oplossing van Felix Geering.

Er zijn natuurlijk talloze oplossingen verzonnen voor blokgestuurd rijden. Een van de vele is van Felix Geering. Ik maak daar geen gebruik van. Maar wat ik er wel uit geleerd heb, is dat reedcontacten als sensor hun beperking hebben, met name bij trek-duw combinaties. Als je zo'n fijne Sprinter op je NS-baan hebt, of een SBB-variant, dan wil je kop kunnen maken op een station. Dat werkt vergelijkbaar aan een keerlus in je baan, maar toch anders. Bij keerlussen zit de magneet altijd op dezelfde plaats. Bij kopstations zit de magneet van een pendeltrein soms in de kop, soms in de staart. Of je moet met 2 magneten werken (in kop, en staart). En daarom vind ik analoog een lichtschacht eenduidiger dan een reedcontact.

En als ik dat nou weer terug vertaal naar de arduino aanpak
sensors, motordrivers aangestuurd door de software naar rijrichting en een shield om de wissel te bedienen. De motordrivers bedienen ook de functionele bovenleiding (die dus op dezelfde punten is geïsoleerd als de spoorstaven). Dat is de basis.

Wat te doen met alle extra's van de keerlus-varianten? Op het zelfde shield bijplaatsen?

[Te 2/2]

Zijn arduino shields stapelbaar?

[Timo]

Allereerst ben ik het met Gerard eens, de module is vast ook anders te gebruiken maar of dat handig is...

Zelf beschik ik over goedkope bistabiele (2xom) en monostabiele (4xom) relais van minder dan € 1,- per stuk (die Chinezen toch!),

Dat je monostabiele voor een habbekrats kan krijgen in China wist ik maar ik ben nog nooit bi-stabiele tegen gekomen. Heb je een linkje?

en vergelijk ik dat met de kosten van zo'n floodland-torentje arduino's, dan ziet dat eruit als een kanon op een mug afvuren. Er moet dus ook een goedkopere arduino aanpak mogelijk zijn, zelfs als dat 4 pinnen kost.

Zo heel erg complex is die Floodland oplossing niet. Enige is dat hij 3 relais schakelt ipv 1 zodat je eventueel 3 keer stroomdetectie kunt aanleggen in de lus.. Twee relais zou je dus weg kunnen laten. Maar weer, dit is een oplossing voor een digitale baan. Maw, de lus wordt omgeschakeld ipv het volgende blok. Analoog dus niet nuttig.

De stapel hardware bij floodland lijkt inderdaad tamelijk overdone, als je het vergelijkt met deze analoge oplossing van F. Geering. En zelfs die kan goedkoper als je andere aannames doet.

Wat is al zei, eigenlijk zit er geen drol op die print. Enige reden dat hij zo groot is omdat hij de Arduino Uno shield maat heeft gebruikt. Zou je het doen met een Pro Mini of Nano kan je met een veel kleiner printje af waarvan ik zou zeggen, doen! Handig!

Het derde aspect wordt nergens genoemd: het voortraject van de lus (inrit-uitrit).
Je kunt de inrit-uitrit beschouwen als onderdeel van een enkel keerlus-blok. Immers, zodra de inrit bezet, kan er geen tweede trein meer in.

Maar net wat je wilt. Als je pal voor de lus een station ofzo hebt dan zou het best nog kunnen. Trein 1 komt door het station/inrit de lus in, wacht daar (waarschijnlijk uit het zicht want lussen liggen zelden in het zicht). Trein 2 (een treinstel) komt naar station en na even gewacht te hebben vertrekt deze weer in de richting waar hij vandaan kwam. Nu kan je trein 1 weer tevoorschijn toveren uit de lus.

Dit zou wel kunnen als je de inrit en lus op één motor driver zet maar het is gewoon zo veel makkelijker te realiseren door de lus en inrit op losse drivers te zetten. Dan is alle flexibiliteit gewoon een kwestie van software.

Wat moet zo'n module kunnen? Bij old-school analoog rijden met relais is het ad hoc en vooral niet modulair oplossen van situaties gangbaar. Maar als je streeft naar meer abstractie (object georiënteerd), dan hebben al deze situaties een gezamenlijke situatie met elkaar gemeen, en dat is de oplossing van Felix Geering.

Maar wat ik er wel uit geleerd heb, is dat reedcontacten als sensor hun beperking hebben, met name bij trek-duw combinaties.

Dat klopt. Eigenlijk heeft elke vorm van detectie voor en nadelen. Bij een reedcontact is het voordeel dat het goedkoop en simpel is maar je moet de trein voorzien van magneten. En inderdaad, het moment van magneet moet consistent zijn. Kan iets keren/achteruit rijden dan zal hij voorzien moeten worden van een magneet voor en achter (en een systeem wat daarvan niet door de war raakt). Stroomdetectie heeft als voordeel dat je er niets van ziet maar dat er altijd een verbruiker voorop moet zijn. Ook is dit wat lastiger op een analoge baan (want geen detectie mogelijk als je geen spanning op de rails zet). Lichtsluizen hebben als voordeel dat ze de trein zelf detecteren dus en niets extra's nodig is. Wel moet de beam dus door het pad van de trein schijnen dus lastiger te verstoppen. Vandaar dat analoog een IR reflectie populair is. Deze detecteert ook de trein (dus niets erop nodig) alleen kan tussen de rails gemaakt worden.

en een shield om de wissel te bedienen.

Ben zelf dus geen fan van shields. Zijn zo groot en lomp. Print waar je een Pro Mini op kan prikken is vaak kleiner, makkelijker en goedkoper.

De motordrivers bedienen ook de functionele bovenleiding.

Functionele bovenleiding zou ik niet aan beginnen, dat heeft geen enkele meerwaarde en alleen nadelen. Zo is de stroomafname slechter dan via de wielen en is een keerlus zo goed als onmogelijk. Immers, na het keren wil de loc de verkeerde spoorstaaf gebruiken om de motor te voeden. Zou je kunnen oplossen door ieder blok de bovenleiding weer schakelbaar te maken maarja, waar doe je het eigenlijk voor? Gewoon spanning van de rails afnemen is dan net zo makkelijk...

Wat te doen met alle extra's van de keerlus-varianten? Op het zelfde shield bijplaatsen?

Wat ik al zei, in een door Arduino gestuurd bloksysteem is een keerlus niet anders dan elk ander blok... De Arduino moet gewoon zorgen dat het volgende blok dezelfde snelheid en richting heeft waarmee de trein door kan rijden. Dat dit toevallig ook hetzelfde blok is waar hij uit kwam maar deze nu van rechts naar links (dus richting andersom) wilt berijden is eigenlijk bijzaak...

Dus, systematisch heb je dan als, if volgende blok is vrij, stuur richting en snelheid (en wat nog meer) door naar volgende blok. En in het geval van een keerlus is "if volgende blok vrij" toevallig hetzelfde als dat de trein volledig de lus in is gereden. En als je een manier hebt om altijd bij te houden hoe de instellingen van een  een blok moeten als je vanuit een ander blok komt is het klaar. Bijvoorbeeld:
Blok 1 => Blok 2: Vooruit
Blok 2 => Blok 1: Achteruit
enz

En als blok 2 de lus is gaat dat al vanzelf goed.

Enige waar je mee zit is nog de deadlock. Dus hoe je om gaat met een tweede trein die de lus in wil. Maar dat is eigenlijk niet anders dan elk stuk enkelsporig. Ook daar wil je niet dat er twee treinen uit tegenoversgestelde richting het enkelspoor op rijden. Maar goed, dan zit je eigenlijk al een niveau hoger.

Zijn arduino shields stapelbaar?

In de basis, ja. Maar het ligt wel aan het shield. Deze moet wel voorzien zijn van weer een header. Die van Floodland is dat niet. Een ook al is het stapelbaar zegt dat natuurlijk niets over het eventueel dubbel gebruiken van pinnen op de Arduino.


Timo

[Te 2/2]

Functionele bovenleiding zou ik niet aan beginnen, dat heeft geen enkele meerwaarde en alleen nadelen. Zo is de stroomafname slechter dan via de wielen en is een keerlus zo goed als onmogelijk.

Onbekend maakt onbemind. Er is een reden waarom de stroomafname via de wielen minder betrouwbaar is, maar kennelijk kun je zelfs een Sommerfeldt bovenleiding prima functioneel gebruiken. Dat laatste wist ik zelf ook niet eerder.

Kijk eens hier rond: of wat meer gericht hier en daar.

Dat is een baan van 2-rail rijders met bovenleiding en een selectrix digitaal systeem. Ooit meenden ze het beste van twee werelden te mixen: 2-rail en 3-rail, door alle loks zo om te bouwen dat de beide spoorstaven de ene pool en de bovenleiding de andere pool vormt. Het waren toen nog beginners voor wie een keerlus onmogelijk leek ( je zou haast denken 3-rail rijders bij aanvang).

Aan hun aanpak zit wel een keerzijde: diesel- en stoomloks kunnen ze nooit meer gebruiken. Zitten zij niet mee.

Hun aanpak bewijst dat je bij 2-rail de bovenleiding functioneel kunt gebruiken, zelfs digitaal. Er is dus een andere oorzaak voor om te stellen dat het "normaal" geen zin heeft. De stroomafname is niet slechter dan via de wielen, dat is een drogreden. Het probleem zit in de rails of in de stroomafname van die wielen op de rails zelf, en niet in de bovenleiding.

Net zo'n drogreden: dat je beter digitaal kunt rijden op c-rails dan op k-rails. Er zijn op k-rails meer contactproblemen dan op c-rails, en als je de oorzaak begrijpt, dan kun je ze oplossen. Zo kijk ik ook naar 2-rail.

[gvandersel]

Jan Willem,

Bovenleiding functioneel voegt niets toe. In het begin van mijn modelspoor carrière heb ik Trix Express gehad. Dit is een 3 rail systeem, waarbij de beide railstaven elektrisch gescheiden zijn. Hiermee is het mogelijk om als je met functionele bovenleiding rijdt met 3 treinen onafhankelijk van elkaar te rijden. Bij een keerlus heb je problemen, trein verkeeerd om op de baan => problemen. Zodra je met meer dan twee treinen gaat rijden (maakt niet uit analoog of digitaal) vervalt het nut van bovenleiding, doordat de logica om de juiste spanning op de juiste plaats te krijgen alleen maar complexer wordt. Met de komst van digitaal en de mogelijkheid om meer treinen via de rails te sturen is de noodzaak voor functionele bovenleiding verder verminderd.

Dit is mijn verklaring.

Groet,

Gerard van der Sel.

[Timo]

Hoi Jan Willem,

Ik heb absoluut niet gezegd dat het niet kan  Maar als je al een vorm van meertreinenbedrijf aan het maken bent (of dit nu analoge blokken, Arduino sturing of digitaal met de computer is) voegt functionele bovenleiding niets toe behalve problemen uitdagingen. Contact aan de bovenleiding blijft een klein oppervlag en daarmee een groot single point of failure. Dus de stroomafname is wel degelijk slechter. En om de boel aan te sturen wordt alles alleen maar complexer zoals Gerard al aan gaf. En waarom? Je wil toch nog steeds maar één trein per blok? Ik ben het dus volledig met Gerard eens. En het is dus absoluut geen drogreden 

En 3-rail rijders moeten zelf maar uitzoeken waar ze op rijden.   Vroeger nog wel veel mee gereden dus het kan best leuk zijn als je het hebt (ook M-rail) maar ik vind 3-rail gewoon niet mooi. Maar als je ergens een voorraad van hebt kan je er prima mee uit de voeten.


Timo

[smits66]

Hoi volgers

@Timo, Gerard, Jan Willem
Bedankt voor jullie input

@Allen

In grote lijnen werkt het AAMS systeem, om het goed te kunnen testen ga ik een kleine modelspoorbaan bouwen.

Dit baantje word ongeveer 120x60 cm maar word wel als module voor de grote baan gebouwd.
Deze module word ook voorzien van scenery.

Het Baanplan



Het word een uitdaging om dit baantje met het AAMS systeem te gaan sturen.
Dit baantje heeft 

• 12 Wissels
• 14 Blokken waar van 4 in twee richtingen word bereden
• Elk blok is onderverdeeld in 2 secties
• 14 Seinen waar van er 8 verborgen zijn, deze zijn alleen zichtbaar op het bediening-paneel
• 28 sensoren onder/tussen/naast de railsen te beginnen bij het niet zichtbare deel
• 2 L293 motordrivers leveren ongeveer 600mA voldoende om een N-Lok aan te drijven.

De totale baan word door 2 motordrivers aangestuurd, twee in de bochten en 1 in het schaduw station en 1 bij het station.

Het word er niet direct bijgebouwd in de loop van de tijd ga ik dat er bij bouwen.
Dit alles wil ik met 1 a 2 Arduino' s  mega 2650 gaan sturen.
 
AAMS Baan indeling


Het is al meteen duidelijk dat ik te weinig i/o lijnen hebt , dit wil ik gaan oplossen door een shiftregister te gaan gebruiken, een shift-register heeft maar drie poorten nodig om acht  uitgangen te maken, door de shift register te multiplexen  kun je meer uitgangen maken, zo kun je heel veel uitgangen maken met drie i/o poorten.

Wil ik 24 i/o hebben moet ik drie shift-registers multiplexen en aan de Arduino hangen, door in het Arduino programma een matrix van 0 en 1 en te maken kan ik de uitgangen sturen.

Voorbeeld seinen matrix (let op! geen programmeercode)

matrix {0,0,0,0,0,0,0,0}  alle seinen staan uit
           {1,0,1,0,1,0,1,0} Blok 1 t/m 4 seinen Rood.
           {0,1,01,0,1,0,1 } Blok 1 t/m 4 seinen Groen
           {1,0,0,1,1,0,1,0} Blok 1 rood, blok 2 Groen, blok 3 Rood, blok 4 Rood
enz.

Deze constructie kun je ook voor wissels gebruiken.

Het schema van het shiftregister:



Het schema van de multiplex-shiftregister



Omdat er max. 20 mA per uitgang van het shiftregister beschikbaar is kun je daar hoogstens een ledje mee aansturen om meer vermogen te hebben heb ik achter het shiftregister een uln2803 driver gezet zodat bv relais kan aansturen, voor wissels levert de uln2803 te weinig vermogen, daarvoor worden vermogens transistorren voor gebruikt.

Zie onderstande schema



Ook moet ik nog sensor sturing ontwerpen, welke sensor ik er voor ga gebruiken moet ik nog even bekijken, ik beging met een LDR sensor, wil ook nog een IR reflectiesensor uitproberen en een IR-lichtsluis.

De LDR sensor werkte goed op mijn testbaantje, ik ga het schema nog verder uitbreiden om de gevoeligheid van de LDR sensor te kunnen instellen, maar dat moet ik nog even verder uitzoeken.
De LDR sensor zoals in het schema werkt goed.

Schema LDR sensor.



Dat was het weer voor vandaag

Mvg Paul 

[Te 2/2]

Ben benieuwd naar je LDR test. Met 10 kOhm zou die schaduwen moeten waarnemen, dus geschikt zijn voor schemertoestanden. Ga je je schaduwstation verlichten of is het in het verborgen gedeelte ook gewoon licht genoeg?

Dat Shiftregister is een goede vondst. Doet me ook denken aan een verbeterde old-school diodenmatrix, een manier om signalen parallel binnen lasten komen, en toch serieel te verwerken.
Zo te zien is hij 8-bits. Handig als je uln2803 driver ook 8-bits is. En 16-bits zal wel toekomstmuziek zijn?

Ik begin me wel af te vragen of een gedeelte van m'n baan zich hier ook voor leent, het deel met wisselstraat tussen kopstation, lokdepot, en hoofdbaan. Als er iets analoog duur uitpakt dan is het wel het automatiseren van rijwegen (met of zonder seinbeelden) door een wisselstraat met pak 'm beet 10 wissels. Zo'n analoge aanpak gaat meestal ook gepaard met CDU's om voldoende spanning te hebben voor wissels die dan gelijktijdig moeten schakelen. Met een Arduino aanpak kan dat ook anders, vlak na elkaar, bijvoorbeeld.

Ik ben benieuwd.

[Timo]

Hoi Paul,

Leuk plan. Zo krijgt het geheel wat vorm.

Nog wat gehad/gesnapt aan/van de vorige voorbeeldcode?

De totale baan word door 2 motordrivers aangestuurd, twee in de bochten en 1 in het schaduw station en 1 bij het station.

Ah, ik dacht eerst, 2 lijkt me wat weinig. Maar je bedoelt dus 2 IC's met dus 4 H-bruggen. Begrijp ik je goed als ik zeg dat de indeling is:
Driver 1: b3 b4
Driver 2: b5 b6 b7 b8
Driver 3: b9 b10
Driver 4: b1 b2 b11 b12 b13 b14

Komt overigens gelijk weer om de hoek kijken dat we hier nog steeds geen eenduidige term voor hebben 

Hier zie ik wel een beperking in rijmogelijkheden. Zo kan je dan niet het station uitrijden van spoor b11 en tegelijk het station inrijden op b2. Zelfde voor het schaduwstation. Ook kan je niet rangeren tegelijk met het station binnen rijden. En als je het later gaat uitbreiden (maar goed, dat is dus later) heb je hetzelfde probleem met het in/uit rijden van b1/b6.

Dit alles wil ik met 1 a 2 Arduino' s  mega 2650 gaan sturen.

Lijkt me prima mogelijk met 1 Mega. Wil je toch meer dan één uC (en dat zou het een stuk modulairder maken) zou ik zelf gaan voor een Pro Mini of Nano. Maar voor nu moet één Mega prima gaan. Maar als je het dus later wilt uitbreiden hoeft dat niet de makkelijkste weg te zijn....
 

Het is al meteen duidelijk dat ik te weinig i/o lijnen hebt , dit wil ik gaan oplossen door een shiftregister te gaan gebruiken, een shift-register heeft maar drie poorten nodig om acht  uitgangen te maken, door de shift register te multiplexen 

Daisy chaining is het woord wat je zoekt  Multiplexen is weer wat anders. Dit zou eventueel ook kunnen (hierbij sluit je de latch van ieder shift register op een aparte pin op de Arduino aan) maar kost meer pinnen (maar zou programmeren wel makkelijker kunnen maken omdat je niet verplicht ieder register elke keer hoeft te schrijven).

Maar shift registers zijn een goeie keuze, ze zijn super goedkoop en makkelijk aan te sturen.

matrix {0,0,0,0,0,0,0,0}  alle seinen staan uit [knip]

Ja, en dat "matrix" kan gewoon een array van bytes zijn. Waarbij iedere byte een heel shift register is. Voor 3 shift registers dus genoeg aan een byte shiftRegisterData[3].

Het schema van het shiftregister:

Drie opmerkingen. Waarschijnlijk is een shift register zelf al meer dan krachtig genoeg voor seinen. 5mA geeft met moderne ledjes al meer licht dan je zou willen voor een sein... Dus gewoon rechtstreeks aan het shift register zou dus ook mogelijk zijn.

De COM van de ULN kan je inderdaad aan de 5V hangen maar dan kan je niets voeden met een hogere spanning van 5V. Als je de seinen dus met 12V wilt voeden gaat dit nu niet. Overigens kan het voor het aansturen van ledjes geen kwaad de COM niet aan te sluiten.

En als laatste (en belangrijkste), gebruik pinnen 51 en 52 voor de data en clock. Dit zijn de hardware SPI pinnen  (het protocol waarmee je de shift registers aan stuurt) van de Mega. Hierdoor is het voor de Mega echt geen werk meer om het aan te sturen. Want ja, als je van een hardware oplossing gebruik kan maken, waarom zou je dat niet doen? Om dan te schrijven naar de registers gebruik je dan niet shiftOut() maar de (ingebouwde) SPI-library. 10Mhz als snelheid zou geen probleem moeten zijn en volgens mij wil je gewoon SPI_MODE0, die komt overeen met die van shiftOut().

Schema LDR sensor.

Dit gaat zeker niet werken  Maar is denk ik gewoon teken foutje  Alle analoge pinnen zien op deze manier allemaal alleen maar GND. Denk dat je het GND-punt en analogin-pint wilt omdraaien 

Als werken met een LDR op deze manier bevalt moet je er zeker mee door gaan maar bedenk dat een Mega maar 16 analog poorten heeft. Ook is dit relatief traag, zeker omdat de Mega eigenlijk maar 1 ADC heeft. Alle pinnen worden hier gewoon op gemultiplexed (echte multiplex  ). En om alleen hiervoor een 2e Mega (of uno/Pro Mini/Nano) zou ik zelf zonde vinden.


Timo

[gvandersel]

Paul,

Waarom een schuifregister en niet gewoon I2C. Dezelfde beperkingen heb je nu met je schuifregister. Bovendien kun je met I2C ook externe inputs creeren.

Groet,

Gerard van der Sel.

[smits66]

Hoi volgers,

@Timo

Bedankt voor je input

Ik heb de voorbeeld code bekeken en getest, moet me nog in de programmeertaal gaan verdiepen. Ik ben meer een mens van doen en ervaren, dan van lezen.

Ik heb het schema ondertussen aangepast, had de analoog in en gnd  omgewisseld in het schema (moet dat soort dingen ook niet
's avonds laat doen )

Voor mij is een blok een combi van motorsturing, seinsturing, bezetmelders, moeten maar eens gaan brainstormen hoe we de verschillende functies gaan noemen, ideeën zijn welkom.

Ik gebruik de uln2803 driver voor het aansturen van seinen omdat er ook nog seinen te koop zijn met gloeilampjes (vaak goedkoper dan leds)

Ben er nog niet uit welke Arduino uitvoering wil gaan gebruiken, allemaal hebben ze wel voordelen en nadelen.

@ Jan Willem

Bedank voor je input

@ Gerard

Ik kies voor de shiftregisters omdat mij programmeer kennis nog niet heel erg groot is, shiftregisters zijn makkelijker te programmeren dan een I²C , daarbij spelen de kosten ook mee de 74HC595 koop ik per 20 voor net twee Euro.
Wat ik voor een I²C chip/module weet ik niet, voor zover ik weet zijn die stukken duurder dan de 74HC595.


Mvg Paul 


 

[gvandersel]

Betreft I2C module: In china rond de 2 euro, gebouwd en klaar voor gebruik. Ik heb de spec van dat ic een keer opgezocht, maar is zowel voor input als output te gebruiken. Voor I2C kun je toch een library pakken? Dus programeren is feitelijk niets.
Om je 74LS595 aan te sluiten en aan de gang te krijgen zul je echt aan de gang moeten. Bitbanging (zoals ik met de SX-bus moest) of schuifregister gebruiken. Dan ISR inrichten en dan kun je je data pas heen en weer schuiven. Ik weet dat je een SX-bus in de buurt hebt. Waarom koppel je niet meerdere Arduino's met elkaar via de SX-bus en dan laten praten.

Groet,

Gerard van der Sel.

Even gegoogled op arduino i2c io levert dit op: http://playground.arduino.cc/Code/I2CPortExpander8574

[Timo]

IO expanders zijn inderdaad niet zo heel duur maar ik vind ze eigenlijk nog best overpriced. Een Pro Mini als I2C IO expander gebruiken is eigenlijk goedkoper...  (Staat op mijn verlanglijstje code voor te maken...) En voor het geld van 1 PCF8574T kan je 30 shift registers kopen. De 74HC595 is dan wel alleen output maar voor input kan je de tegenhanger, de 74HC165 pakken. En als je de hardware SPI gebruikt kan je met 4 pinnen zowel inputs als outputs tegelijk afhandelen zonder I2C overhead. En ja, misschien is met I2C iets makkelijker iedere pin zo out of the box in te stellen. Maar met één functie of library heb je zo alle inputs en outputs ingelezen/gezet in minder tijd dan één I2C transactie zou kosten. En aangezien Paul er seinen mee wil aansturen is het toch al makkelijker hier functies voor te schrijven en of die nu met de wire llibrary van doen hebben of de SPI library maakt niet zo veel uit. Dus in dit geval snap ik het wel 

@Paul, wat betreft de code, dat hands on snap ik wel Maar om het iets makkelijker te maken zou ik zeggen, kijk even naar de Ring buffer pagina op Wikipedia. Het is wel de Engelse pagina maar ik denk dat vooral de animatie al heeeel veel duidelijk kan maken 

Wat betreft namen dacht ik toen aan blokken (motor driver) en subblokken (detectie, sein, in/uit-schakel relais).


Timo