Wat nodig voor eigen software te schrijven?

[Yannick82]

Ik ben sinds kort bezig met model treinen en heb intresse in zowel elektronica als het bouwen van scenery.
Ik ben software engineer als beroep en vind het ook altijd zeer leuk om dat te combineren met mijn hobby. Toen ik vroeger bezig was met slotcars heb ik ook mijn eigen software geschreven die snelheid, ronde tijden enzo opsloeg zodat ik kon vergelijken.

Een van de dingen die ik enorm graag zou willen doen met de treinen, is mijn eigen "centrale" schrijven. Sommive mensen spenderen uren, weken, jaren een scenery. Ik vind het leuk om software te schrijven...
Wat ik niet goed weet, is wat er allemaal voor nodig is? Welke hardware componenten enzo. Bestaan er kant en klare controllers die ik via de pc kan aansturen via een gedocumenteerde API ofzo?

Momenteel is alles wat ik heb van Marklin en hun "central station" is enorm gesloten. Ook al kan je dat via de PC bedienden, ze hebben geen APIs ofzo waarbij je je eigen software kan schrijven.

Ik vermoed dat ik dan naar het standaard DCC protocol moet gaan? Ik vermoed ook dat de locos van Marklin DCC ondersteunen, ook al hebben ze een MFX decoder?

Ik heb projecten gezien zoals DCC++EX waar je met een Arduino bepaalde dingen kan doen en waar je dan commandos naar kan sturen via PC ofzo.
Dit lijkt me al een stap in de goeie richting.

Alle info die me op weg kan helpen zou enorm geacppreciëerd worden.

[Karst Drenth]

Hoi,

Met alleen Software kom je er niet

Maar "API's" zijn er voldoende: https://www.railcommunity.org/index.php?option=com_content&view=article&id=49&Itemid=61

Weliswaar zeer low-level, maar uitgebreid en duidelijk.

Wil je een niveau "hoger" ( je koopt dan de "controller", zoals jij het noemt ) dan vind je hier wel iets:

Loconet:      https://www.digitrax.com/static/apps/cms/media/documents/loconet/loconetpersonaledition.pdf
XpressNet:  https://www.lenz-elektronik.de/src/pdf/Lenz_XpressNet_Doku.pdf
Z21:           https://www.z21.eu/media/Kwc_Basic_DownloadTag_Component/47-1652-959-downloadTag/default/69bad87e/1646977660/z21-lan-protokoll.pdf

Grtzz & suc6,
Karst

[bask185]

Hallo Yannick,

Wat ik niet goed weet, is wat er allemaal voor nodig is? Welke hardware componenten enzo

Je kan beginnen met een arduino Uno + motor shield. Dan hoef je (nog) niks te solderen.

Ik heb zelf vanuit scratch een DCC centrale gemaakt. Dat heb ik nooit helemaal afgemaakt. Het werkte wel, maar ik moest nog finetuning dingetjes doen met nieuw pakketjes bufferen ed. 
code op github
draaje op bnls

Nu kan je software schrijven, software schrijven en nog meer software schrijven. Je kan software schrijven om DCC te doen, maar het is tevens ook al gedaan met DCC++ en nmra_dcc library. Een computer programma schrijven? -> rocrail, koploper, iTrain, jmri, mijn processing GUI (ooit een keer gemaakt).

Zoals Karst zei, je kan het iets hoger level opzoeken. Je kan dan met een 'standaard' centrale spelen zoals z21 of multimaus + roco booster en dan met een arduino oid hiermee interfacen via XpressNet. Dit bespaart je zelf de moeite om het DCC wiel voor de 34 keer uit te vinden en dan kan je die tijd gebruiken om iets anders te doen. Nu heeft iemand dus ook al een werkende XpressNet library geschreven, dat is dus ook al gedaan. Of je kan een wat meer uitgebreide centrale kopen zoals een Z21 of DR5000 en met loconet gaan spelen, maar ook hier van zijn er al libraries beschikbaar. Ik zie het gebruik van andermans library tegenwoordig als het versnellen van het proces. Ik zou zelf ook een XpressNet library kunnen maken, maar dat gaat me erg veel tijd en moeite kosten en nu besteed ik die tijd en moeite in andere handige dingetjes.

