Auteur Topic: Twentse Modelspoorweg Club (TMC): Digitale besturing (gelezen 4114 keer)

Dat kan opzich wel bij USB, maar dat hangt van je hardware en een beetje software af. .... Maar zoals je waarschijnlijk al doorhebt. Dat is veel werk waarbij ethernet meer plug n play is

Klopt!.

Ik snap het toch niet helemaal. Zoals ik het lees, is er niet een fysieke Xnet bus? En gebruik je het Xnet protocol alleen tussen PIO kaarten en PC
De Freds gaan op loconet.

Misschien dat een foto de huidige situatie duidelijker kan maken. De foto toont de PC voor 1 station, ieder station heeft zijn eigen PC.
De PIO kaarten zitten in de PC en komen met behulp van een aantal flatcables naar buiten. Meteen achter de PC worden ze gesplitst en gaan naar meerdere 25-polige SUBD-connectoren. Daarvandaan gaan ze door middel van standaard 25-polige ronde kabels, die meerder meters lang kunnen zijn, naar de elektronica om wissels om te zetten of sporen bezet te melden.

Omdat veranderingen in kleine, reversibele stapjes moeten gaan, is het de bedoeling om in een eerste stap de VB6 software niet meer de PIO kaarten in de PC aan te sturen, maar:

Experiment 1: USB-PIO converters, of
Experiment 2: een Ethernet - TCP/IP - XpressNet interface. Daarvandaan gaat het naar een centrale (Lenz, Z21, Yamorc, zelfbouw, ...), die speciale TMC "test" decoders aanstuurt, die weer worden aangesloten op de 25 polige ronde kabels.

Op deze manier kunnen we, als iets niet werkt, binnen een paar minuten teruggaan naar de oude situatie (SUBD-Connectoren omsteken, oude VB6 software opstarten). Pas als het een tijd stabiel werkt, zouden we de USB-PIO converters / Ethernet / XpressNet kunnen doortrekken (en de bestaande 25 polige bekabeling kunnen verwijderen).

Er komt dus geen XpressNet bus langs de baan, om handregelaars in te stoppen. Daarvoor blijven we Loconet / IB / FREDs gebruiken (dus geen multimaus).

Ook wordt de (IB) centrale voor rijden NIET gebruikt voor terugmelding / wissels schakelen.

Terugmelders, (heb je dat nog niet verteld of zitten die ook op de PIO kaarten en heb ik het niet begrepen)

De huidige terugmelding / bezetmelding wordt ook door de PIO kaarten gedaan. Dat moet in de toekomst ook anders.
Ik zal over bezetmelding in een volgende, uitgebreid bericht, wat meer vertellen.

Xnet kent geen terugmelders.

Dat klopt niet helemaal. Lenz heeft de RS-Bus, en de meldingen van deze bus worden door de Lenz centrale via daarvoor gedefinieerde XpressNet commando's verstuurd. Roco doet iets vergelijkbaars.

Groet, Aiko

bask185 · « **Reactie #16 Gepost op:** 27 August 2024, 14:47:15 »

Nee dat klopt wel. Er bestaan geen XpressNet fysieke terugmelders, losse terugmelders zit niet in dat protocol. Wat wel bestaat is een XpressNet broadcast bericht van de Xnet master met informatie over terugmelders, daar heb jij het over. Maar die informatie komt van echte terugmelders die op andere fysieke bussen zitten en dat kan van alles zijn zoals bijvoorbeeld de RS bus. Of in het geval van Roco dan die R-bus. (fun fact: R-bus kan je zien als dialect van XpressNet. Het lijkt er veel op. Een of andere kerel uit Tsjechie heeft dat uitgevogeld maar ik kan zijn website nooit zo snel vinden)

Ik weet niet of die broadcasts ook daadwerkelijk plaatsvinden op de Lenz centrales. Ik heb ze dat ooit gevraagd maar die mail is nooit beantwoord.
Ik weet dat de DR5000 het wel doet.
En volgens de Roco customer support doet de z21 het weer niet, en om die reden heb ik ook nooit een R-bus melder gekocht om dit zelf te testen, want die zijn *** duur. Maar ik kreeg ook van de customer support te horen dat je dat 'niet nodig' hebt. Dat maak ik zelf wel uit

