Hi @hvdkooij
Ja dat staat zeker op de road map!
Ben nu nog druk bezig met de ESU Ecos, (kan inmiddels een locomotief laten rijden) maar, zodra de Ecos klaar is dat een prima idee.
Ik heb er alleen geen, dus als ik enige tijd een Centrale die "Z21 spreekt", zou kunnen lenen zou dat heel mooi zijn.
Ik heb het aan de https://github.com/fransjacobs/model-railway/issues/98 toegevoegd. Dank.
Groet,
Frans
Java Central Station
Bouwer van JCS
Hallo,
Als eerste iedereen bedankt voor de reacties, ideeën en tips.
Zo net voor mijn vakantie ben ik er tijdens de kerst dagen in geslaagd de ESU ECoS 50000 werkend te krijgen.
Er waren nog wel een paar wijzigingen in de HAL nodig, maar het eerste resultaat is er 
Instellingen in JCS.
En het rijden met de automatisch geïmporteerde locomotieven, accessoires en Sensoren.
Heb er een klein filmpje van gemaakt: https://youtu.be/rbFK8flam7M?si=ytovPw9PqUzL-bt9
Nu moet ik nog een hoop testen, ook de andere centrales, daar de HAL is gewijzigd, voordat ik een release kan maken.
Als er nu al mensen zij die het willen testen dan mag dat natuurlijk altijd, moet je alleen de boel zelf bouwen
Zie https://github.com/fransjacobs/model-ra ... /README.md
Ik wens iedereen een gelukkig 2025.
Frans
Als eerste iedereen bedankt voor de reacties, ideeën en tips.
Zo net voor mijn vakantie ben ik er tijdens de kerst dagen in geslaagd de ESU ECoS 50000 werkend te krijgen.
- IMG_5943.png (469.51 KiB) 284 keer bekeken
Instellingen in JCS.
- jcs_ecos2.png (288.77 KiB) 284 keer bekeken
- jcs_ecos2.png (288.77 KiB) 284 keer bekeken
Nu moet ik nog een hoop testen, ook de andere centrales, daar de HAL is gewijzigd, voordat ik een release kan maken.
Als er nu al mensen zij die het willen testen dan mag dat natuurlijk altijd, moet je alleen de boel zelf bouwen
Zie https://github.com/fransjacobs/model-ra ... /README.md
Ik wens iedereen een gelukkig 2025.
Frans
- Bijlagen
-
- jcs_ecos1.png (210.42 KiB) 284 keer bekeken
Bouwer van JCS
3 stappen voorwaarts, 1 stap terug.
Afgelopen tijd heb ik weer vorderingen gemaakt met JCS.
Ik had al vermeld dat ik de de ECoS centrale werkend heb, met name op mijn (kleine) test baan.
Ik zit nu in een Test traject om alle veranderingen die ik in de HAL moest doen ook te testen met de andere centrales.
Dit blijkt een zeer leerzaam traject (...).
Tijdens mijn vakantie had ik de laptop bij me, maar geen centrale om e.e.a. te kunnen testen. Daarom ben ik op het idee gekomen om de modulaire verbindingen structuur, die bij alle centrales is geïmplementeerd uit te breiden, zodat ik ook zonder centrale kan testen en virtueel rijden.
Als eerste hoe zit de centrale implementatie in elkaar?
Alle centrale implementaties worden doormiddel van de HAL verbonden met de rest van JCS.
De centrale implementatie zorgt ervoor dat “universele” commandos uit JCS worden omgezet naar de centrale specifieke commandos en vice versa voor de terugmeldingen.
De implementatie van de centrale is een soort 2 trap raket. Aan 1 kant worden de commandos gegeven (start, stop locomotief, schakel accessoire, etc) en deze wordt via een centrale connectie aan de centrale doorgegeven.
De ECoS en Marklin Centrales hebben 3 soorten connecties:
.
Deze gedraagt zie exact als een ECoS, maar de commandos worden uit een configuratie file gehaald.
Het leuke is nu dat je alle lagen kunt door testen of het gedrag het juiste is.
Dit het ik ook voor de terugmeldingen gedaan, dus als de Autopilot aan is dan wordt via de virtuele connectie het exacte terug meld event, alsof het een ECoS is, op gezette tijden gestuurd. Hierdoor heb ik uitgebreide unit testen kunnen maken voor de ECoS.
Tijden het testen met een wat grotere layout dan mijn test layout (met meer dan 400 tegels) kwam ik er achter dat er een vertraging zit bij het uitvoeren van commandos, moor erger nog ook bij de reactie op meldingen.
Dit blijkt een onvolkomenheid in de GUI te zijn.
Om Automatisch rijden te begrijpen heb ik zoveel mogelijk grafische terugkoppelingen gemaakt, zodat je op het beeldscherm duidelijk kan zien wat er aan het gebeuren is.
Met een layout met maximaal 50 tegels gaat dit zonder problemen, echter bij een layout van meer dan 400 tegels blijkt dat de tekentijd van het scherm soms meer dan een seconde is.
Hier zit dus een ontwerp foutje. Het blijkt nu dat bij ieder event het gehele scherm opnieuw wordt getekend, ook als die niet perse nodig is. Ik had verwacht dat ik alleen de tegel die veranderd is opnieuw tekende maar helaas bleek dit dus niet zo (ook gaat de ventilator van de laptop lopen dus kennelijk had die het ook druk).
Dus voor het scherm is het even terug naar de tekentafel.
Wordt vervolgt,
Frans
Afgelopen tijd heb ik weer vorderingen gemaakt met JCS.
Ik had al vermeld dat ik de de ECoS centrale werkend heb, met name op mijn (kleine) test baan.
Ik zit nu in een Test traject om alle veranderingen die ik in de HAL moest doen ook te testen met de andere centrales.
Dit blijkt een zeer leerzaam traject (...).
Tijdens mijn vakantie had ik de laptop bij me, maar geen centrale om e.e.a. te kunnen testen. Daarom ben ik op het idee gekomen om de modulaire verbindingen structuur, die bij alle centrales is geïmplementeerd uit te breiden, zodat ik ook zonder centrale kan testen en virtueel rijden.
Als eerste hoe zit de centrale implementatie in elkaar?
Alle centrale implementaties worden doormiddel van de HAL verbonden met de rest van JCS.
De centrale implementatie zorgt ervoor dat “universele” commandos uit JCS worden omgezet naar de centrale specifieke commandos en vice versa voor de terugmeldingen.
De implementatie van de centrale is een soort 2 trap raket. Aan 1 kant worden de commandos gegeven (start, stop locomotief, schakel accessoire, etc) en deze wordt via een centrale connectie aan de centrale doorgegeven.
- jcs-centrale-connectie.001.png (108.44 KiB) 192 keer bekeken
- [li]TCP voor alle commandos en terugkoppelingen volgen protocol leverancier[/li]
[li]HTTP voor het downloaden van locomotief iconen, zodat JCS deze ook kan tonen[/li]
[li]VNC Om het scherm van de centrale in JCS te zien[/li]
.Deze gedraagt zie exact als een ECoS, maar de commandos worden uit een configuratie file gehaald.
Het leuke is nu dat je alle lagen kunt door testen of het gedrag het juiste is.
Dit het ik ook voor de terugmeldingen gedaan, dus als de Autopilot aan is dan wordt via de virtuele connectie het exacte terug meld event, alsof het een ECoS is, op gezette tijden gestuurd. Hierdoor heb ik uitgebreide unit testen kunnen maken voor de ECoS.
Tijden het testen met een wat grotere layout dan mijn test layout (met meer dan 400 tegels) kwam ik er achter dat er een vertraging zit bij het uitvoeren van commandos, moor erger nog ook bij de reactie op meldingen.
Dit blijkt een onvolkomenheid in de GUI te zijn.
Om Automatisch rijden te begrijpen heb ik zoveel mogelijk grafische terugkoppelingen gemaakt, zodat je op het beeldscherm duidelijk kan zien wat er aan het gebeuren is.
Met een layout met maximaal 50 tegels gaat dit zonder problemen, echter bij een layout van meer dan 400 tegels blijkt dat de tekentijd van het scherm soms meer dan een seconde is.
Hier zit dus een ontwerp foutje. Het blijkt nu dat bij ieder event het gehele scherm opnieuw wordt getekend, ook als die niet perse nodig is. Ik had verwacht dat ik alleen de tegel die veranderd is opnieuw tekende maar helaas bleek dit dus niet zo (ook gaat de ventilator van de laptop lopen dus kennelijk had die het ook druk).
Dus voor het scherm is het even terug naar de tekentafel.
Wordt vervolgt,
Frans
Bouwer van JCS
Hi Frans,
Ja z'n simulatie is super handig, dat heb ik er bij Traintastic vanaf de start ingemaakt, maakt het zo veel makkelijker om te testen. Ik heb de meeste hardware ondersteuning ontwikkeld op basis van simulatie en die pas later getest met echte hardware, moest ik soms wel de simulatie nog wat bij stellen omdat de hardware toch net wat anders deed. Ik heb ook dat als er een sensor wordt getriggerd er ook echt een commando komt uit de simulatie van die centrale, dat werkt heel mooi om alles af te testen.
Heb je ook simulatie gemaakt voor Marklin CS3 en DCC-EX?
Waar ik nog tegen aanliep bij de ECoS was dat als je te snel commando's stuurt de buffer op de ECoS vol loopt en dan raken er dus commando's kwijt. Ik meen me te herinneren dat de input buffer iets van 1024 bytes is. Wat ik gedaan heb is dat ik bijhou hoeveel commando's "in de lucht" zijn, de limiet is nu 25. Als er 25 "in de lucht" zijn dan wacht ik eerst op een reply voor ik weer een nieuw commando stuur.
HTTP voor iconen is wel een leuke, daar moet ik ook maar eens naar kijken
Reinder
Ja z'n simulatie is super handig, dat heb ik er bij Traintastic vanaf de start ingemaakt, maakt het zo veel makkelijker om te testen. Ik heb de meeste hardware ondersteuning ontwikkeld op basis van simulatie en die pas later getest met echte hardware, moest ik soms wel de simulatie nog wat bij stellen omdat de hardware toch net wat anders deed. Ik heb ook dat als er een sensor wordt getriggerd er ook echt een commando komt uit de simulatie van die centrale, dat werkt heel mooi om alles af te testen.
Heb je ook simulatie gemaakt voor Marklin CS3 en DCC-EX?
Waar ik nog tegen aanliep bij de ECoS was dat als je te snel commando's stuurt de buffer op de ECoS vol loopt en dan raken er dus commando's kwijt. Ik meen me te herinneren dat de input buffer iets van 1024 bytes is. Wat ik gedaan heb is dat ik bijhou hoeveel commando's "in de lucht" zijn, de limiet is nu 25. Als er 25 "in de lucht" zijn dan wacht ik eerst op een reply voor ik weer een nieuw commando stuur.
HTTP voor iconen is wel een leuke, daar moet ik ook maar eens naar kijken
Reinder
Ontwikkelaar van Traintastic open source software
Ahhh. Sliding windows verhaal uit de TCP/IP wereld.reinder schreef: ↑18 jan 2025, 22:26 Waar ik nog tegen aanliep bij de ECoS was dat als je te snel commando's stuurt de buffer op de ECoS vol loopt en dan raken er dus commando's kwijt. Ik meen me te herinneren dat de input buffer iets van 1024 bytes is. Wat ik gedaan heb is dat ik bijhou hoeveel commando's "in de lucht" zijn, de limiet is nu 25. Als er 25 "in de lucht" zijn dan wacht ik eerst op een reply voor ik weer een nieuw commando stuur.
Qua ideëen is het welicht eens goed te kijken hoe TCP op dit punt werkt.
En wellicht kun je daar ook code van lenen voor je eigen toepassing.
Groet, Hugo.
Fleischman z21 en YD7001 en DCC-EX centrales
Mobiele baan 2x 100x50 cm met YD7001, DR4018, DR4088
Mobiele baan 2x 100x50 cm met YD7001, DR4018, DR4088
Die staan nog op de nominatie om te doen, ik wil tenslotte overal min of meer de zelfde structuur hebben.
Goede suggestie, ga hier zeker naar kijken, al heb ik met mijn testen tot nu toe er geen last van gehad.reinder schreef: ↑18 jan 2025, 22:26 Waar ik nog tegen aanliep bij de ECoS was dat als je te snel commando's stuurt de buffer op de ECoS vol loopt en dan raken er dus commando's kwijt. Ik meen me te herinneren dat de input buffer iets van 1024 bytes is. Wat ik gedaan heb is dat ik bijhou hoeveel commando's "in de lucht" zijn, de limiet is nu 25. Als er 25 "in de lucht" zijn dan wacht ik eerst op een reply voor ik weer een nieuw commando stuur.
Grappig hoe de "nog te doen dingen" queue steeds weer vol loopt
Groet,
Frans
Bouwer van JCS
Hi Hugo,
Het lijkt idd wel op het window van TCP/IP, alleen is het een heel ander doel. Dit is om te voorkomen dat het input buffer van de ECoS vol loopt, bij TCP/IP is het om de data overdracht snelheid te verhogen.
----------
Hi Frans,
Haha, ja daar heb ik ook steeds last van, er komt steeds meer bij, of je komt bij een volgense Centrale er weer achter dat het net niet helemaal in de HAL past, kun je daar weer aan het sleutelen. Houdt ons wel van de straat
Het lijkt idd wel op het window van TCP/IP, alleen is het een heel ander doel. Dit is om te voorkomen dat het input buffer van de ECoS vol loopt, bij TCP/IP is het om de data overdracht snelheid te verhogen.
----------
Hi Frans,
Haha, ja daar heb ik ook steeds last van, er komt steeds meer bij, of je komt bij een volgense Centrale er weer achter dat het net niet helemaal in de HAL past, kun je daar weer aan het sleutelen. Houdt ons wel van de straat
Ontwikkelaar van Traintastic open source software
Hallo,
Bedankt voor de reacties. Dat "voelt" altijd goed
In mijn vorige bijdrage vertelde ik dat het opbouwen van het scherm erg traag werd bij gebruik van meer dan 100 tegels.
Vandaar dat ik even terug moest naar de tekentafel.
Inmiddels lijkt nu alles een stuk vlotter te werken.
Wat was het probleem?
In mijn eerste ontwerp van de layout UI werden er Tegels op een Container Component geplaatst (in Java een JPanel).
Iedere tegel heeft een eigen render methode waarmee die zichzelf kan tekenen.
Deze tegel objecten werden allemaal geërfd van het generieke Shape Object, maar waren geen Componenten in de zin van de JDK.
Wanneer een tegel opnieuw gerenderd moest worden, bv als een wissel van status veranderd werden nu alle tegels opnieuw getekend, omdat er geen "flag" o.i.d. was die kon aangeven welke tegel nu veranderd was. Dit tekenen duurde per tegel tussen de 2 en 10 ms afhankelijk van de soort tegel.
Dan dient binnen de Java Swing API ook alle render activiteit te gebeuren in de z.g. "Event Dispatch Thread".
De JDK doe dit min of meer zelf en daar heb je in weze geen, of weinig invloed op. Dit zorgde voor vertraging.
Vandaar dat bij meer als 100 tegels de totale tekentijd flink kon oplopen (heb tot aan 2000 ms gemeten).
Het mag duidelijk zijn dat dit geen houdbare oplossing was.
Wat is er veranderd?
Een heleboel
Waarschuwing het wordt een beetje "nerd" technisch O:-D
Iedere tegel erft nu van JComponent en volgt het Swing API MVC (Model, View en Controller) patroon.
De tegels worden nu aan de Container toegevoegd i.p.v. getekend.
De Container beschikt over standaard functionaliteit om alleen te renderen wat is gevraagd te renderen.
Ik kan nu dus 1 specifieke tegel opnieuw renderen.
Dit scheelt veel tijd.
De tegel objecten zijn nu opgebouwd in de volgende structuur:
Een Tegel heeft een TileModel, dit object geeft alle (veranderbare) data van de tegel.
Denk bv aan de stand van een wissel, de status van een blok of sensor.
Een tegel heeft ook een TileUI dit object heeft alleen de render code (de hele code wordt nu ook makkelijker te volgen door de heldere scheiding van verantwoordelijkheden).
Door gebruik te maken van overerving erft ieder specifiek layout object van Tile dat een abstracte klas is geworden.
Als voorbeeld een Straight (recht stuk) die erft van Tile.
Heeft een TileModel (hier wordt in opgeslagen of die horizontaal of verticaal is). Heeft een StraightUI object dat de code bevat on een Straight te kunnen tekenen.
De StraightUI erft van ComponentUI uit de JDK, dit object is verantwoordelijk voor het renderen van objecten op een canvas.
Een Switch (Wissel) erft weer van Straight daar een wissel bestaat uit één rechte en één diagonaal etc.
Door deze aanzienlijke verbouwing moest alle aansturing van de de tegels ook anders.
Hierdoor werden dus grote delen van de code geraakt.
Een van de grootste veranderingen is de invoering van een EventAction Queue.
Deze dit tussen de tegels waar je op kunt klikken (Switch, Signal and Sensor) Het event van deze tegel wordt nu op deze Queue gezet.
Aan de andere kant van deze Queue "loopt" een HandlerThread. Deze Thread "kijkt" of er een actie event op de Queue staat en handelt dit vervolgens af (zoals het omzetten van een wissel of sein).
Dit word nu volledig buiten de EventDispatch Thread gedaan, zodat deze dus niet wordt "opgehouden" door het uitvoeren van allerlei (tijd consumerende) taken (In de voorgaande versie = werd dit met een z.g. worker Thread gedaan maar dit werkte minder goed).
Het ontkoppelen van verantwoordelijkheden door een queue werkt erg goed (beter dan lossen "worker" threads zoals ik nu gebruik), dus ben nu met een refactor slag bezig om meer taken zo te laten lopen.
Kortom het gaat weer vooruit, maar nog een hoop te doen voordat het zover is dat ik een release kan maken.
Wordt vervolgt,
Frans
Bedankt voor de reacties. Dat "voelt" altijd goed
In mijn vorige bijdrage vertelde ik dat het opbouwen van het scherm erg traag werd bij gebruik van meer dan 100 tegels.
Vandaar dat ik even terug moest naar de tekentafel.
Inmiddels lijkt nu alles een stuk vlotter te werken.
Wat was het probleem?
In mijn eerste ontwerp van de layout UI werden er Tegels op een Container Component geplaatst (in Java een JPanel).
Iedere tegel heeft een eigen render methode waarmee die zichzelf kan tekenen.
Deze tegel objecten werden allemaal geërfd van het generieke Shape Object, maar waren geen Componenten in de zin van de JDK.
Wanneer een tegel opnieuw gerenderd moest worden, bv als een wissel van status veranderd werden nu alle tegels opnieuw getekend, omdat er geen "flag" o.i.d. was die kon aangeven welke tegel nu veranderd was. Dit tekenen duurde per tegel tussen de 2 en 10 ms afhankelijk van de soort tegel.
Dan dient binnen de Java Swing API ook alle render activiteit te gebeuren in de z.g. "Event Dispatch Thread".
De JDK doe dit min of meer zelf en daar heb je in weze geen, of weinig invloed op. Dit zorgde voor vertraging.
Vandaar dat bij meer als 100 tegels de totale tekentijd flink kon oplopen (heb tot aan 2000 ms gemeten).
Het mag duidelijk zijn dat dit geen houdbare oplossing was.
Wat is er veranderd?
Een heleboel
Waarschuwing het wordt een beetje "nerd" technisch O:-D
Iedere tegel erft nu van JComponent en volgt het Swing API MVC (Model, View en Controller) patroon.
De tegels worden nu aan de Container toegevoegd i.p.v. getekend.
De Container beschikt over standaard functionaliteit om alleen te renderen wat is gevraagd te renderen.
Ik kan nu dus 1 specifieke tegel opnieuw renderen.
Dit scheelt veel tijd.
De tegel objecten zijn nu opgebouwd in de volgende structuur:
- jcs-gui-componenenten.png (91.61 KiB) 97 keer bekeken
Denk bv aan de stand van een wissel, de status van een blok of sensor.
Een tegel heeft ook een TileUI dit object heeft alleen de render code (de hele code wordt nu ook makkelijker te volgen door de heldere scheiding van verantwoordelijkheden).
Door gebruik te maken van overerving erft ieder specifiek layout object van Tile dat een abstracte klas is geworden.
Als voorbeeld een Straight (recht stuk) die erft van Tile.
Heeft een TileModel (hier wordt in opgeslagen of die horizontaal of verticaal is). Heeft een StraightUI object dat de code bevat on een Straight te kunnen tekenen.
De StraightUI erft van ComponentUI uit de JDK, dit object is verantwoordelijk voor het renderen van objecten op een canvas.
Een Switch (Wissel) erft weer van Straight daar een wissel bestaat uit één rechte en één diagonaal etc.
Door deze aanzienlijke verbouwing moest alle aansturing van de de tegels ook anders.
Hierdoor werden dus grote delen van de code geraakt.
Een van de grootste veranderingen is de invoering van een EventAction Queue.
Deze dit tussen de tegels waar je op kunt klikken (Switch, Signal and Sensor) Het event van deze tegel wordt nu op deze Queue gezet.
Aan de andere kant van deze Queue "loopt" een HandlerThread. Deze Thread "kijkt" of er een actie event op de Queue staat en handelt dit vervolgens af (zoals het omzetten van een wissel of sein).
Dit word nu volledig buiten de EventDispatch Thread gedaan, zodat deze dus niet wordt "opgehouden" door het uitvoeren van allerlei (tijd consumerende) taken (In de voorgaande versie = werd dit met een z.g. worker Thread gedaan maar dit werkte minder goed).
Het ontkoppelen van verantwoordelijkheden door een queue werkt erg goed (beter dan lossen "worker" threads zoals ik nu gebruik), dus ben nu met een refactor slag bezig om meer taken zo te laten lopen.
Kortom het gaat weer vooruit, maar nog een hoop te doen voordat het zover is dat ik een release kan maken.
Wordt vervolgt,
Frans
Bouwer van JCS
hey Frans, knap werk man, het NERD gehalte staat op hoog,
succes
guy
succes
guy
Hi Frans,
Ik had afgelopen weekend in ene een idee....wat nu als ik een modelspoorbaan simulator bouw, dan koppel ik die aan m'n software en dan kan ik virtueel een baan testen.
Inmiddels heb ik een hele basic versie, je kunt via een TCP socket verbinding maken en de trein besturen (snelheid+richting) en je krijg bezetmeldingen binnen.
In combinatie met de commando centrale simulatie die ik al had kun je dan dus alles simuleren/testen best handig
De modelsoorbaan simulator moet nog wel flink uitgebreid -> https://github.com/traintastic/traintastic/issues/185
Filmpje, met een LocoNet centrale, je ziet de commando log onderin het scherm:
Het mooie van deze hele simpele modelspoorbaan simulator is dat hij algemeen is, dus mocht je het handig vinden dan kun je denk ik met een beetje code hem ook aan Java Central Station koppelen
Ik had afgelopen weekend in ene een idee....wat nu als ik een modelspoorbaan simulator bouw, dan koppel ik die aan m'n software en dan kan ik virtueel een baan testen.
Inmiddels heb ik een hele basic versie, je kunt via een TCP socket verbinding maken en de trein besturen (snelheid+richting) en je krijg bezetmeldingen binnen.
In combinatie met de commando centrale simulatie die ik al had kun je dan dus alles simuleren/testen best handig
De modelsoorbaan simulator moet nog wel flink uitgebreid -> https://github.com/traintastic/traintastic/issues/185
Filmpje, met een LocoNet centrale, je ziet de commando log onderin het scherm:
Het mooie van deze hele simpele modelspoorbaan simulator is dat hij algemeen is, dus mocht je het handig vinden dan kun je denk ik met een beetje code hem ook aan Java Central Station koppelen
Ontwikkelaar van Traintastic open source software