Twentse Modelspoorweg Club (TMC): Digitale besturing

[AP3737]

Hallo
In deze, en een aantal vervolgbijdragen, wil ik proberen de digitale besturing van de TMC baan te beschrijven, zoals ik die nu zie, en zoals die er in de toekomst volgens mij uit zou kunnen zien. Vooraf een waarschuwing: ik schrijf hier mijn persoonlijke ideeën; wat hier staat is geen officieel TMC beleid en is in de meeste gevallen niet besproken met de leden van de TMC . Het zou dus heel goed kunnen dat ik hier een aantal ideeën beschrijf die de leden van de Vereeniging niet zien zitten, en die dus ook nooit gerealiseerd gaan worden.

De vraag die gesteld kan worden, is waarom ik dan dit draadje begin. Er zijn hierop een aantal mogelijke antwoorden. In eerste instantie helpt het mij om mijn ideeën te structureren. Vervolgens hoop ik dat hetgeen ik schrijf, een aantal leden van de TMC zal helpen, nu of later (waarom was er ook al weer een bepaalde keuze gemaakt). Tenslotte hoop ik op feedback, zodat ideeën verbeterd kunnen worden.

Het is niet mijn bedoeling mooie plaatjes van de TMC baan te tonen. Daartoe kan men beter de TMC website bezoeken: https://twentsemodelspoorweg.club/. Het baanplan is eigenlijk simpel uit te leggen: we hebben de stations Enschede, Hengelo, Delden en Oldenzaal zo goed als op schaal nagebouwd, en er zijn 3 schaduwstations (Almelo, Bad Bentheim en Gronau). Het tijdperk is midden jaren zeventig. Er liggen 230 wissels, er zijn 110 seinen en ongeveer 300 bezetmelders. Waar in het echt wissels liggen en seinen staan, hebben wij ze ook. Om een indruk te krijgen hierbij een foto van station Hengelo


De club heeft bijna 70 leden, en een paar keer per maand zijn er drukbezochte rijavonden. Alhoewel de Vereeniging veel eigen materieel heeft, nemen de meeste leden hun eigen loks en rijtuigen mee. Gereden wordt digitaal; de centrale is een Uhlenbrock Intellibox en we hebben een groot aantal Fremo (Spax) Boosters nagebouwd (zie onder). Voor het rijden worden Fremo Freds gebruikt, die op vele plaatsen op Loconet kunnen worden aangesloten. Als men vanaf (schaduw)station Almelo via Hengelo en Oldenzaal naar (schaduw)station Bad Bentheim wil rijden, moet de “machinist” meelopen en zijn eigen Fred steeds opnieuw af- en aankoppelen. Sinds enige tijd zijn we aan het testen of Apps op mobiele telefoons een goed alternatief voor de Freds kunnen zijn.


De stations Enschede, Hengelo en Oldenzaal hebben ieder een eigen bediening, die op rijavonden ieder bemand worden door een seinhuiswachter. We hebben dus geen vol-automatische baan, en willen dat ook niet. Wel is er op de trajecten tussen de stations een beveiliging (Lenz LG100 Bremsgenerator), die ervoor zorgt dat treinen, indien nodig, automatisch gestopt kunnen worden.

Het geheel loopt reeds vele jaren stabiel en naar ieders tevredenheid. Op zich zou er dus geen reden hoeven te zijn om iets te veranderen. Behalve één ding: voor de besturing van de wissels en seinen worden een aantal PIO kaarten gebruikt, die door zelfgeschreven (VB6) software wordt aangestuurd. Deze PIO kaarten (zie foto hieronder) zijn natuurlijk niet meer te koop, en ook al zouden we er genoeg van op voorraad hebben, passen niet meer in moderne PCs. Het is dus tijd voor iets nieuws. Daarover wil ik een volgende keer iets meer vertellen.

Groet, Aiko

[bask185]

Leuk draadje, ideeën kan ik vast bij helpen 

Sinds enige tijd zijn we aan het testen of Apps op mobiele telefoons een goed alternatief voor de Freds kunnen zijn.

Uiteraard heb ik een tweetal handregelaren in de toekomst, die de Fred kunnen vervangen. Maar als je naar draadloos gaat kijken, kan je ook eens kijken naar dit stukje.

Mr Gathow heeft uitgevogeld hoe je elke multimaus kan upgraden naar WLAN multimaus door een ESP en een Lipo er in te hangen. Dit werkt volgens mij wel met dat Z21 protocol. Ik weet niet hoe dat gaat icm een intellibox. Als je de Z21 app echter aan de praat krijgt, moet je dit ook werkend kunnen krijgen.
https://pgahtow.de/w/Z21_WLAN_MultiMaus#Gateway_Software

