Automatisering voor Kranenberg - Arduino's, bezetmelders, wissels, seinen

[meino]

Ik zag dat het hoofdstukje over Digitaal op dit forum hoofdzakelijk over problemen en vragen gaat, dus plaats ik dit draadje toch maar hier, ondanks het feit dat het alleen maar over digitale- en computerzaken gaat.

Zoals ik in de bouwbeschrijving van Kranenberg beschrijf, ben ik op een gegeven moment van analoog bedrijf naar digitaal overgestapt. Dat is gebeurd met een MDRRC-II Centrale. De volgende stap, die al snel kwam, was om dan ook met een PC de baan te gaan besturen. De MDRRC-II centrale kan met een aantal programma's aangestuurd worden, waarbij Robert Evers Koploper als referentie gebruikt. Alhoewel ik zelf een voorkeur voor JMRI had, maar dat ondersteunde de MDRRC-II centrale niet. Dus Koploper gedownload en opgetuigd. Dat had best wat voeten in de aarde, omdat Koploper zo zijn eigenaardigen heeft. Maar om Koploper (en ook andere programmatuur) zijn werk te kunnen laten doen, moet Koploper informatie van de baan krijgen en de mogelijkheid hebben om wissels te kunnen aansturen. Teminste als je automatisch wilt rijden. Verder wilde ik ook iets met seinen gaan doen. In eerste instantie had ik het idee om dat puur met armseinen te doen, totdat ik ontdekte dat er ook 3D geprinte seinen van het seinstelsel '46 beschikbaar waren. Na een test met het bouwen van een sein, besloten om, op 2 versimpelde vertakkingseinen na, alles met seinen van het seinstelsel '46 te doen, zie https://forum.beneluxspoor.net/index.php?topic=34476.540, vanaf reactie #543.  Dat betekende dat er een aantal verschillende componenten bedacht en gebouwd moesten worden. Een systeem dat de bezetmelding van een sectie in de baan in de gaten houdt en terugmeldt aan de centrale, een systeem dat DCC wisselcommando's ontvangt en de wissels omzet en een systeem dat de ledjes en servo's van de seinen aanstuurt.

Dat heeft uiteindelijk tot het volgende complex van systemen geleid.



Oorspronkelijk waren de systemen voor de bezetmelders en wisselaansturing gescheiden. Maar ik had al snel het idee dat ik de wissels ook handmatig nog wilde kunnen aansturen. Dat moest dan wel via Koploper gebeuren in verband met de controle, het is niet zo handig om een wissel om te zetten als de wissel nog bezet is. Dat kon via een bezetmelder (gekoppeld aan een drukknop) en een speciale actie. Alleen om dat goed werkend te krijgen is het eigenlijk ook nodig om een terugmelding naar Koploper van de wisselstand te hebben via een bezetmelding. Vandaar dat er communicatie is ontstaan tussen deze systemen, waarbij de wisselsteller een melding maakt aan de bezetmeldercontroller als een wissel omgaat. Later toen ik de systemen voor de seinen ontwikkelde, bleken die ook behoefte te hebben om te weten hoe de wissels staan. Verder deze laatste worden ook door DCC commando's aangestuurd, ik had ze apart aan de DCC bus kunnen verbinden, maar omdat dat de wisselsteller al een koppeling met de DCC bus had, vangt die de seincommando's op en geeft die ook door aan de seincontrollers.
Een opmerking voor de nitpickers, ik heb iets de S88 bus genoemd, technisch gezien is dit een shiftregister en geen bus, maar conceptueel vond ik het beter om dit een bus te noemen.

Tot zover deze introductie, in de volgende stukjes zal ik wat dieper ingaan op de verschillende systemen.

Groet Meino

[Timo]

Hoi Meino,

de categorieën zijn wat dat betreft een beetje een ramp inderdaad

Maar waarom ben je voor I2C gegaan ipv XPressNet wat de MDRRC-II zo ondersteund? I2C is namelijk absoluut niet geschikt om onder een baan te leggen. Na 10 a 20cm houdt I2C echt wel op stabiel te zijn


Timo

[meino]

Hoi Timo

dat weet ik, maar gemak dient de mens. Deze systemen zitten allemaal vlak bij elkaar onder de baan, dus afstand is nog geen probleem, overigens de grootste afstand die ik heb overbrugd is 50-60 cm en werkt in mijn situatie nog probleemloos. Maar de implementatie is dood simpel, 2 draadjes en een bestaande library. Als het in de toekomst toch problemen gaat geven, door extra systemen die verder af gaan komen, dan kan ik altijd nog het vervangen door een ander bus systeem. Dan denk ik zelf eerder aan Loconet dan XpressNet.

Groet Meino

[Robert E]

Maar waarom ben je voor I2C gegaan ipv XPressNet wat de MDRRC-II zo ondersteund?