Met DCC++, loconet en XpressNet kan je dus zelf met een arduino iets van een pendelautomaat maken of iets anders leuks. Als je nog wat inspiratie zoekt:
multimaus enhancer
digitale pendel apparaat
Nx schakelpaneel ga ik eerdaags weer eens een update geven
Nieuwe handregelaar
En denk ook aan dingen naast de baan.
Led driver

En ik ben recentelijk veel bezig met mijn all-in-one project. Daarin combineer ik alles omtrent input en output met XpressNet, Loconet en DCC in een programma. Dit loopt van schakelpanelen en ledjes naar servo decoders, seindecoders en terugmelders.
https://github.com/bask185/modelRailroad

En ik heb thuis een analoge baan werkend op een multimaus via XpressNet
https://forum.beneluxspoor.net/index.php?topic=94212.msg3222270926#msg3222270926
Code en pcb ontwerpjes

Zoals je ziet, valt er dus heel veel te programmeren, het is nu de vraag wat precies wil je programmeren.

Mvg,

Bas

[henk]

Ik vermoed dat ik dan naar het standaard DCC protocol moet gaan? Ik vermoed ook dat de locos van Marklin DCC ondersteunen, ook al hebben ze een MFX decoder?

Pas vrij recent eigenlijk. Zeg pakweg de laatste vijf jaar. Daarvoor eigenlijk nooit.
Märklin gebruikt sinds een jaar of 15 wel de Mtc21 decoderplug. Dat maakt eventueel wisselen van decoders gemakkelijker.

[Yannick82]

Bedankt voor de info. Is al zeer handig...

Eigenlijk, wat ideaal zou zijn voor mij is dat ik gewoon een "centrale" koop waar ik via een library gewoon commandos naar kan sturen als in "loco A snelheid X" of "sein A stand 1".
Het programmeren van die commandos en vertalen naar de signalen die op het spoort gezet worden, heb ik minder intresse in. Alhoewel dit laatste zeer intressant en leerrijk kan zijn maar ik vermoed dat dit een zwart gat zal worden en ik teveel tijd daarin ga steken en te weinig echt met de treinen bezig ga zijn.

Als bovenstaande niet bestaat of lukt, dan is het volgnende niveau om inderdaad met een arduino aan de slag te gaan en eens dieper in te gaan op DCC++ Ex of iets anders gelijkaardigs. 

[Yannick82]

De Z21 lijkt me wel een goeie optie. De documentatie is goed rond het protocol wat ideaal is..

Wat ik echter niet weet, werkt die op C-rails van Marklin? Het zijn de enige rails die ik heb...

Wat is ook niet snap is dat veel programmas zoals RocRail and JRMI support hebben voor de CS3 van Marklin. Hoe doen die dat? Is dat puur reverse engineering want die commandos zijn toch niet gedocumenteerd?
Moest ik mijn eigen systeem kunnen schrijven dat kan communiceren met de CS3, dan koop ik gewoon die maar bij gebrek aan documentaite lijkt me dat niet echt handig... Ook libraries vind ik niet echt daarvoor...

[bask185]

De Z21 is duur maar heeft loconet, de z21 is goedkoop maar heeft geen loconet. Je kan ook een DR5000 die heeft elke bestaande bus known to us aan boord en kost slechts €150,- in de aanbieding.

werkt die op C-rails van Marklin

Irrelevant. Je kan elke centrale combineren met elke rails.

Wat is ook niet snap is dat veel programmas zoals RocRail and JRMI support hebben voor de CS3 van Marklin

Marklin heeft ooit ergens hun Cs2 can bus protocol naar buiten gebracht. Die is niet of niet veel veranderd met de Cs3. Als je zoekt, kan je die vinden. Behalve de fysieke canbus doet de Cs3 ook het canbus protocol over TCP IP sturen. Hiermee doen die programma's babbelen met een CS.