Citaat

Experiment 2: een Ethernet - TCP/IP - XpressNet interface

Die heb je dus ook voor loconet. Ik meen dat uhlenbrock er een heeft. Maar je kan ook zelf met een Arduino een USB <> loconet omzetter maken. En als je iets meer tijd heb, koop je zo'n ethernetshield en maak je zelf je Loconet <> ethernet interface.

Want dan

Citaat

De huidige terugmelding / bezetmelding wordt ook door de PIO kaarten gedaan. Dat moet in de toekomst ook anders.

Kan je dus zelfbouw (bestuckte) loconet terugmelders gaan fabriceren voor weinig.

Citaat

Ik zal over bezetmelding in een volgende, uitgebreid bericht, wat meer vertellen.

Ik wacht geduldig af

Mvg,

Bas

Karst Drenth · « **Reactie #17 Gepost op:** 27 August 2024, 15:33:42 »

Je bent niet helemaal bij de tijd met jouw kennis

Nee dat klopt wel. Er bestaan geen XpressNet fysieke terugmelders, losse terugmelders zit niet in dat protocol.* Wat wel bestaat is een XpressNet broadcast bericht van de Xnet master met informatie over terugmelders, daar heb jij het over. Maar die informatie komt van echte terugmelders die op andere fysieke bussen zitten en dat kan van alles zijn zoals bijvoorbeeld de RS bus. Of in het geval van Roco dan die R-bus. (fun fact: R-bus kan je zien als dialect van XpressNet. Het lijkt er veel op. Een of andere kerel uit Tsjechie heeft dat uitgevogeld** maar ik kan zijn website nooit zo snel vinden)

*) jawel hoor: Bluecher maakt(e) die dingen al ruim 10 jaar geleden. En sinds de laatste Build kunnen onze YD6016RB-CS dat truukje ook. De grap is, dat er door onze "OpenDCC" vrienden een uitbreiding op het XpressNet protokol is gemaakt. De Z/z21 pikken dat op en leiden de berichten verder naar een applicatie als ware het een LocoNet melder. Overigens heft dit gelijk het maximum aantal melders aan de RBus op. De RBuys van de z/Z21 in XBUS mode zetten, dan de YD6016RB-CS ook in XBus modus zetten, en je hebt 2048 mogelijke terugmelders !

**) nou nee hoor, dat was een Nederlander in 2014

Citaat van: bask185 op 27 August 2024, 15:43:44

Ik weet niet of die broadcasts ook daadwerkelijk plaatsvinden op de Lenz centrales*. Ik heb ze dat ooit gevraagd maar die mail is nooit beantwoord.
Ik weet dat de DR5000 het wel doet.
En volgens de Roco customer support doet de z21 het weer niet,** en om die reden heb ik ook nooit een R-bus melder gekocht om dit zelf te testen, want die zijn *** duur. Maar ik kreeg ook van de customer support te horen dat je dat 'niet nodig' hebt. Dat maak ik zelf wel uit

*) Lenz kent alleen RS melders, maar broadcast die dan ook wel degelijk via XpressNet. Geen "special-feature", staat gewoon in de specs.

**) @Roco: ken je product... de nieuwste FW op de z/Z21 heeft de mogelijkheid om ook die melders als LocoNet melders te broadcasten

Grtzz,
Karst

bask185 · « **Reactie #18 Gepost op:** 27 August 2024, 15:43:44 »

Dat klopt helemaal. Ik volg niet actief alle nieuwtjes van openDCC, roco en lenz. Druk bezig met throttles en ABC modules maken enzo. Ik vogel voor nu uit wat voor mij belangrijk is te weten. Wat een z21 precies doet, ja het zal wel

Ik geloof nog in het 1 bus principe.

Maar uit nieuwsgierigheid. Kan je nu met een z21 start met laatste FW nu ook 2048 terugmelders hebben?

Mvg,

Bas