Ik heb zelf wel eens een netwerk gemaakt van ESP8266 boards met een 'painless mesh' library. Dat vond ik redelijk simpel te doen, en ik had toen bijna 0 ervaring met draadloze dingen. Alle ESPs vormen onderling een zelf opererend netwerk. Je kan dan in applicatie code, een van de ESPs instellen als brug naar jullie systeem toe. En dan moet je zelf handregelaars fabrieken met een LiPo en ESP er in. Ik zag laatste dat er een nieuwe wemos d1 opvolger was met het acculaad circuit ingebouwd. Dat is een leuke basis om zelf draadloze throttles mee te maken, zijnde het als een mesh, met Z21 protocol, Loconet over TCP IP of met WiThrottle protocol. Wat het beste werkt met de IB, volgens mij is dan loconet wel handig, maar ik ben niet echt thuis in uhlenbrocks apparatuur. Ik weet wel dat ze een WLAN loconet interface hebben met nummer 63860.

Ik ben verder benieuwd naar jullie nieuwe wissel decoders 

Bas

[Karst Drenth]

Op zich zou er dus geen reden hoeven te zijn om iets te veranderen. Behalve één ding: voor de besturing van de wissels en seinen worden een aantal PIO kaarten gebruikt, die door zelfgeschreven (VB6) software wordt aangestuurd. Deze PIO kaarten (zie foto hieronder) zijn natuurlijk niet meer te koop, en ook al zouden we er genoeg van op voorraad hebben, passen niet meer in moderne PCs. Het is dus tijd voor iets nieuws. Daarover wil ik een volgende keer iets meer vertellen.

Ok, betreft het alleen de wissels en seinen? Je zoekt daarvoor een alternatief ? Vraag: Wat doet die zelfgeschreven software met die PIO kaarten ? Hangen daar aan de ene kant versterkers aan om de wissels te sturen en aan de andere kant misschien een/het bedieningstableau van het betreffende station ?

Ik lees namelijk:

Het geheel loopt reeds vele jaren stabiel en naar ieders tevredenheid.

wat mij de indruk geeft, dat je geen directe aanleiding hebt om de besturing van de locs (FREDs) te vervangen ?

Vraag: in welke orde-grootte van aantallen FREDs spreken we ? 1-5; 5-10; 10-20; > 20 ?

Grtzz,
Karst

[AP3737]

Beste Bas en Karst

Dank voor jullie reacties.

Betreft het alleen de wissels en seinen? Je zoekt daarvoor een alternatief ? Vraag: Wat doet die zelfgeschreven software met die PIO kaarten ? Hangen daar aan de ene kant versterkers aan om de wissels te sturen en aan de andere kant misschien een/het bedieningstableau van het betreffende station ?

Ja, de belangrijkste reden voor verandering zijn de PIO kaarten, dus de bediening van wissels, seinen en de bezet terugmelding. Aan deze kaarten hangen inderdaad (zelfgebouwde, maar relatief standaard) versterkers en optocouplers. Aan de bedienkant zijn er wel bedieningstableaus, maar bediening gaat vooral via beeldscherm en muis. Voor ieder station zijn de sporen, wissels en seinen op een beeldscherm zichtbaar. Wisselstraten etc. kunnen zo bediend worden.

wat mij de indruk geeft, dat je geen directe aanleiding hebt om de besturing van de locs (FREDs) te vervangen ?
Vraag: in welke orde-grootte van aantallen FREDs spreken we ? 1-5; 5-10; 10-20; > 20 ?

Hoeveel Freds we precies hebben weet ik zo uit mijn hoofd niet (ik ben momenteel in Zwitserland op vakantie, en kan dus ook niet even natellen). Maar het aantal aanwezige Freds is zeker groter dan 20.
De Freds zijn niet echt een probleem, maar er zijn wel wensen waarin de huidige (oude) Freds niet goed voorzien (we hebben verschillende types). De belangrijkste wensen zijn om meer functies te kunnen bedienen. Veel leden hebben locs met prachtige geluiden, maar (afhankelijk van het type Fred) kunnen daarvan maar een beperkt aantal bediend worden. Ook is soms terugmelding van de "stand" van een functie gewenst (b.v. als F4 Rangeerstand is ingeschakeld, en de "machinist" zich afvraagt waarom de trein zo langzaam rijdt).

De Freds hebben één groot voordeel ten opzichte van de ons bekende alternatieven: het DCC loc adres is relatief vast. Een "machinist" kan dus niet (door een typefout of wat dan ook) er zomaar met een andere trein vandoor gaan.

Mr Gathow heeft uitgevogeld hoe je elke multimaus kan upgraden naar WLAN multimaus