Schrok even, maar gelukkig gebruik je de I2C bus van MDRRC-II niet...
Ondersteuning daarvoor gaat namelijk bij de eerste beste update eruit.....

a 10 a 20cm houdt I2C echt wel op stabiel te zijn

Mwaahhh, als je bitrate niet te hoog zet gaat een metertje of twee wel

Mvg

Robert

[meino]

Schrok even, maar gelukkig gebruik je de I2C bus van MDRRC-II niet...
Ondersteuning daarvoor gaat namelijk bij de eerste beste update eruit.....

Nee, ik zou eerlijk gezegd niet weten waarvoor ik die kon gebruiken. de enige data die ik naar MDRRC-II stuur gaat via S88. Maar nog wel even een compliment voor je over de MDRRC-II.

Groet Meino

[gvandersel]

Leuke opzet. Zie mogelijkheden voor een SX-bus ipv een I2C bus.

Groet,

Gerard van der Sel.

[Timo]

Ja, dat is de dunne lijn tussen "het werkt" en een goed ontwerp. Zeg niet dat je het moet aanpassen hoor Maar als je rare dingen ziet zou dat wel je eerste punt van aandacht moeten zijn. Door inderdaad maar de standaard 100 kbit/sec gebruikt en niet te lichte pull ups gebruikt is het nog wel een beetje te rekken\stabiliseren. Maar bedenk dat de meeste modelspoorbanen redelijk veel storing bevatten.


Timo

[meino]

Timo

Wat een goed ontwerp is zullen we hier niet over twisten, dat heb ik in mijn werkzame leven al genoeg gedaan. Nu ben ik met een hobby bezig en het meeste is organisch gegroeid, waarbij veel zaken achteraf anders en beter hadden gekund.
Ik ben me zeer bewust van de potentiele problemen, Ik heb al genoeg problemen gehad met servo's - opgelost door afgeschermde cat6 kabels te gebruiken - en nu heb ik een bezetmelder die zo nu en dan vervelend doet, helaas is het juist de bezet melder die met het kortste kabeltje (20cm) met de arduino verbonden is. Verder heb ik de DCC library aangepast om stoorsignalen(spikes) op het DCC kanaal software matig uit te filteren.
Toen ik met de I2C bus begon was het een verbinding tussen 2 mega's die naast elkaar zitten, dus een heel korte verbinding en heel simpel te realiseren, later heb ik ook nog een cluster van 3 mega's verbonden. Die drie zitten ook naast elkaar alleen is de cluster zelf ongeveer 50-60 cm verwijderd van de andere 2. Tot nu toe werkt dat vlekkeloos, waarbij ik nog niets aan de clockrate (ik wist niet eens dat dat kon) gedaan heb, dus dat loopt nog op de default waarden. Verder probeer ik me aan het adagium "If it ain't broke, don't fix it" te houden, soms is dat best wel moeilijk omdat ook ik vaak denk "Dat kan beter". Mocht ik in de toekomst meer Arduino's te gaan koppelen, dan is de kans groot dat ik de I2C bus door iets anders moet vervangen.

Groet Meino

[Klaas Zondervan]

Naar aanleiding van dit draadje heb ik eens gekeken wat I2C inhoudt. In alle beschrijvingen die ik vind wordt gesteld dat er slechts 2 lijnen zijn, een datalijn en een kloklijn. Maar om het goed te laten werken moet de ground van de diverse controllers toch ook gekoppeld zijn?

[gvandersel]

Klopt Klaas. I2C bestaat uit een klok lijn en een bidirectionele datalijn. Om het geheel elektrisch te laten werken is er nog een derde lijn de GND. I2C is bedoeld voor communicatie IN een apparaat. Hierbij is sprake van een voeding (Zal je wel bekend zijn). Hierdoor staat het ook bekend als een twee draads protocol. Het is dus bij grotere afstanden drie draads.

Groet,

Gerard van der Sel.

[meino]

Ik wist dat dat voor I2C nodig was, dus alle Arduino's zijn gekoppeld aan de zelfde GND.  Het zelfde voor de voeding, alle arduino's en aangekoppelde hardware wordt vanuit 1 bron gevoed.