Een wiel wat er nog niet is, en niet zo heel moeilijk moet zijn is een XpressNet of Loconet converter naar Cs3 can bus. De EcosII heeft wel een can bus <> loconet converter. Het zou wel grappig zijn als je ff een XpressNet bus aan een Cs3 kan koppelen zodat je multimausen kan toevoegen aan hun crappy systeem.

Ik weet ook dat mensen een arduino hebben ingezet als mobile station 1 slave. Deze arduino communiceerde via can bus met de mobile station 1 en kon zodoende dingen aansturen. Dit werd 'Railduino' genoemd en daar kan je ook code van vinden. Meestal google ik dit voor mensen, maar dat red jij wel  . Er zit volgens mij wel verschil tussen de canbus protocollen van de mobile station en de Cs2/Cs3. Ik kan tot op heden nog steeds niet mijn Ms1 in mijn cs2 prikken  .

Mijn cs2 wil ik overigens wel tijdelijk afstaan in bruikleen als je er iets mee wilt doen. Bij mij ligt die toch maar in een kast te verstoffen. Ik heb ook een canbus shield voor een arduino uno liggen.

Mvg,

Bas

[Yannick82]

Als ik het goed begrijp heeft de DR5000 alles wat de Z21 heeft en nog meer? Wat is dan het verschil tussen de Z21 en de DR5000 en waarom zou je dan de Z21 kopen, zeker als je het prijsverschil ziet... De DR5000 kan je instellen zodat hij de Z21 simuleert en je zelf de Z21 apps kan gebruiken.

Kan ik dan ook de Z21 accessoires gebruiken op de DR5000 zoals de Z21 Detector voor detector rails?

En aangezien de DR5000 in Z21 mode kan gebruikt worden, vermoed ik dat ik de Z21 commandos via UDP kan sturen naar de DR5000?

Als dit allemaal kan, dan is de DR5000 een zeer goeie optie en kan ik vrij vlug focussen op wat ik zelf wil schrijven zonder het wiel opnieuw te moeten uitvinden. Alhoewel hetgeen ik wil schrijven ook al bestaat maar het gaat hier over het process en het plezier natuurlijk

[meino]

Als je met Canbus aan de gang wil gaan, kun je ook mijn Canbus draadje eens lezen.

Groet Meino

[Patrick Smout]

Hoi Yannick,