Dat zou een mogelijkheid zijn, maar die is wel relatief duur. Bij de aantallen die wij in gebruik hebben niet meer echt leuk. Zoals ik hierboven al heb aangegeven, is de belangrijkste beperking van de bestaande Freds het beperkte aantal functies, en het niet zichtbaar zijn welke functie nu precies is ingeschakeld. Wat kosten betreft, is een App op je mobieltje natuurlijk de meest interessante oplossing. Op dit moment testen we bv. met WiThrottle. Aan mobieltjes zitten echter wel weer een aantal nadelen. De machinist kan gebeld worden, waardoor de besturing wegvalt (ja, je kan je mobieltje op niet-storen zetten, maar natuurlijk net die ene keer dat je gebeld wordt, was je dat vergeten ...). Bij mobiele Apps kan je relatief eenvoudig typefouten maken, en ervandoor gaan met de trein van iemand anders. Bij alle draadloze systemen kan de batterij opeens leeg zijn, terwijl je dacht dat je hem toch echt had opgeladen.

Ik zag laatste dat er een nieuwe wemos d1 opvolger was

Complete zelfbouw zou een optie zijn. Zelf ben ik nogal gecharmeerd van M5-Stack, omdat je daar alles al mooi ingebouwd in een kastje hebt. Maar zelfbouw kost natuurlijk veel tijd om te ontwikkelen, en de prioriteit ligt momenteel bij de vervanging van de PIO kaarten.

Ik ben verder benieuwd naar jullie nieuwe wissel decoders 

Komt  . Nog even geduld 

groet, Aiko

[spock]

Als je zoveel POI wilt hebben voor je zo laag mogelijke prijs dan zou ik kijken naar POI bordjes met een Mcp23017 chip.
Per Mcp23017 heb je 16 IO pinnen. Deze wordt aangestuurd per i2c. Je kunt acht van deze boards aansluiten op een microcontroller met i2c interface, bv arduino of ESP32. Dat zijn dan 128 IO's.

Je zal dan wel zelf de software moeten schrijven voor de microcontroller.
Interfacing met de PC is dan afhankelijk van de interface van de microcontroller (USB, Ethernet of Wifi (niet de eerste keus)).

mvg spock

[AP3737]

Als je zoveel POI wilt hebben voor je zo laag mogelijke prijs dan zou ik kijken naar POI bordjes met een Mcp23017 chip.
Per Mcp23017 heb je 16 IO pinnen. Deze wordt aangestuurd per i2c. Je kunt acht van deze boards aansluiten op een microcontroller met i2c interface, bv arduino of ESP32. Dat zijn dan 128 IO's.

Je zal dan wel zelf de software moeten schrijven voor de microcontroller.
Interfacing met de PC is dan afhankelijk van de interface van de microcontroller (USB, Ethernet of Wifi (niet de eerste keus)).

mvg spock

Beste Spock
Dank je voor de suggestie. We hebben inderdaad oplossingen bekeken op basis van een Arduino en I2C I/O extenders. Kom ik nog op terug.

Groet, Aiko

[AP3737]

Voordat ik mogelijke alternatieven bespreek voor de 192 kanaal Parallelle I/O (PIO) kaarten, wil ik eerst de “ontwerpeisen” (randvoorwaarden, wensen) noemen waaraan oplossingen moeten voldoen.

De eerste en belangrijkste eis, is dat “tijdens de verbouwing” de rijavonden gewoon door moeten gaan. Het is onbespreekbaar als de baan er een aantal maanden uit zou liggen. Als er iets wordt vernieuwd, zou het eigenlijk zo moeten zijn dat, als er onverhoeds problemen optreden, er alleen wat stekkers of printjes verwijderd hoeven te worden en de oude er weer in worden gestopt. Of dat de nieuwe programmatuur wordt gestopt, en de oude weer wordt opgestart.
Het gevolg van deze eis is dat we veranderingen in kleine stapjes moeten uitvoeren.

Een tweede eis is dat de huidige wisselaansturing, op basis van “oude” telefoonrelais, behouden blijft. Het monteren en afstellen van deze aandrijvingen heeft veel tijd en energie gekost. Ze werken goed, en we hebben er (mocht er eens wat kapot gaan) nog genoeg van op voorraad. Bovendien hebben ze niets gekost, dus wat wil je nog meer?
Aan ieder telefoonrelais zit al een printje met daarop een paar componenten, waaronder een printrelais, zodat we vanuit de PIO kaarten en wat “tussen electronica” 48V op de telefoonrelais kunnen zetten, en daarmee het wissel omzetten. Ook de hartstuk polarisatie van de wissels (meest Rocoline) wordt door het printrelais verzorgd, omdat we er achter kwamen dat de contacten van de telefoonrelais niet altijd betrouwbaar werkten. Hieronder wat foto’s van de telefoonrelais en printjes.