Overigens heb ik ook maar eens op wikipedia gekeken en de Engelse versie (https://en.wikipedia.org/wiki/I%C2%B2C) geeft een zeer uitgebreide beschrijving. Overigens kwam ik daar het volgende tegen:
"The maximal number of nodes is limited by the address space and also by the total bus capacitance of 400 pF, which restricts practical communication distances to a few meters. The relatively high impedance and low noise immunity requires a common ground potential, which again restricts practical use to communication within the same PC board or small system of boards."
Daaruit leid ik af dat de maximale afstand die veilig te overbruggen is hoofdzakelijk bepaald wordt door de maximale capaciteit van de kabel. Als ik het zo bekijk dan komt mijn situatie redelijk overeen met wat beschreven wordt. Het is weliswaar geen koppeling op een board, maar de gekoppelde systemen zitten in mijn geval wel fysiek dicht bij elkaar. Het is echter wel duidelijk dat als de te koppelen systemen verspreid over de baan zitten, de I2C bus niet zonder meer een goede oplossing is.

Groet Meino

[Robert E]

Nu ben ik met een hobby bezig .....

Gewoon lekker doorgaan
Soms is het wat omslachtig of kan het anders maar jij moet er plezier aan hebben !

Zo is MDRRC ook ontstaan...

Mvg

Robert

[gvandersel]

Er bestaan overigens I2C busdrivers die de afstand erg vergroten. Wat betreft de adresspace, die is 7 bits. Dus 128 apparaten. Hoeveel data ieder apparaat ontvangt is niet gedefinieerd. Bij je draaischijf gebruik je een afgeleide van I2C, en daar gaan met iedere dataslag een stuk of 32 bits heen en weer. Hiervan is een gedeelte subadres.

Groet,

Gerard van der Sel.

[meino]

Dag Gerard

De Adafruit motorshield die ik eerst gebruikte bij de draaischijf, gebruikt inderdaad de I2C bus. Het driverkaartje dat ik nu gebruik, de TMC2130, gebruikt de SPI bus. Tenminste dat leid ik uit het commentaar in de library af. De SPI bus zou dus ook nog een mogelijkheid zijn om Arduino's te laten communiceren, maar daar heb ik me nog niet echt in verdiept.

Groet Meino

[meino]

Ik kom toch nog even terug op de afgelopen discussie.

Timo heeft echt wel een punt betreffende het gebruik van I2C bus. Het is hiermee erg makkelijk om Arduino's te koppelen, en in mijn situatie werkt het goed. Maar dat hoeft niet in iedere situatie op te gaan. Daarnaast heb ik voldoende kennis om eventuele problemen op te lossen, maar dat hoeft niet voor iedereen op te gaan.

Daarom heb ik toch nog eens naar wat alternatieven gekeken, n.l. XpressNet en Loconet. Maar ik vind dat aan beide alternatieven toch wel nadelen kleven.

- XpressNet is een gesloten systeem die naast de hardware ook een complete definitie van alle commando's tussen de master en aangesloten apparaten bevat. Dat betekend dat ik voor mijn toepassing waarschijnlijk gebruik moet maken van commando's die in beschreven zijn door Lenz. Verder maakt XpressNet gebruik van een adres van 5 bits, wat betekend dat XpressNet maximaal 31 apparaten kan aansturen. Verder is binnen het XpressNet de centrale verantwoordelijk voor het toewijzen van transmissie slots aan de aangesloten apparaten. Kortom de Centrale is verantwoordelijk voor het ordelijk functioneren van het netwerk/bus. Ook de transmissie snelheid (64Kb) vindt wat aan de lage kant.

- Loconet is anders, het bevat niet een master en alle apparaten hebben de zelfde rechten (het is afgeleid van Ethernet). Maar voor zover ik kan zien bevat het ook set van voorgedefinieerde commando's. Overigens dit weet ik niet helemaal zeker, omdat Lenz een document met een complete definitie heeft gepubliceerd, maar voor Loconet heb ik dat nog niet kunnen vinden. De vrije, op Ethernet gebaseerde werking spreekt mij wel aan. Maar de transmissie snelheid (16Kb) vindt ik zelf veel te laag voor de toepassing die ik voor ogen heb.

Kortom bij geen van de beide alternatieven loop ik erg warm om dat te gaan gebruiken. Toen kwam ik op Ebay het volgende tegen https://www.ebay.de/itm/mini-ENC28J60-Ethernet-LAN-Netzwerk-Modul-Arduino-RJ45-SPI-CP01002.
Een kaartje waarmee je Arduino's op Ethernet kunt aansluiten, voor de prijs (vanaf euro 2,50) hoef je het niet te laten, en met de juiste bibliotheek, kan een Arduino in een IP netwerk worden opgenomen, je kunt zelfs een HTML server bouwen op een Arduino. Dit opent vele mogelijkheden, peer to peer communicatie met UDP of TCP, remote configuratie en monitoring door middel van een Webbrowser etc. Verder alle hardware is makkelijk te krijgen, iedere bouwmarkt heeft tegenwoordig een grote collectie aan patchkabels, stekkers, tangen, losse cat5 kabel. Switches en routers zijn ook voor weinig geld overal te krijgen.
Dus ik heb wat van deze kaartjes besteld in China om te kijken of dit kan gaan werken. De resultaten zal ik hier in draadje wel laten weten.

Groet Meino