uitdagend project. Als ik het goed begrijp wil je meer de kant van het besturingsprogramma op PC (tablet?) zelf schrijven?
Ook voor mij is de software (en elektronica) rond modeltreinen wat me het meeste aanspreekt. Beroepshalve werk ik in de branche van de custom made besturingen (ontwikkeling en productie). Als dusdanig heb ik zelf het commandstation gebouwd (DCC Command Station gepubliceerd in Elektor 09/2008), alle terug- en bezetmelders en wissel/sein decoders. Daarnaast ben ik, met de nodige rustmomenten, ook al geruime tijd bezig aan de PC besturingssoftware.
Het evenwicht dat ik gevonden heb is om gebruik te maken van een standaard kant-en-klaar PC software (ikzelf gebruik koploper) en daar al vast mee aan de slag te gaan. Op die manier kan je op korte termijn treinen laten rijden en ook aan de baan bouwen. In tussentijd kan je ook een start maken met de eigen software. Op de momenten dat je geen zin hebt om te programmeren neem je gewoon je standaard software.
Mijn baan staat op zolder en het is toch wel vervelend als je altijd op zolder moet zitten, zowel voor te bouwen, rijden als voor het programmeren. In de zomer te warm en vooral niet leuk voor de mede-huisgenoten. Ik heb dus ook heel vroeg in het traject al een volledige software simulator gebouwd voor de baan. Zowel koploper als mijn eigen software kunnen via een virtuele seriële poort (en P50X protocol) met de simulator praten zonder dat ze er erg in hebben dat ze niet met mijn eigen commandstation praten. E.e.a. maakt dat ik perfect de software kan ontwikkelen waar ik ook wil en het is bovendien ook veel veiliger voor de treinen  . Zowel de simulator als de eigen besturingssoftware lezen hetzelfde "model" in van mijn layout (XML file).
Ik heb een conversieprogramma geschreven om de koploper database (.ZIP backup files) om te zetten naar de XML configuratiefile die ik gebruik in mijn software. De grafische weergave van de layout neem ik niet over maar de config van blokken, wissels, locs en ijking, vaste en variabele routes etc  wordt allemaal automatisch omgezet. E.e.a. maakt dat ik de wijzigingen die ik maak in de standaard-pc-software aan de config van de layout ook direct kan gebruiken in mijn eigen software.
Momenteel ben ik met de eigen software zover dat treinen netjes rondrijden met met geijkte snelheden in vaste/variabele routes met de nodige snelheidsbeperkingen etc. en ook mooi (leren) remmen. De stand van de treinen wordt momenteel nog niet bewaard als het programma afgesloten wordt. Met de simulator is dit geen probleem omdat je snel e.e.a. bij het begin goed zet maar op de echte baan in feite een hels karwei. Volgende stap is nu dus het wegschrijven van de stand van de treinen/status van blokken bij het stoppen van de layout/afsluiten van de besturingssoftware.
Het is voor mij ook niet de bedoeling alle mogelijkheden van de standaard-pc-software na te bouwen en pretendeer zeker en vast ook niet dat dit voor mij bereikbaar is en/of nodig/beter is. Ik vind het gewoon leuk om te doen.
Alles bij elkaar is dit een project dat al meer dan 10 jaar loopt en verre van af is (maar dat hoeft voor mij ook niet).

mvg, Patrick Smout

[bask185]

Wat is dan het verschil tussen de Z21 en de DR5000

The one thing dat een DR5000 niet kan, is het oudere MM2 protocol spreken voor d'n marklin treintjes. Helaas heeft marklin veels te lang gewacht om ook DCC in te bouwen. De Z21 kan dit wel. De Dr5000 heeft ook geen can bus, maar dat is dan ook niet echt een gemis ofzo.

Kan ik dan ook de Z21 accessoires gebruiken op de DR5000 zoals de Z21 Detector voor detector rails?

Dat hangt er van af. Die Z21 detector heb je in Can bus variant die gaat voor zover ik weet niet op de Dr5000, maar de R-bus terugmelder kan er wel op.

Je kan verschillende merken met elkaar combineren, zolang de apparaten maar de zelfde bus aan boord hebben. Je kan van wel 10 merken een DCC decoder kopen die 100% interchangeable zijn. Meestal doet men zichzelf een plezier en koopt spul van digikeijs omdat die ook alles verkopen voor minder geld.

Je hebt verschillende bussystemen voor input (bezetmelders), output (dcc decoders) en beiden (loconet). De S88 bus, R-Bus van roco en de RS bus van Lenz zijn slechts alleen voor bezetmelders. En je kan ze dan nog 'misbruiken' om bijvoorbeeld een schakelpaneel mee te maken.

Dan heb je verder nog de XpressNet bus. XpressNet is bedoeld voor handregelaars en schakelpaneel spul, je kan er ook accessoire decoders van maken zoals ik gedaan heb op mijn analoge baan. Op de DR5000 zijn R-bus en XpressNet samengevoegd in 1 bus. Dat kan technisch omdat ze beide met Rs485 werken. De R-bus lijkt onderhuids heel erg op XpressNet.

Nog een 'wiel' wat je kan uitvinden. Op een Tsjech na (wat ik even niet kan vinden) zijn er nog geen open source projecten om met de R-bus te werken. Die R-bus melders zijn allemaal duur en ik denk dat je daar mensen blij mee kan maken. Hetzelfde kan je ook doen met de RS bus van Lenz daar weet ik helemaal niks over tbh.