De printjes zijn allemaal voorzien van 8-polige RJ45 connectoren. Alhoewel niet alle 8 polen aangesloten zijn, is door de keuze van deze 8-polige connectoren verwisseling met de 6-polige Loconet bekabeling (voor de Fred bediening) uitgesloten. Voor ieder station komen alle (witte 8-polige) wisselkabels op een centrale plaats samen. Hieronder een foto van zo’n centrale “schakelkast” waar de kabels samenkomen.


Een derde eis is dat we de huidige computer programma’s, die op een grafische wijze de stationsemplacementen tonen, na wat aanpassingen, kunnen blijven gebruiken. De “seinhuiswachters / verkeersleiders” zijn aan dit user interface gewend, waardoor fouten worden beperkt.

Naast deze drie “functionele” eisen zijn er ook nog wat “strategische” wensen.

De belangrijkste wens is dat we minder afhankelijk worden van de kennis en ervaring van individuele leden, maar meer richting “standaard” oplossingen gaan. Vooral voor wat betreft de computer programmatuur is dit een lastige wens: enerzijds willen we de huidige programmatuur graag behouden, maar anderzijds zouden we ook met standaard programmatuur (zoals Koploper, RocRail, iTrain, TC, …) willen experimenteren. Een aantal leden heeft thuis dergelijke standaardsoftware in gebruik, en we zouden best eens een tijdje met verschillende programma’s ervaring willen opdoen.

Een tweede wens is dat het geheel niet te prijzig wordt. Alhoewel de Vereeniging er financieel op zich goed voorstaat, moeten we toch steeds op de centen letten. Als we bijvoorbeeld zouden besluiten alle electronica “even nieuw te kopen”, zouden de kosten voor decoders voor de huidige 300 bezetmelders, 230 wissels en 110 seinen al snel richting tienduizend Euro of meer gaan. Dat is geen realistisch plan.
Om kosten te besparen, willen we daarom liefst dingen zelf bouwen. Een probleem dat zich dan natuurlijk wel zou kunnen voordoen, is dat de kennis om bepaalde dingen te bouwen, weer bij een beperkt  aantal personen aanwezig komt. Daarom moeten zelfbouw projecten liefst compatibel / vergelijkbare functionaliteit hebben als commerciële producten, zodat ze later, indien nodig, eenvoudig door commerciële producten vervangen kunnen worden. Ook is goede documentatie van zelfbouw projecten essentieel, zodat iets later makkelijk nagebouwd kan worden. Indien mogelijk zouden projecten met de buitenwereld gedeeld moeten worden, via platforms zoals GitHub en OSHWLab, zodat we feedback krijgen en er ook anderen hun voordeel mee kunnen doen.

Dat was het weer voor vandaag. Wordt vervolgd.
Aiko

[Klaas Zondervan]

Het gevolg van deze eis is dat we veranderingen in kleine stapjes moeten uitvoeren.

Dat zou je kunnen doen door de wissels stuk voor stuk te vervangen door b.v. motoraandrijvingen. Die worden anders aangestuurd, maar dat kun je ondervangen door er andere hulpprintjes bij te zetten waarmee je de oorspronkelijk aansturing uit de centrale kast kunt behouden.

Ook de hartstuk polarisatie van de wissels (meest Rocoline) wordt door het printrelais verzorgd, omdat we er achter kwamen dat de contacten van de telefoonrelais niet altijd betrouwbaar werkten.

Een oorzaak kan zijn dat de telefoonrelais verkeerd gemonteerd zitten. Nu kan stof op de contacten blijven liggen. In een telefooncentrale werden ze gemonteerd met de contacten vertikaal, zodat stof er tussendoor kon vallen. Bovendien zat er een stofkap over een rek met relais, tenminste bij de telefooncentrale die ik ooit heb gesloopt omdat ik de relais mocht hebben.
Voor een grotere betrouwbaarheid kun je ook meerdere contacten parallel zetten.

[bask185]

Als ik jullie wensen bij elkaar optel

De belangrijkste wens is dat we minder afhankelijk worden van de kennis en ervaring van individuele leden, maar meer richting “standaard” oplossingen gaan

+

Een tweede wens is dat het geheel niet te prijzig wordt ..... Als we bijvoorbeeld zouden besluiten alle elektronica “even nieuw te kopen”, zouden de kosten voor decoders voor de huidige 300 bezetmelders, 230 wissels en 110 seinen al snel richting tienduizend Euro of meer

+

Daarom moeten zelfbouw projecten liefst compatibel / vergelijkbare functionaliteit hebben als commerciële producten, zodat ze later, indien nodig, eenvoudig door commerciële producten vervangen kunnen worden