Karst Drenth · « **Reactie #19 Gepost op:** 27 August 2024, 16:11:15 »

Maar uit nieuwsgierigheid. Kan je nu met een z21 start met laatste FW nu ook 2048 terugmelders hebben?

Yep ! Ik denk momenteel zelfs dat onze YD6016RB-CS de enige Module op de markt is, die dat kan. Let wel, de aansluiting is via de tot X-Bus getransformeerde R-Bus, de meldingen volgen via het Z21-Protokol in de LocoNet tunnel. En ja, de FW voor de z21 (start) moet minimaal 1.43 zijn. Werkt zelfs met de maintenance tool en met de Z21 App

Overigens werkt het ook via de "gewone" XBus van de z/Z21, maar die is langzamer dan de omgebouwde R-BUS.

Grtzz,
Karst

AP3737 · « **Reactie #20 Gepost op:** 27 August 2024, 17:33:45 »

Bezetmelding

Zoals in mijn vorige bijdrage reeds vermeld, overwegen we om voor het schakelen van wissels / seinen, en voor het melden of sporen bezet zijn, verschillende (als het kan, zelfbouw) centrales te gebruiken. Dat we wissels en seinen met DCC willen schakelen, zal tot weinig discussies leiden. De keuze voor het terugmeld protocol is echter minder vanzelfsprekend. Er zijn meerdere opties, zoals S88, LocoNet, RS-Bus, X-Bus, Can, Bidib, RailCom, en waarschijnlijk nog wel een paar. Ik verwacht dat de verschillende Forum lezers hierin verschillende keuzes maken, maar als er iets niet klopt in mijn redenatie, of als er feiten zijn die ik niet ken, dan hoor ik het graag.

Voordat een keuze wordt gemaakt, is het misschien verstandig eerst de eisen te noemen waaraan de bezetmeldbus moet voldoen.

Er moeten meerdere fabrikanten zijn die componenten maken voor deze bus.
De bus moet betrouwbaar kunnen werken, ook bij grote banen (lange kabels, veel melders).
Het moet voor de leden van de TMC mogelijk zijn om kosten te besparen door zelf bezetmelddecoders te maken (of bouwpakketten te kopen).

Aan de eerste eis is eenvoudig te voldoen; voor alle bezetmeldbussen zijn er eigenlijk wel een aantal fabrikanten die spulletjes leveren.

De tweede eis is makkelijk geformuleerd, maar wat betekent het precies? Daarop is geen eenduidig antwoord te geven; iedere techneut zal daarbij een ander antwoord geven. Voor mij betekent het onder andere dat de terugmeldbus en de voedingslijn galvanisch gescheiden moeten zijn. Als de voeding en de terugmeldbus met elkaar elektrisch verbonden zijn, kan stroom voor de voeding en stroom voor terugmelding elkaar beïnvloeden, wat bij lange leidingen tot moeilijk reproduceerbare fouten kan leiden. Galvanische scheiding kan door middel van opto-couplers (of moderne, maar ook duurdere, digitale isolatoren) op de terugmeld bus, maar ook door geïsoleerde DC/DC-omvormers, zoals de Recom 0505, op de voedingslijn. Verder is een bus die werkt op basis van stroomsturing minder gevoelig voor storingen dan een bus die werkt op basis van spanningssturing.

De derde eis is misschien wel de meest bepalende. Niet alleen moeten er goede open source libraries beschikbaar zijn (inclusief documentatie), maar vooral de eis dat we zelf voldoende kennis in huis moeten hebben, betekent dat de uiteindelijke keuze beperkt zal zijn.

Uiteindelijk komen er voor ons twee bussen in aanmerking: Loconet en RS-Bus.