Al deze bussen zijn afhankelijk van een centrale. Loconet is hier een uitzondering omdat dat peer 2 peer is. Je kan in theorie een zelf gemaakte loconet terugmelder direct een zelf gemaakte loconet sein decoder laten aansturen. Dat is waar ik momenteel mee bezig ben. Dit werkt dus buiten een centrale om, je hebt dan alleen nog iets van een voeding nodig (krijg je normaal uit de centrale).

Zo kan je dus bijvoorbeeld een analoge baan aanleggen waarbij alle wissels, schakeltableaus, ledjes, bezetmelders, relais, servo's en de hele mikmak op loconet werkt en waarom, nou het is makkelijk bekabelen en de elektronica is modulair en dus ook recyclebaar.

Je moet ook bedenken, je hebt pas bezetmelders nodig als je er ook iets mee wilt doen. Centrales zoals een DR5000 en Z21 sturen alle bezetmeld informatie door naar een computer waarop dan een programma zoals iTrain of koploper draait. Het programma gebruikt dan de bezetmelders om bij te houden waar welke trein is. Heb je wel een Z21 maar geen computer dan heb je ook geen behoefte aan een bezetmelder.

Verder kan je bezetmelders gebruiken om simpelweg ergens een ledje op te lichten op een schakelpaneel van bijvoorbeeld een schaduwstation.

En een Central station of EcosII die hebben elk intern een layout waarop je bezetmelders kan zien. Deze bezetmelders kan je dan in die centrale ook koppelen aan bijvoorbeeld een sein en/of een remmodule. Deze centrales kunnen ook een pendeldienst maken zonder een extra computer.

Ik zou goed nadenken over hoe je baan wilt aansturen. Ik vind een baan die vol automatisch rijdt op iTrain erg saai. Dat spreekt mij niet aan. Wat ik wel nog interessant zou vinden is een computer gebruiken voor slechts de grafische weergave. Daar kan je bijvoorbeeld iTrain ook voor gebruiken. iTrain kan dan je treinen volgen en je kan bepaalde dingen zoals wisselstraten en rijwegen realiseren.

Volgens mij kan dat ook met JMRI allemaal, dat heeft een wat hogere hobby gehalte en komt ook met arduino programma's. Ik denk dat JMRI daarom leuk is voor je om op te zoeken.

Mvg,

Bas

[Yannick82]

Het evenwicht dat ik gevonden heb is om gebruik te maken van een standaard kant-en-klaar PC software

Dat is net het omgekeerde van wat ik wil
Ik zoek eigenlijk een kant en klare centrale zodat ik me kan focussen op het schrijven van software.

Ideaal is het een module waar ik commandos naar kan sturen, of het nu via UDP, TCP, REST API, SDK,... maakt niet veel uit.
Ook moet ik de bezetting kunnen opvragen zodat ik signalen en wissels kan aansturen.

Mijn doel is om het volledig automatisch te laten lopen.
Neem nu bijvoorbeeld een dubbele ovaal waarbij ja van de buitense naar binnen kan en omgekeerd door middel van wissels.
Ik wil dan software schrijven waarmee ik de wissels kan bedienen, de treinen kan aansturen en ook een automatische time table waarbij bijvoorbeeld de trein 2 rondjes de buitenste ovaal doet en daarna wisselt naar binnen. Daarbij moet ik dan rekening houden met de positie van de andere trein en seinen zetten en de trein correct laten stoppen indien nodig.
Ik weet dat dit perfect kan met iets als een CS3 of Z21 in combinatie met RocRail of andere software maar dat is nu net hetgeen ik zelf wil doen.

Momenteel lijkt me de Z21 een goeie optie, alsook de DR5000.
Doordat ik ook nogal vrij nieuw ben in de hobby en sommige zaken nog niet 100% duidelijk zijn, neig ik meer naar de Z21 omdat de documentie goed is en als ik hun componenten koop, ik ook gemakkelijk kan vinden hoe ze met elkaar te doen samen werken.
Misschien niet de meeste goedkoopste maar geef me mss wel de meeste kans op success.