+

Om kosten te besparen, willen we daarom liefst dingen zelf bouwen. Een probleem dat zich dan natuurlijk wel zou kunnen voordoen, is dat de kennis om bepaalde dingen te bouwen, weer bij een beperkt  aantal personen aanwezig komt. Daarom moeten zelfbouw projecten liefst compatibel / vergelijkbare functionaliteit hebben als commerciële producten, zodat ze later, indien nodig, eenvoudig door commerciële producten vervangen kunnen worden. Ook is goede documentatie van zelfbouw projecten essentieel, zodat iets later makkelijk nagebouwd kan worden. Indien mogelijk zouden projecten met de buitenwereld gedeeld moeten worden, via platforms zoals GitHub en OSHWLab, zodat we feedback krijgen en er ook anderen hun voordeel mee kunnen doen

=

Open source decoders en terugmelders.

Dit citaat ken je wellicht.

Give a man a fish, and you feed him for a day; teach a man to fish and you feed him for a lifetime.

Naast dat ik 'vis' verkoop, leer ik ook hoe je zelf de vis moet vangen.

Mijn decoders, terugmelders en dingen, die zet ik allemaal online. Ik heb een uitgebreide instructie over je hoe die zelf kan bestellen bij de printenboer. En ik leg uit hoe je het programma er in moet schieten. Daar heb ik makkelijk te gebruiken batch files voor. Je moet nu denken over een prijs van €8,- a €9,- per stuk. En dan hebben we het over een DCC spoel/sein decoder met 16 uitgangen (goed voor 8 wissels of 5x 3 kleuren seinen)
Open Source Solenoid Decoder

En zo heb ik een 8 voudige DCC servo decoders zonder puntstukrelais, een 6 voudige servo decoder met puntstukrelais, S88 gnd en keerlus printjes. Loconet terugmelders worden op dit moment getest en die komen er ook bij. Ze zijn wel iets duurder te maken, ik denk ~€15 ofzo omdat er gewoon meer op zit.

Ik documenteer alles, ik maak handleidingen, aansluitschema's en ik maak instructie filmpjes. En ik heb uiteraard samples die je kan lenen. Dito voor een nieuwe nog te ontwerpen Fred opvolger.
Releases, source code, pcb files alles staat op deze git repo

Ik heb verder geen trademark of licentie dingetjes naast OSHW ed. Dus doe er mee wat je wilt.

Er vanuit gaande dat je 2 uitgangen per PTT relais nodig en 3.5 uitgangen (sommige seinen zullen cijferbakken hebben??) voor een NS lichtsein dan kom ik met jullie aantallen

300 bezetmelders, 230 wissels en 110 seinen

29 DCC decoders voor wissels
24 DCC decoders voor seinen
19 loconet terugmelders met current sense

Kom ik uit op een schatting van €762,-. En voordat ik op iemands tenen sta, ik verdien er niks aan 
Het is wel een grove schatting, afhankelijk van factoren kan het €100 mee of tegen zitten, maar het is iig geen €10.000 

En voor de beeldvorming, aanpassingen zijn bespreekbaar. Ik weet alleen niet of dit dan handig is om te doen, want ik ken jullie prints niet. Zelf denk ik aan redesign met 3.5mm plugbare kroonsteentjes en die je kan doorsteken naar volgende decoders en waaraan je een CDU kan hangen.


DCC decoders hebben wel het voordeel dat je ze lokaler bij de wissels in de buurt kan plaatsen. Dan krijg je veel minder draad en zo kan je geleidelijk je RJ45 dingen vervangen door een DCC decoder. En dito voor bezetmelders. Hoe korter de draden, hoe beter het is.

Zowel DCC als loconet zit op de IB, ik kan je alleen niet veel zinnigs vertellen over je VB6 applicaties. Als jij dat ding met de IB kan laten babbelen, kan je het wellicht werkend houden.

Ik heb zelf alleen ervaring met iTrain en daarmee kan je ook mooie emplacementen mee maken voor op de PC. Dat werkt naadloos via de IB met de bezetmelders, de handregelaars en de DCC decoders. Je kan verder dingen leuke dingen moet rijwegen en acties. iTrain ondersteunt ook de Z21 WLAN maus en daarmee ook de Z21 app. iTrain heeft zelf ook een app natuurlijk. Je kan er mee rijden, maar je kan je wisseltableaus ook op een client tablet draaien. Dan kan je een tablet rijwegen stellen. Dat is dan een optie.

Ik weet niet uit mn hoofd of ze WiThrottle ondersteunen. Dat zou me niet verbazen.

Mvg,

Bas

