Voor de dubbele engelsman heb je de uitdaging dat de uitvoering verschilt. Fleischman en minitrix gebruiken 1 aandrijving met 1 adres. Dan heb je twee standen. Peco is feitelijk 2 in elkaar geschoven wissels. Dus 2 aandrijvingen met elk een eigen adres. En in principe 4 standen.
Dus dat wordt wel een ding als je er aan begint.
Java Central Station
Fleischman z21 en YD7001 en DCC-EX centrales.
Mobiele baan 2x 100x50 cm met YD7001, DR4018, DR4088 en DCCNext.
https://hugo.vanderkooij.org/modelspoor/
Mobiele baan 2x 100x50 cm met YD7001, DR4018, DR4088 en DCCNext.
https://hugo.vanderkooij.org/modelspoor/
Hallo,
Na een lange test periode, en 2 erg leuke presentaties die ik heb mogen geven, kan ik met enig gepaste trots aankondigen dat ik Release 0.0.3 van JCS heb gepubliceerd.
In deze release zit de ondersteuning van zowel de Marklin CS 2/3 als ESU ECoS ingebouwd. Ook kun je met deze versie automatisch rijden.
Ik heb nu ook veel tijd besteed aan het maken van een handleiding, zodat het een completer product aan het worden is, hopelijk niet meer alleen voor nerds
Kortom testers gezocht! Ondanks dat ik veel tijd heb besteed aan het testen van JCS, dit op verschillende platformen heb uitgeprobeerd en op mijn eigen baan met 9 locomotieven werkt is dit natuurlijk nog geen garantie dat het overal werkt, althans dat is het streven
Mocht je het leuk vinden JCS uit te proberen graag!.
Groeten,
Frans
Na een lange test periode, en 2 erg leuke presentaties die ik heb mogen geven, kan ik met enig gepaste trots aankondigen dat ik Release 0.0.3 van JCS heb gepubliceerd.
In deze release zit de ondersteuning van zowel de Marklin CS 2/3 als ESU ECoS ingebouwd. Ook kun je met deze versie automatisch rijden.
Ik heb nu ook veel tijd besteed aan het maken van een handleiding, zodat het een completer product aan het worden is, hopelijk niet meer alleen voor nerds
Kortom testers gezocht! Ondanks dat ik veel tijd heb besteed aan het testen van JCS, dit op verschillende platformen heb uitgeprobeerd en op mijn eigen baan met 9 locomotieven werkt is dit natuurlijk nog geen garantie dat het overal werkt, althans dat is het streven
Mocht je het leuk vinden JCS uit te proberen graag!.
Groeten,
Frans
Bouwer van JCS
Hallo,
Het is alweer bijna 4 maanden geleden sinds mijn laatste post.
Aan het JCS project wordt nog steeds met veel passie en plezier gewerkt.
Er komen soms dingen tussendoor als kinderen die huis uitgaan en pa moet dan klussen
Maar er zijn vorderingen.
Ik ben bezig met het inbouwen van een Stations optie.
Eigenlijk is het een soort Queue van blokken, zodat je een schaduw station kan configureren dat b.v. bestaat uit blokken 1, 2 en 3.
Uit deze blokken samen kan pas een trein vertrekken als er in alle blokken er een trein staat. Voor de configuratie hiervan heb ik een aantal schermen toegevoegd:
De Blokken die tot het station behoren:
Nu de schermen zijn toegevoegd en database is aangepast moet de state machine worden aangepast.
Deze state machine is het hart van JCS dat automatisch rijden bestuurt.
Ik heb mezelf ten doel gesteld deze state machine uitgebreid door testen.
Bij met maken van de unit testen kwam naar voren dat de manier waarop de state machine nu gemaakt het heel lastig te testen is.
Vandaar dat ik ben begonnen aan een redesign van dit stuk.
Dit redesign is nu voor ongeveer 60 % voltooid. Nu kan ik ui gebreid iedere stap door testen. Dit is belangrijk voor vervolg stappen.
De eerste functionaliteit die ik nu aan het voorbereiden ben is het aansturen van Seinen.
Het aansturen van Seinen wordt getriggered door de status van blokken.
Tot nu toe hadden blokken wel een status, die op het scherm wordt getoond, maar nu moet een verandering van de blok status leiden tot het aansturen van een sein.
Voorbeeld: als een locomotief mag vertrekken wordt de start state uitgevoerd. De start state zet het vertrekkende blok in de Outbound status. Dit is het moment dat een sein moet worden aangestuurd (groen). Vervolgens kan de locomotief worden aangestuurd.
Wordt vervolgt.
Frans
Het is alweer bijna 4 maanden geleden sinds mijn laatste post.
Aan het JCS project wordt nog steeds met veel passie en plezier gewerkt.
Er komen soms dingen tussendoor als kinderen die huis uitgaan en pa moet dan klussen
Maar er zijn vorderingen.
Ik ben bezig met het inbouwen van een Stations optie.
Eigenlijk is het een soort Queue van blokken, zodat je een schaduw station kan configureren dat b.v. bestaat uit blokken 1, 2 en 3.
Uit deze blokken samen kan pas een trein vertrekken als er in alle blokken er een trein staat. Voor de configuratie hiervan heb ik een aantal schermen toegevoegd:
- stations-dialog.png (27.28 KiB) 1309 keer bekeken
- stations-dialog-members.png (28.49 KiB) 1309 keer bekeken
Deze state machine is het hart van JCS dat automatisch rijden bestuurt.
Ik heb mezelf ten doel gesteld deze state machine uitgebreid door testen.
Bij met maken van de unit testen kwam naar voren dat de manier waarop de state machine nu gemaakt het heel lastig te testen is.
Vandaar dat ik ben begonnen aan een redesign van dit stuk.
Dit redesign is nu voor ongeveer 60 % voltooid. Nu kan ik ui gebreid iedere stap door testen. Dit is belangrijk voor vervolg stappen.
De eerste functionaliteit die ik nu aan het voorbereiden ben is het aansturen van Seinen.
Het aansturen van Seinen wordt getriggered door de status van blokken.
Tot nu toe hadden blokken wel een status, die op het scherm wordt getoond, maar nu moet een verandering van de blok status leiden tot het aansturen van een sein.
Voorbeeld: als een locomotief mag vertrekken wordt de start state uitgevoerd. De start state zet het vertrekkende blok in de Outbound status. Dit is het moment dat een sein moet worden aangestuurd (groen). Vervolgens kan de locomotief worden aangestuurd.
Wordt vervolgt.
Frans
Bouwer van JCS
Klinkt leuk. Maar het feit dat er pas een trein uit mag als alle blokken vol zijn lijkt me wel lastig.
Stel voor dat ik 5 opstelsporen heb in mijn schaduw station met 2 a 3 blokken per spoor. Dan wil ik niet wachten tot alle blokken zijn gevuld. Maar eerder op dienstregeling of zo.
Ik weet niet of je wat kan met mijn feedback.
Stel voor dat ik 5 opstelsporen heb in mijn schaduw station met 2 a 3 blokken per spoor. Dan wil ik niet wachten tot alle blokken zijn gevuld. Maar eerder op dienstregeling of zo.
Ik weet niet of je wat kan met mijn feedback.
Fleischman z21 en YD7001 en DCC-EX centrales.
Mobiele baan 2x 100x50 cm met YD7001, DR4018, DR4088 en DCCNext.
https://hugo.vanderkooij.org/modelspoor/
Mobiele baan 2x 100x50 cm met YD7001, DR4018, DR4088 en DCCNext.
https://hugo.vanderkooij.org/modelspoor/
Hallo Hugo,
Dank voor je reactie.
Hoe ik de Stations optie nu aan het maken kan je het minimale aantal treinen in het station instellen, voordat er weer 1 mag vertrekken.
Voorbeeld mijn baan Station Mittelstadt HBF heeft 4 sporen. Hiervan gaan er 2 richting Noord en 2 richting zuid.
Ik heb in nu ingesteld Station Mittelstadt Noord, 2 blokken, minimaal 2 treinen.
Als er nu 1 trein binnenkomt kan deze niet vertrekken, omdat er maar 1 trein in het station aanwezig is. Ook niet na de blok wachttijd.
Zodra er een 2e trein binnenkomt kan de eerste trein weer vertrekken, omdat er dan voldaan wordt aan de voorwaarde min. 2.
Voorbeeld schaduw station, bestaat uit 4 sporen en dus 4 blokken. min aantal treinen is 3.
Dus als de 3e trein binnenkomt kan er weer 1 vertrekken. Hierdoor is de kans groot dat er dus 1 spoor vrij blijft om er langs te kunnen rijden.
Ik rijdt willekeurig. Ik heb nog geen dienst regeling in JCS. De treinen loop wordt nu voornamelijk beïnvloed door permissies en (blok) wachttijden.
Ik heb ook nog geen type trein toegevoegd. Dat is een van de volgende stappen.
Met een type trein wordt bedoeld dat je bv een trien de classificatie "goederen" geeft en het stations blok de classificatie "personen". een "goederen" trein hoeft dan niet te stoppen in een "personen" blok.
Ieder geval stof tot nadenken.
Zodra alles is geïmplementeerd ga ik dit op m'n eigen baan uitgebreid testen. Ik vermoed zomaar dat er dan nog wel iet naar boven komt.
Groet,
Frans
Dank voor je reactie.
Hoe ik de Stations optie nu aan het maken kan je het minimale aantal treinen in het station instellen, voordat er weer 1 mag vertrekken.
Voorbeeld mijn baan Station Mittelstadt HBF heeft 4 sporen. Hiervan gaan er 2 richting Noord en 2 richting zuid.
Ik heb in nu ingesteld Station Mittelstadt Noord, 2 blokken, minimaal 2 treinen.
Als er nu 1 trein binnenkomt kan deze niet vertrekken, omdat er maar 1 trein in het station aanwezig is. Ook niet na de blok wachttijd.
Zodra er een 2e trein binnenkomt kan de eerste trein weer vertrekken, omdat er dan voldaan wordt aan de voorwaarde min. 2.
Voorbeeld schaduw station, bestaat uit 4 sporen en dus 4 blokken. min aantal treinen is 3.
Dus als de 3e trein binnenkomt kan er weer 1 vertrekken. Hierdoor is de kans groot dat er dus 1 spoor vrij blijft om er langs te kunnen rijden.
Ik rijdt willekeurig. Ik heb nog geen dienst regeling in JCS. De treinen loop wordt nu voornamelijk beïnvloed door permissies en (blok) wachttijden.
Ik heb ook nog geen type trein toegevoegd. Dat is een van de volgende stappen.
Met een type trein wordt bedoeld dat je bv een trien de classificatie "goederen" geeft en het stations blok de classificatie "personen". een "goederen" trein hoeft dan niet te stoppen in een "personen" blok.
Ieder geval stof tot nadenken.
Zodra alles is geïmplementeerd ga ik dit op m'n eigen baan uitgebreid testen. Ik vermoed zomaar dat er dan nog wel iet naar boven komt
.Groet,
Frans
Bouwer van JCS
Hallo,
Sinds mijn vorige post is er onder de motorkap veel veranderd. Deze verandering begon tijdens het maken van de stations functionaliteit. Het toevoegen van deze functie bleek zodanig lastig te zijn dat ik mij ging afvragen of de eerste versie van de "Autopilot" wel goed qua structuur in elkaar zat. Kortom, omdat het toevoegen van nieuwe functionaliteit erg lastig bleek is het antwoord daarop nee, het kan beter.
Nu dat heb ik geweten, want bij het opzetten van een nieuwe structuur (re-factoren) van de autopilot, de motor die automatisch rijden mogelijk maakt, kwam ik toch weer een hoop onverwachte dingen tegen.
Het grootste probleem was de manier waarop de processen (threads) lopen. Een multi threaded omgeving lastig te debuggen.
Een van de problemen waar ik tegenaan liep is dat meerdere threads informatie updaten of bevragen, wat soms resulteerde dat een thread verouderde informatie kreeg.
Voorbeeld: Op mijn baan heb ik een aantal blokken na elkaar, niet in alle blokken hoeft te worden gestopt. De fysieke lengte van de blokken is verschillend.
Als een trein gaat rijden en de arriveer (enter) sensor wordt getriggered wordt er gekeken of er een volgend blok beschikbaar is an als dit zo is wordt dit gereserveerd.
Het reserveren van een blok betekend dat eventuele wissels die de route naar het blok maken worden omgezet. Hier kwam het grootste probleem naar voren. Met Marklin magnetische wissels is de schakeltijd per wissel ca. 100 ms. met bv 2 wissels in de rijweg en een wachttijd tussen de commandos duurt dit ongeveer 350 ms. De trein rijd gedurende deze tijd gewoon door. Bij een kort blok en veel andere commandos op het netwerk kon het nu voorkomen dat de bezet melding van het blok werd gemist, omdat de reservering nog bezig was. Met name gebeurde dit in korte blokken, dit werd erger met een servo wissel, waar de schakeltijd in de seconden loopt.
Kortom een andere, betere, oplossing was nodig om geen botsingen te krijgen (leer momentje).
Dit probleem (uitdaging) is nu in de nieuwe structuur opgelost. De state machine doet nu bij een doorgaand blok een predictie van de schakeltijd door eerst op te vragen wat die is per wissel. Is deze tijd boven een bepaalde waarde (500 ms) wordt de snelheid van de trein verlaagt, om zo te voorkomen dat de in of bezet melder door de trein wordt getriggered voordat de volgende route is gereserveerd. Maar dat was niet het enige, het monitoren van de terugmelders is nu een apart proces geworden. Hierdoor werd het mogelijk om zelfs tijdens het wachten op een reservering toch de bezetmelding van een blok te kunnen "zien" (en er op reageren). Als er een bezetmelding komt tijdens het reserveren van een route wordt de trein gestopt.
Nu is er dus "ruimte" gecreëerd om meerdere dingen tijdens het rij-proces te doen. Het eerste op mijn lijst was het aansturen van seinen.
Hiervoor heb ik een aantal schermen aangepast om seinen te kunnen configureren.
Het het blok configuratie scherm wordt een (vertrek) sein aan een blok zijde toe gewezen. (JCS gaat er vanuit dat de seinen in de centrale zijn geconfigureerd en dat de seinen zijn uitgelezen bij de Accessoire configuratie).
Vervolgens dient het gewenste seinbeeld voor een rijweg worden ingesteld.
Het seinbeeld verloop is als volgt:
In de departure state wordt gekeken of er een sein voor het departure blok (in de juiste richting) is geconfigureerd.
Zo ja wordt de departure waarde gezet (groen). Daarna volgt het verdere verloop (trein wordt gestart etc).
In de approaching state, enter sensor is af gegaan, wordt er gecontroleerd of er een "actief sein is" (groen sein) zo ja wordt het sein op rood gezet.
In de "find next route" state, de state die een volgende route zoekt (door rijden) wordt in principe het zelfde gedaan als bij departure.
Nu rest mij nog een hoop test werk ook op verschillende centrales (leve de updates
)
Wordt vervolgt,
Frans
Ps voor de liefhebber, de code is hier te zien.
Sinds mijn vorige post is er onder de motorkap veel veranderd. Deze verandering begon tijdens het maken van de stations functionaliteit. Het toevoegen van deze functie bleek zodanig lastig te zijn dat ik mij ging afvragen of de eerste versie van de "Autopilot" wel goed qua structuur in elkaar zat. Kortom, omdat het toevoegen van nieuwe functionaliteit erg lastig bleek is het antwoord daarop nee, het kan beter.
Nu dat heb ik geweten, want bij het opzetten van een nieuwe structuur (re-factoren) van de autopilot, de motor die automatisch rijden mogelijk maakt, kwam ik toch weer een hoop onverwachte dingen tegen.
Het grootste probleem was de manier waarop de processen (threads) lopen. Een multi threaded omgeving lastig te debuggen.
Een van de problemen waar ik tegenaan liep is dat meerdere threads informatie updaten of bevragen, wat soms resulteerde dat een thread verouderde informatie kreeg.
Voorbeeld: Op mijn baan heb ik een aantal blokken na elkaar, niet in alle blokken hoeft te worden gestopt. De fysieke lengte van de blokken is verschillend.
Als een trein gaat rijden en de arriveer (enter) sensor wordt getriggered wordt er gekeken of er een volgend blok beschikbaar is an als dit zo is wordt dit gereserveerd.
Het reserveren van een blok betekend dat eventuele wissels die de route naar het blok maken worden omgezet. Hier kwam het grootste probleem naar voren. Met Marklin magnetische wissels is de schakeltijd per wissel ca. 100 ms. met bv 2 wissels in de rijweg en een wachttijd tussen de commandos duurt dit ongeveer 350 ms. De trein rijd gedurende deze tijd gewoon door. Bij een kort blok en veel andere commandos op het netwerk kon het nu voorkomen dat de bezet melding van het blok werd gemist, omdat de reservering nog bezig was. Met name gebeurde dit in korte blokken, dit werd erger met een servo wissel, waar de schakeltijd in de seconden loopt.
Kortom een andere, betere, oplossing was nodig om geen botsingen te krijgen (leer momentje).
Dit probleem (uitdaging) is nu in de nieuwe structuur opgelost. De state machine doet nu bij een doorgaand blok een predictie van de schakeltijd door eerst op te vragen wat die is per wissel. Is deze tijd boven een bepaalde waarde (500 ms) wordt de snelheid van de trein verlaagt, om zo te voorkomen dat de in of bezet melder door de trein wordt getriggered voordat de volgende route is gereserveerd. Maar dat was niet het enige, het monitoren van de terugmelders is nu een apart proces geworden. Hierdoor werd het mogelijk om zelfs tijdens het wachten op een reservering toch de bezetmelding van een blok te kunnen "zien" (en er op reageren). Als er een bezetmelding komt tijdens het reserveren van een route wordt de trein gestopt.
Nu is er dus "ruimte" gecreëerd om meerdere dingen tijdens het rij-proces te doen. Het eerste op mijn lijst was het aansturen van seinen.
Hiervoor heb ik een aantal schermen aangepast om seinen te kunnen configureren.
- block_dialog.png (20.45 KiB) 12 keer bekeken
Vervolgens dient het gewenste seinbeeld voor een rijweg worden ingesteld.
- rijwegen_sein_settings.png (85.84 KiB) 12 keer bekeken
- seinen-statemachine.png (62.5 KiB) 12 keer bekeken
In de departure state wordt gekeken of er een sein voor het departure blok (in de juiste richting) is geconfigureerd.
Zo ja wordt de departure waarde gezet (groen). Daarna volgt het verdere verloop (trein wordt gestart etc).
In de approaching state, enter sensor is af gegaan, wordt er gecontroleerd of er een "actief sein is" (groen sein) zo ja wordt het sein op rood gezet.
In de "find next route" state, de state die een volgende route zoekt (door rijden) wordt in principe het zelfde gedaan als bij departure.
Nu rest mij nog een hoop test werk ook op verschillende centrales (leve de updates
)Wordt vervolgt,
Frans
Ps voor de liefhebber, de code is hier te zien.
Bouwer van JCS