[Patrick Smout]

Dat is net het omgekeerde van wat ik wil
Ik zoek eigenlijk een kant en klare centrale zodat ik me kan focussen op het schrijven van software.

Dag Yannick,

ik denk dat we wel degelijk hetzelfde proberen te bereiken maar ik kan me niet van de indruk ontdoen dat ik me niet duidelijk genoeg uitgedrukt heb, of je me niet helemaal begrijpt, of mijn reactie niet volledig gelezen hebt.
Wat ik bedoel is dat ik kant-en-klaar software voor de PC gebruik voor de momenten op te vangen dat ik wil rijden met de baan en niet wil programmeren.
Het ontwikkelen van een PC besturingssoftware doe je niet in 1-2-3 en in tussentijd wil ik ook de treinen eens automatisch zien rijden 
Ik heb in het verleden gekozen voor een zelfbouwcentrale(goedkope centrales waren er toen niet) maar het (al wat oudere) protocol tussen PC en mijn zelfbouwcentrale (P50x) is standaard op bv een Intellibox en een aantal andere zelfbouw/commerciële centrales. M.a.w. , mijn eigen PC software werkt ook prima samen met een aantal standaard centrales net zoals de kant-en-klaar programma's.

Kies wel voor een PC software systeemopzet en taal waar je wat controle hebt over timing. Rest API's etc is allemaal wel leuk maar besef dat een trein op schaalsnelheid 120km/u op de baan 38cm/sec aflegt. Als je die netjes wil laten remmen en laten stoppen op bv 5mm nauwkeurig is juiste timing en controle over de timing een aandachtspunt. Ook de vertraging tussen het optreden van een bezetmelding op de baan en het zichtbaar worden in de eigen software is een aandachtspunt net zoals de mogelijke afwijking op de vertraging die er kan zitten op het verschijnen van de melding.
In mijn software is er een intern gesimuleerde treinpositie in een blok. De eenheid is nm/ms (nanometer per milliseconde). Elke 50ms wordt een gewijzigde snelheid van een loc vanuit de PC doorgezonden naar het commandstation. Op dag 1 ook nooit gedacht dat ik dit zou moeten aanhouden.

Bovenstaan verhaal illustreert ook waarom ik gebruik maak van een baansimulator. Dit soort zaken krijg je erg moeilijk goed als je niet kan simuleren. De simulator geeft bv ook loginfo over het activeren van bezetmelder (met timestamp tot op een millisec.). Zo kan ik perfect zien waar er werk aan de winkel is en achterhalen waarom de loc soms vroeger/later stopt op een punt.

mvg, Patrick

[Yannick82]

Wat ik bedoel is dat ik kant-en-klaar software voor de PC gebruik voor de momenten op te vangen dat ik wil rijden met de baan en niet wil programmeren.
Het ontwikkelen van een PC besturingssoftware doe je niet in 1-2-3 en in tussentijd wil ik ook de treinen eens automatisch zien rijden 

Inderdaad, dat was me niet helemaal duidelijk.
Ik zou inderdaad ook soortgelijke software gebruiken om met de treinen te rijden terwijl ik mijn eigen software aan het ontwikkelen ben.
Daarom dat ik ook naar de Z21 aan het kijken ben. Die heeft software, is compatibel met tal van software en heeft officieel gepubliceerde documentatie over hun protocol wat ik via de pc kan aansturen adhv UDP packets.

Kies wel voor een PC software systeemopzet en taal waar je wat controle hebt over timing. Rest API's etc is allemaal wel leuk maar besef dat een trein op schaalsnelheid 120km/u op de baan 38cm/sec aflegt. Als je die netjes wil laten remmen en laten stoppen op bv 5mm nauwkeurig is juiste timing en controle over de timing een aandachtspunt. Ook de vertraging tussen het optreden van een bezetmelding op de baan en het zichtbaar worden in de eigen software is een aandachtspunt net zoals de mogelijke afwijking op de vertraging die er kan zitten op het verschijnen van de melding.
In mijn software is er een intern gesimuleerde treinpositie in een blok. De eenheid is nm/ms (nanometer per milliseconde). Elke 50ms wordt een gewijzigde snelheid van een loc vanuit de PC doorgezonden naar het commandstation. Op dag 1 ook nooit gedacht dat ik dit zou moeten aanhouden.