[AP3737]

Hi Bas en Klaas

@Bas: Dank voor je aanbod en bijdrage. Inderdaad is door "zelfbouw" veel geld te besparen. Het bedrag wat ik noemde ging uit van commercieel verkrijgbare producten. Dat willen we dus niet uitgeven.

Ik heb je links en websites bekeken, en ik moet zeggen dat ze er prima uitzien 
Misschien dat ik echter niet goed gekeken heb, maar ik kon allen .hex en gerber files vinden. Open Source betekent volgens mij dat de broncode / Schema en PCB ontwerp ook gedeeld worden. Dat is, voor zover ik kon nagaan, bij jou niet het geval.

@Klaas:

Dat zou je kunnen doen door de wissels stuk voor stuk te vervangen door b.v. motoraandrijvingen

De bedoeling is juist de huidige wisselaandrijving (=op basis van telefoonrelais) te behouden. Vervangen is veel werk, geeft geen echter verbetering en kost veel geld.

Een oorzaak kan zijn dat de telefoonrelais verkeerd gemonteerd zitten. Nu kan stof op de contacten blijven liggen. In een telefooncentrale werden ze gemonteerd met de contacten vertikaal, zodat stof er tussendoor kon vallen. Bovendien zat er een stofkap over een rek met relais, tenminste bij de telefooncentrale die ik ooit heb gesloopt omdat ik de relais mocht hebben. Voor een grotere betrouwbaarheid kun je ook meerdere contacten parallel zetten.

Wat stof betreft, heb je zeker een punt. Maar de telefoonrelais zijn nu eenmaal al op deze manier ingebouwd. Plastic kapjes hadden we nooit gehad / zijn inmiddels weg. Initieel is wel geprobeerd meerdere contacten parallel te zetten, maar dat was toch niet betrouwbaar. En omdat er toch al een apart relais moest komen om de 48V te schakelen, bleek het tweede contact daarvan prima voor de hartstuk polarisatie bruikbaar.

Groet, Aiko

[bask185]

Jawel hoor 

Ik heb voor het gemak een scheiding gemaakt voor releases en source code. Je kan het pad onder software volgen naar
/SOFTWARE/DECODERS/OSSD

PCB staat onder
/PCB/DECODERS_N_OCCUPANCY/OSSD/src/PCB/OSSD/

Mvg,

Bas

[AP3737]

Hi Bas
Ah, heeeeeel mooi 
Dan heb ik onvoldoende gezocht. 

Groet, Aiko

[AP3737]

Oplossingsrichtingen

Alhoewel de baanbesturing op dit moment prima voldoet, zijn er op termijn twee mogelijke problemen. Het eerste probleem is dat de huidige PCs verouderd zijn. Ze draaien nog Windows XP en gebruiken PIO kaarten op basis van ISA / PCI sloten. Het tweede probleem is dat er weinig leden zijn die in staat zijn de huidige Visual Basic 6 software te onderhouden en aan te passen.

Eind 2023 zijn er een aantal discussies geweest om mogelijke oplossingsrichtingen aan te geven. Er zijn drie richtingen geïdentificeerd. Twee daarvan worden op dit moment verder uitgewerkt en getest.

1: Behoud van de PIO kaarten.
De oude Windows XP PCs zouden door nieuwe W10 of W11 PCs met PCI express slots vervangen kunnen worden. PIO kaarten zijn nog wel verkrijgbaar. Ook is de VB6 programmatuur eventueel wel om te zetten naar VB-Net. Toch is deze mogelijkheid verworpen. Het probleem dat er weinig leden zijn die de bestaande software kunnen onderhouden, wordt immers niet opgelost. Maar vooral wordt het vasthouden aan PIO kaarten als weinig toekomstgericht gezien.

2: Overstap naar USB besturingskaarten
In plaats van PIO kaarten in de PC, kan ook gekozen worden voor parallel I/O via USB. Deze oplossing heeft als groot voordeel, dat er weinig aangepast hoeft te worden aan de bestaande VB6 programmatuur. Ook hier blijft het nadeel natuurlijk wel dat het probleem van software onderhoud nu niet wordt opgelost, maar naar de toekomst wordt doorgeschoven. Maar omdat deze oplossing eenvoudig uitvoerbaar lijkt te zijn, is besloten de komende tijd hiermee te experimenteren. In wezen zijn hierbij wederom twee varianten mogelijk. De eerste variant is zelfbouw, op basis van Arduino’s en I2C IO Extender ICs. Een prototype daarvan is ontwikkeld, en lijkt te werken. De tweede variant is het kopen van 24 kanaal USB-IO adapters, zoals die bijvoorbeeld door BMC Messsysteme GmbH verkocht worden. Een aantal van deze adapters zijn gekocht, en worden momenteel getest.