RS-Bus heeft het voordeel dat we zelf veel kennis en ervaring in huis hebben. Ik heb zelf in het verleden een open source RS-Bus library geschreven (https://github.com/aikopras/RSbus), en denk dat deze bus nog weinig geheimen heeft. De bus is op alle decoders met opto-couplers ontkoppelt, en maakt gebruik van stroomsturing. De snelheid is relatief beperkt, maar om alleen te melden of sporen bezet zijn, is de snelheid voldoende. Bekabeling is relatief onkritisch, en er kunnen makkelijk 50 decoders aan één bus gehangen worden zonder dat er problemen optreden.

Loconet is (bij zelfbouwers) erg populair, en lijkt daarom een veilige keuze. Toch kies ik daar niet voor, omdat ik er niet van overtuigd ben dat een gemiddeld Loconet zelfbouw project, op basis van de MRRwA library en een Arduino Uno/ATMega328 (https://mrrwa.org/loconet-interface/), voor grote banen even betrouwbaar werkt als een RS-Bus zelfbouw project. Voor mij geldt: eerst zien, dan geloven. Het bewijs dat een (hardware / software) project precies zo functioneert als de specificatie zegt, is pas gegeven als het met behulp van een Logic analyser / scoop gevalideerd is. Ik begrijp niet goed dat ik, voor wat betreft de MRRwA library en de ATMega328, hierover niets kan vinden op het web. Ik weet dat in de praktijk veel mensen tevreden zijn met de MRRwA library / ATMega328, maar hoe groot zijn die banen? Voldoen ze aan de eis dat, binnen 2us nadat de Carrier Sense concludeert dat de lijn vrij is, begonnen wordt met zenden?
Ik heb al eens eerder op dit forum een draadje gestart (https://forum.beneluxspoor.net/index.php?topic=110394.0), en ik zal mijn twijfels hieronder proberen samen te vatten.

Het eerste verschil tussen een RS-Bus en gemiddeld Loconet zelfbouw project is, dat de RS-bus standaard op alle decoders met behulp van optocouplers is ontkoppelt, en een gemiddeld Loconet zelfbouw project niet. Daarnaast is de RS-Bus gebaseerd op stroomsturing, wat in mijn optiek betrouwbaarder is als spanningssturing.

Het belangrijkste verschil voor mij zit echter in de keus van de processor en hoe de processor belast wordt, vooral door tijdkritische code en Interrupt Service Routines (ISRs). De MRRwA library is geschreven voor de “oude” AtMega processoren (328, 2560, 32U4, ATTiny84, ATTiny84A, ATTiny841), alhoewel er later ook wat toevoegingen zijn gedaan, waardoor het ook zou moeten lopen op STM32F1 en de ESP8266. Ze draaien echter niet op de moderne “opvolgers” van de Atmega serie, zoals de AVR/DxCore (of PIC18) processoren. Deze nieuwe processoren zijn niet alleen goedkoper dan de oude AtMega processoren, maar het belangrijkste verschil zit in het feit dat de nieuwe AVR/DxCore (en PIC) processoren allerlei “peripherals” hebben, zoals het Event System, Core Independent Peripherals, en timers die direct aan externe signalen gekoppeld kunnen worden. Hierdoor kunnen veel taken in hardware verricht worden, zonder de processor (via ISRs) te belasten.

Hoe dit verschil tussen de oude AtMega en de nieuwe AVR/DxCore processoren in de praktijk uitpakt, kan ik misschien het beste uitleggen aan de hand van een tweetal plaatjes die ik gemaakt heb tijdens het testen van mijn RS-Bus implementatie.

Het eerste plaatje toont de belasting van de RS-Bus library op een oude AtMega processor. De bovenste lijn toont de ontvangen RS-Bus pulsjes, de onderste lijn de keren dat de processor een interrupt krijg. We zien dat iedere 200us een interrupt plaatsvindt, om het polling proces te volgen en om te bepalen of/wanneer er gezonden mag worden

Het tweede plaatje toont de belasting van de RS-Bus library op een nieuwe AVR/DxCore processor (en gebruik van een TCB timer). Bij deze nieuwe processoren kan de Timer zelf de polling pulsjes tellen, zonder tussenkomst van de processor. Er is alleen nog maar een Interrupt nodig als we iets willen zenden (middelste lijn). Met de nieuwe AVR/DxCore processoren is het volgens mij veel gemakkelijker om de RS-Bus software in combinatie met andere software betrouwbaar te laten werken.

Misschien dat dit enige uitleg behoeft. In het verleden heb ik met een aantal Arduino libraries problemen gehad, Voorbeelden zijn (of waren, misschien zijn de Libraries inmiddels aangepast) de MOBATOOLS (MOdellBAhn Tools) en de LCD Library. Ook heb ik problemen met Serial output gehad. De problemen werden veroorzaakt doordat de Libraries zelf gebruik maakten van lange ISR (meerdere tientallen us) of zelf strenge timing eisen stelden, waaraan niet in alle omstandigheden werd voldaan. De problemen traden slecht sporadisch op, maar waren heel vervelend (een wissel werd niet omgezet, een baanvak werd niet bezet gemeld). Bij dergelijke problemen is het heel lastig de oorzaak te vinden. Alleen door gebruik van een Logic analyser en het investeren van veel tijd, konden de fouten gevonden en verholpen worden. De les die ik hieruit heb geleerd, is dat het gebruik van ISRs, indien mogelijk, beperkt moet worden, en als ze toch nodig zijn, ze zo kort mogelijk moeten zijn (paar us, zeker geen tientallen us). Vooral bij de nieuwe AVR/DXCore is dit extra belangrijk, omdat je daar ISR geen hogere prioriteiten kan geven.

Ik ben er vrij zeker van dat ook Loconet veel betrouwbaarder wordt als deze op moderne processoren wordt geïmplementeerd. In feite hebben anderen dat al bewezen. Geert Giebens heeft een implementatie gemaakt voor een PIC18 (https://github.com/GeertGiebens/DIY_LocoNet_S88_DCC/) en Mikael Ejberg voor een AVR DA (https://www.ejberg.dk/portfolio/loconet-avr-da/). Ik denk dat deze twee implementaties veel betrouwbaarder met andere software kunnen samenwerken dan de standaard MRRwA implementatie op een oude AtMega processor.

Voor zover ik weet is er voor Geert’s Loconet implementatie geen standaard (C/C++) Arduino bibliotheek aanwezig. Voor Mikael’s implementatie is er wel een Arduino bibliotheek (https://github.com/ejbergdk/loconet-avrda), maar de documentatie daarvan is uiterst beperkt. Natuurlijk heb ik ook gekeken of ik misschien de MRRwA library zou kunnen aanpassen maar, om heel eerlijk te zijn, vind ik de source code daarvan niet erg getuigen van gestructureerd programmeren (de .cpp file telt meer dan 2000 regels). Ik zal mij van verdere kwalificaties onthouden.

Bij LocoNet zou ik als eis stellen, dat de voeding en terugmelding galvanisch gescheiden moet zijn, en dat een moderne processor en goede Library gebruikt moet worden, waarmee tijdkritische functies in hardware plaatsvinden. Alhoewel me dat zeker mogelijk lijkt, zou het ons op dit moment veel tijd kosten om dat helemaal alleen te ontwikkelen en te testen. Onze/mijn kennis van LocoNet is (zeer) beperkt, en als anderen weinig of geen interesse hebben in deze nieuwe hardware, dan is het voor ons (om dit alleen te doen) jammergenoeg op dit moment te veel werk. Het lijkt ons daarom op dit moment sneller en eenvoudiger als we gebruik maken van de RS-Bus voor terugmelding.

Om toch de weg naar LocoNet niet geheel af te sluiten, is een optie de bezetmelder electronica op een opsteek (piggy-back) print te zetten, die eventueel makkelijk vervangbaar is. Dus zoals Blücher dat vroeger al deed (https://www.bluecher-elektronik.de/produkte/gleisbesetztmelder-gbm16xn-vers-2-x/) en ik dat dankbaar heb gekopieerd: https://oshwlab.com/aikopras/rs-bus-smd

Groet, Aiko

JoopSpoort · « **Reactie #21 Gepost op:** 27 August 2024, 18:41:09 »

Hallo Aiko,
Geboren en getogen in Hengelooooo

laat dit mijn hart wel sneller kloppen. Als klein jongetje (met toen nog een peronkaartje) altijd staan kijken naar de treinen helemaal naar Utrecht en Amsterdam en naar het voorzichtig klaarzetten van de goederenwagons aan het perron van van Gent&Loos.
Overigens, de kruiswissels bij het kopspoor lijken me niet helemaal te kloppen. Je kon vanuit het kopspoor alleen naar Oldenzaal, niet naar /enschede. Maar dat zullen jullie wel uit praktische redenen zo hebben gedaan.

Ik las ook over de telefoonrelais? Dat doet me denken aan de modelspoorclub van de PTT in Hengelo waar ik lid van was (via de buurman). Daar waren toen ook plannen om Hengelo na te bouwen. Ik ging tegen die tijd elders wonen, hoe dat afgelopen is weet ik niet. Of is de TMC een voortzetting vanuit o.a. de modelspoorclub van de PTT?

Ik kom zeker een keer kijken als ik weer in Twente ben.

Ik vraag me af hoe de machinisten bij jullie communiceren met de verkeersleiding. De VL zal toch moeten weten waar de machinist naar toe wil terwijl jullie handmatig rijden?

AP3737 · « **Reactie #22 Gepost op:** 28 August 2024, 19:56:36 »

Beste Bas, Karst en Joop

@Joop

Geboren en getogen in Hengelooooo laat dit mijn hart wel sneller kloppen. Als klein jongetje (met toen nog een peronkaartje) altijd staan kijken naar de treinen helemaal naar Utrecht en Amsterdam en naar het voorzichtig klaarzetten van de goederenwagons aan het perron van van Gent&Loos.

Leuk dit te lezen; heel herkenbaar. Ik woon "pas" sinds 1974 in Twente (wisselend Enschede en Hengelo), maar als klein jongetje deed ik dit ook maar dan in Zwolle!

Overigens, de kruiswissels bij het kopspoor lijken me niet helemaal te kloppen. Je kon vanuit het kopspoor alleen naar Oldenzaal, niet naar /enschede.

Je bedoelt de kruising op onderstaande foto? Ja, je hebt volgens mij gelijk, en kan je daarvandaan alleen naar Oldenzaal. Maar volgens mij hebben we daar ook een normale kruising liggen, en klopt dat ook. Maar ik zal volgende keer eens precies kijken, als ik weer op de club ben.

Ik las ook over de telefoonrelais? Dat doet me denken aan de modelspoorclub van de PTT in Hengelo waar ik lid van was (via de buurman). Daar waren toen ook plannen om Hengelo na te bouwen. Ik ging tegen die tijd elders wonen, hoe dat afgelopen is weet ik niet. Of is de TMC een voortzetting vanuit o.a. de modelspoorclub van de PTT?

Oei, goede vraag. TMC heeft inderdaad haar wortels in Hengelo, en bestaat al sinds 1957 (zie: https://twentsemodelspoorweg.club/historie/). Maar of / hoe de relatie met de PTT was, weet ik niet. Er zijn een paar leden die de beginjaren nog kennen, maar ik ben "jongste lid", en moet nog veel leren. Maar ik zal onze voorzitter eens vragen. Die weet veel!

Ik kom zeker een keer kijken als ik weer in Twente ben.

Dan moet je op de opendag langskomen (als ik het me goed herinner, de laatste zondag van oktober). Dat is voor bezoek veruit het leukst!

Ik vraag me af hoe de machinisten bij jullie communiceren met de verkeersleiding. De VL zal toch moeten weten waar de machinist naar toe wil terwijl jullie handmatig rijden?

We communiceren "draadloos", indien nodig met stemverheffing

Wat wel bestaat is een XpressNet broadcast bericht

De Lenz XpressNet specificatie kent meerdere berichten die te maken hebben met terugmelding. Terugmelding kan betrekking hebben op wissels die van positie veranderen, maar ook de veranderde bezetmelding van sporen. Er zijn niet alleen broadcast meldingen, maar je kan ook zelf de status opvragen, waarna je een "gewoon" bericht terug krijgt. Wat Karst zegt, klopt helemaal! Kan ik niets meer aan toevoegen.