Dit is idd ook al iets waar ik aan gedacht heb en wat belangrijk is. Dit is namelijk ook een reden waarom ik zelf iets wil schrijven. Ik wil wat experimenten met die timings, meten hoe lang wat doert en zien wat ik er dan praktisch mee kan aanvangen.

Bovenstaan verhaal illustreert ook waarom ik gebruik maak van een baansimulator. Dit soort zaken krijg je erg moeilijk goed als je niet kan simuleren. De simulator geeft bv ook loginfo over het activeren van bezetmelder (met timestamp tot op een millisec.). Zo kan ik perfect zien waar er werk aan de winkel is en achterhalen waarom de loc soms vroeger/later stopt op een punt.

mvg, Patrick

Wat is de baansimulator? Daar heb ik nog niets van gelezen denk ik... Is dat een simulator waarbij je je fysieke baan kan simuleren en en virtueel treinen kan doen rijden/aansturen alsof het echt is waardoor je geen zorgen moet maken dat fouten in je software tot botsende treinen lijden? Indien, welke software heb ik daarvoor nodig? Lijkt me zeker goed om dat te beijken.

[Patrick Smout]

Dag Yannick,

de "baansimulator" is een PC software die ik zelf geschreven heb. Deze software simuleert idd de fysieke baan en het commandstation. In mijn geval elk command station dat het P50x protocol praat.

Dit is de normale situatie (ipv DR5000 kan je willekeurig ander commandstation nemen dat je gebruikt zoals CS, IB, Z21, etc

PC-Software <-> DR5000 <-> Fysieke baan

Met de simulator

PC-Software <-> PC Baan Simulator

De communicatie tussen de PC-Software en de PC Baan simulator maakt ook gebruik van P50x maar loopt niet via een fysieke seriële poort maar via  virtuele seriële poorten. Op de PC is een bridge gemaakt tussen 2 virtuele seriële poorten. Zowel de besturingssoftware als de simulator praten via een virtuele seriële poort en de bridge met elkaar. Door nu in mijn besturingssoftware een echte poort te kiezen ipv de virtuele kan ik met de fysieke baan praten.
Mijn simulator  leest ook dezelfde XML configbestanden als de besturingssoftware maar doet gewoon andere dingen. Als de locsnelheid bv niet 0 is verplaatst de loc zich door een blok en gaat naar een volgende blok afhankelijk van de wisselstand. Onderweg komt de loc melders tegen en deze triggers worden dan via het P50x protocol en de virtuele seriële poort doorgegeven naar de besturingssoftware. Deze verschillen in niets van de echte meldingen dus ik heb een perfecte simulatie van wat ik op de echte baan zou zien.
De UI van de simulator is niet meer dan een logboek van de gebeurtenissen.
Nog even dit, de meest PC besturingsprogramma's kunnen ook een simulatie doen wat op zich best handig is (m.a.w. de treinen laten rijden zonder dat de baan er aan hangt). Dit wordt volledig afgehandeld binnen de PC besturingssoftware en er komt geen communicatie aan te pas. Dit is anders dan mijn oplossing waar de simulator werkelijk een afzonderlijk stukje PC software is dat kan praten met een PC besturingsprogramma en dat zich gedraagt als een baan. Mijn stukje software heeft als doel om de besturingssoftware op punt te krijgen. De simulator is ook realatief domme software. De echte "intelligentie" zit in de besturingssoftware. De simulator reageert maar op wat de besturingssoftware uitstuurt. Het is wel zo dat de locs in de simulator ook rijden met geijkte snelheden en een massavertraging hebben voor versnellen/vertragen. Het moet allemaal dus wel wat overeenkomen met de echte baan.