Een voordeel van deze gekochte adapters is dat ze ieder een uniek serie nummer hebben, en zo vanuit de software aangesproken worden. Als iemand wat USB stekkers eruit haalt en er later weer instopt, dan blijft het geheel goed werken, ook al wordt de stekker volgorde omgedraaid. Natuurlijk waren we ook nieuwsgierig wat er nu precies in een dergelijke adapter zit, en konden we de verleiding het geheel open te maken niet weerstaan. 


3: Overstap naar DCC besturing
Het mag duidelijk zijn dat deze oplossing het meest toekomst gericht is, maar ook het meeste werk kost. De grootste uitdaging zal zijn de veranderingen in kleine, reversibele stapjes te doen. De rijavonden moeten gewoon ongestoord kunnen doorgaan.

Het vervangen van de bestaande electronica door DCC electronica lijkt niet het grootste probleem. Er zijn, om te testen, zelfs al wat decoder printjes ontworpen en (door JLCPCB) geproduceerd. Het grootste probleem lijkt de aanpassing van de huidige VB6 software, zodat met DCC centrales gesproken kan worden. Daarover de volgende keer meer.

Groet, Aiko

[AP3737]

De vorige keer heb ik aangegeven dat de grootste uitdaging zit in het aanpassen van de bestaande VB6 software, zodat het met de wissel / terugmeld centrales kan praten.

Ik schrijf bewust “centrales” in de meervoudvorm, omdat ik een voorstander ben van, wat mijn vroegere baas noemde, “separation of concerns”. Die slogan wil zeggen dat je geen dingen gaat vermengen die niets met elkaar te maken hebben. Concreet: voor het schakelen van wissels en voor het ontvangen van bezetmeldingen kies ik het liefst voor gescheiden centrales. Hoe minder verschillende taken een centrale te doen heeft, hoe minder er mis kan gaan. Ik ben daar bij mijn eigen baan 20 jaar geleden tegenaan gelopen: mijn toenmalige Windows XP PC hield zich niet altijd aan de RS-232 (CTS) flow-control regels, waardoor berichtjes verloren gingen als de PC en (Lenz LZV100 / LI100F) centrale gelijktijdig wilden zenden. Door gescheiden centrales te nemen voor wissels en voor terugmeldingen, kan er bij grote banen met veel data verkeer minder misgaan.

Voor communicatie tussen PC en centrale is gekozen voor XpressNet, met daaraan toegevoegd een aantal (XpressNet achtige) Z21 commando’s. Door deze keuze hebben we redelijk wat opties voor wat betreft centrales. Uiteraard kunnen we Lenz centrales gebruiken, maar ook verschillende anderen, waaronder Digikeijs / Yamorc en Roco. Daarnaast zou ook zelfbouw op basis van de Z21PG mogelijk moeten zijn.

De keuze voor XpressNet heeft nog een belangrijke reden: een aantal van de leden die zich met digitale zaken bemoeien hebben thuis ook XpressNet. Dat maakt testen eenvoudiger.

De wissels zelf worden geschakeld met behulp van DCC Accessory Commands. Bijna iedere decoder kan daar mee omgaan, en dat zal over 10 à 20 jaar waarschijnlijk nog wel zo zijn.

Misschien ten overvloede: het is niet de bedoeling dat de treinbesturing volledig geautomatiseerd wordt. De “machinisten” blijven dus zelf hun treinen besturen; de VB6 software doet dat niet. RailCom terugmelding is daarom ook niet nodig; een simpele melding of een baanvak bezit is of niet, is voldoende. Als we wel RailCom terugmelding hadden gewild, dan was XpressNet natuurlijk onvoldoende en hadden we misschien serieus naar iets als BIDIB moeten kijken. In een volgende bijdrage kom ik echter nog op bezetmelding terug, omdat dat misschien de lastigste keuze is.

Een andere belangrijke keuze is het laag 1/2 protocol tussen PC en Centrale. De eerste vraag die dan beantwoord moet worden, is USB of netwerk? En als je voor netwerk kiest, zijn de volgende keuzes bedraad (802.3) of WIFI (802.11), en TCP dan wel UDP. Mijn eigen voorkeur gaat, als het even kan, richting bedraad netwerk en TCP. Desondanks zullen we proberen alle opties open te houden.

Bij netwerken is galvanische scheiding tussen de verschillende apparaten standaard. Bij USB is dat niet altijd zo. Bij kleine banen is galvanische scheiding waarschijnlijk niet nodig, maar bij grote banen, die veel gevoeliger zijn voor storingen, wel. Natuurlijk kan je USB ook achteraf voorzien van USB-isolatoren, maar bij netwerken is dit standaard.

Een tweede voordeel is dat je communicatie over netwerken eenvoudig met tools zoals Wireshark kan analyseren. Je ziet dan precies welke berichtjes er tussen PC en centrale worden uitgewisseld, waardoor het opsporen van fouten wordt vereenvoudigd. Tegenwoordig kan Wireshark ook de data over USB-poorten wel monitoren, maar dat gaat toch minder comfortabel.

Een derde voordeel is dat netwerkinterfaces meerdere parallelle verbindingen ondersteunen. Dit is niet alleen handig voor monitor en analyse software, maar vooral ook omdat nu de bezetmeldingen van de trajecten tussen twee stations gehoord kunnen worden door de PCs van beide stations. Bij USB, maar ook in de huidige situatie waar we nog PIO kaarten hebben, is dat niet mogelijk, en is er een centrale server nodig voor de trajecten tussen de stations.

Een vierde voordeel is dat netwerk interfaces ieder een eigen adres / lokale naam hebben (mits ze juist zijn geconfigureerd). Hierdoor kan je netwerk stekkers er uit trekken, en later er gewoon (desnoods in een andere poort) weer in stoppen. Bij USB is dat vaak niet mogelijk. Ook heeft USB het nadeel dat er verschillende snelheden mogelijk zijn; als de baudrate verkeerd is ingesteld, werkt niets.

Tenslotte is data-uitwisseling over een netwerk zeer betrouwbaar, mits er gebruik wordt gemaakt van het Transport Control Protocol (TCP). Dit protocol zal transmissiefouten detecteren, en herstellen. Ook met UDP kan wel betrouwbaar gewerkt worden, mits het onderliggende netwerk betrouwbaar is. Dat is normaal gesproken het geval bij bedrade netwerken, maar niet bij altijd bij WIFI. Voor mij is het daarom ook niet goed te begrijpen dat Roco voor UDP heeft gekozen, te meer daar ze de Z21 in sets met WIFI routers aanbieden.

Dat was het weer voor vandaag.
Groet, Aiko

[bask185]

Hierdoor kan je netwerk stekkers er uit trekken, en later er gewoon (desnoods in een andere poort) weer in stoppen. Bij USB is dat vaak niet mogelijk.

Dat kan opzich wel bij USB, maar dat hangt van je hardware en een beetje software af. Als je bijvoorbeeld een originele Arduino pakt en een Chinese kopie, zie je de naam arduino uno terugkomen in je device manager bij de originele. Waarbij de Chinese verschijnt als CH340 (de USB TTL chip). Die originele arduino's hebben programmeerbare FTDI USB <> TTL chips. Die kan je dan zelf programmeren en voorzien van iets van een unieke ID waardoor je niet meer afhankelijk bent van willekeurig uitgedeelde com poort nummers. Maar zoals je waarschijnlijk al doorhebt. Dat is veel werk waarbij ethernet meer plug n play is 

een aantal van de leden die zich met digitale zaken bemoeien hebben thuis ook XpressNet. Dat maakt testen eenvoudiger.

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.
Terugmelders, (heb je dat nog niet verteld of zitten die ook op de PIO kaarten en heb ik het niet begrepen) Xnet kent geen terugmelders.
Dus naast PC - centrale interactie, is er ook nog een fysieke Xnet bus? Gebruiken jullie ook nog multimausen oid?
Want ik zie dan niet in wat het voordeel is van het Xnet protocol tov het Lnet protocol als je alleen kijkt naar de PC <> centrale(s) interactie.
vziw gebruikt die IB ook geen Xnet voor PC communicatie?

Ik heb gespeeld met loconet en xpressNet en ik vind loconet ansich wat makkelijker. Vooral als je zelf je dingen maakt, kan je gewoon makkelijker berichten toevoegen. Ik weet niet hoe Xnet spul zoals een Lenz centrale nou omgaat als dat ding een bericht ziet wat die niet herkent. Volgens mij kan bij Xnet de centrale het bericht gewoon tegenhouden als de payload volgens hem niet ok is.

Als je perse Xnet nodig heb voor iets, zou ik eerder kijken naar een DR5000 / yamorc / Z21 centrale die het beiden hebben.
Of anders iets van hubjes die elk een Xnet <> Lnet omzetter is zodat je zowel freds als multimausen in dezelfde hub kan prikken (wat wel lichtelijk risicovol is)

Maar ik ben wel nieuwsgierig geworden.
Treinen en Freds gaan op de IB.
Accessoires gaan over de PIO kaarten.
Terugmelders die gaan ook over de PIO kaarten?
Heb je dan 2 centrales waaronder de IB en de PIO interface aan de PC hangen?

Mvg,

Bas