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.
 

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-railway/blob/84-add-hardware-support-for-esu-ecos/README.md

Ik wens iedereen een gelukkig 2025.

Frans

Frans,

Mooi dat de Ecos nu ook aan JCS hangt. 

Ik heb hem gerund. Ik krijg verbinding met mijn Ecos, maar moet 2x drukken op de start/sopt knop om hem weer aan (of uit) te krijgen. De eerste keer verandert de knop van kleur en de twee keer gaat de ecos ook echt Aan (of uit).
Bij een typefout in het ip adres blijft hij (in de terminal zag ik dat) doorgaan met het oude IP adres en niet met het nieuw ingevoerde adres. Pas bij het afsluiten zag ik het juiste Ipadres erin komen en was het bij de volgende start gelijk goed.

Ook ik ga er een poosje tussenuit. Goede vakantie.

Meine

@Meine

Dank voor deze eerste testen.

Zal daar naar kijken na mijn vakantie.
Ben ieder geval blij dat het er op lijkt dat het ook bij jou gaat werken.
Zoals reeds vermeld ga ik (na mijn vakantie) alles grondig door testen.

De afgelopen tijd heb ik voornamelijk besteden aan het begrijpen en werkend krijgen van de functionaliteit van de ECoS.
Het zal mij niet verbazen als er nog issues zijn.

Fijne vakantie.


Groet,
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.


De ECoS en Marklin Centrales hebben 3 soorten connecties:

• TCP voor alle commandos en terugkoppelingen volgen protocol leverancier
• HTTP voor het downloaden van locomotief iconen, zodat JCS deze ook kan tonen
• VNC Om het scherm van de centrale in JCS te zien

Om te kunnen testen zonder centrale heb ik, als eerste voor de ECoS een virtuele ECoS connectie gemaakt (je moet iets doen op vakantie .
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
 

Dag Frans,

Ik volg je topic en kan redelijk begrijpen waar je mee bezig bent alhoewel het mijtoch een beetje boven mijn pet gaat.
Maar stilstaan is achteruitgaan dus ik blijf alle ontwikkelingen volgen (uit nieuwsgierigheid).

Nu heb ik een vraag.
Je gebrukt een VNC.
Nu weet ik dat je met ene VNC-viewer het scherm van de ecos op je beeldscherm van je computer kunt krijgen.
Welke VNC-viewer zou jij adviseren?
Ik heb daar weinig kaas van gegeten.

Henk

Hallo Henk,

Dank voor het volgen.
Er is zeker geen stilstand, maar soms ga je vooruit in functionaliteit om er vervolgen achter te komen dat je dingen iets anders had moeten aanpakken.
Ik denk dat dit voor ieder project geldt.
Enfin daar leer je dan weer van

Zowel de Marklin CS3 als de ESU ECoS hebben een VNC server aan boord.
Met VNC wordt het beeld van de centrale als het ware naar de VNC Client (je computer) gestuurd en kun je de centrale vanuit je computer via VNC bedienen.

Ik heb in JCS een VNC Client toegevoegd, meer omdat ik het leuk en interessant vindt om zo'n client zelf te maken, en omdat mijn ECoS 2 strepen in het scherm heeft.


Er zijn goede VNC clients verkrijgbaar, de meeste zijn gratis.
De gene die ik gebruik zijn Real VNC en de Remote RippleC
Beide zijn verkrijgbaar voor verschillende platformen (Windows, MacOs, Linux).

Beide zijn goed bruikbaar voor zowel ESU ECoS als Marklin CS 3.
Zoals bij veel van dit soort applicaties is het ook een beetje "smaak" dus ik zou zeggen probeer ze allebei (gratis) uit en houdt degene die jij het prettigst vindt werken.

Screenshots:
RealVNC

Remote Ripple


Frans

 

Bedankt Frans.

Hallo,

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

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
   

 

een beetje NERD technisch, dat mag je wel zeggen Frans, zeg maar,  een beetje te veel voor mij toch.
ik blijf het volgen
succes
guy

Hallo,

Het is alweer ruim 6 weken geleden dat ik voor het laatst iets had gepost over de vorderingen met JCS.
Door allerlei (privé) omstandigheden gaat het wat trager, maar er zijn nog steeds vorderingen .

Los van mijn privé omstandigheden, ben ik ook begonnen aan groot onderhoud van mijn eigen baan. Ben hier de bekabeling van de sensoren etc aan het vervangen, zodat ik fouten uit het verleden nu elimineer, maar dat de baan straks ook door meerdere centrales bestuurd kan worden (het is nu heel erg Marklin specifiek).

Daardoor kan ik naar de toekomst toe JCS verder ontwikkelen, doordat ik meer mogelijkheden heb dan op m'n testbaan.

Huidige stand van zaken
Druk bezig met het testen van de HAL.
Bij het toevoegen van de USU ECoS bleek dat ik nog (te)veel Marklin CS specifieke code in de HAL had zitten.
Bij het toevoege van de ESU ECoS heb ik die al min of meer verplaats, maar dit moet nog wel allemaal getest worden.
Dit proces is nog steeds gaande. Ook bezig met het zoveel mogelijk automatiseren en toevoegen van testcases.

Bij het testen kwam toen ook naar boven de de GUI nogal traag werd bij gebruik van meer dan 100 tegels, dit probleem lijkt nu eindelijk opgelost (zie vorige post).
De Marklin CS code ben ik, naar aanleiding van de leermomenten die ik bij het toevoegen van de ESU ECoS tegenkwam, aan het herschrijven, refactoren.
Inmiddels is en nu ook een virtuele Marklin connectie mogelijk, maar de Marklin CS heeft net iets andere mogelijkheden als de ESU ECoS.

Ook ben ik begonnen met het implementeren van het gebruik van het toetsenbord bij het editen van de layout en Automatisch gebruik.
Dit waren suggesties van testers / gebruikers en daarom voor mij waardevol.

Door het toevoegen van de toetsenbord functies ben ik ook weer gaan na denken over de layout van de schermen, zodat daar ook een aantal wijzigingen worden gerealiseerd waardoor het geheel en stuk logischer aan het worden is.

Een andere belangrijke wijziging, die toch meer code aanpassingen vraagt dan gedacht, is het reageren op wijziging in de setup.
Denk hier bijvoorbeeld aan het toevoegen van een nieuwe locomotief of Accessoire, het wijzigen of toevoegen van de layout.

Tot nu toe moest je JCS opnieuw starten voordat de wijziging van kracht werd. Dat is straks niet meer nodig.
Verder is er door de DCC-EX gemeenschap een grote update uitgebracht, zodat ik daar ook nog een aantal zaken moet aanpassen.

Enfin zo blijf je bezig

Wordt vervolgt...

Hallo,

Nu de temperatuur weer aan het stijgen is op de treinen-zolder spendeer ik daar wat minder tijd.
Toch maak ik wel langzaam vorderingen mijn mijn zelfbouw project voor treinbesturing.
De hoeveelheid functionaliteit is de laatste tijd met het toevoegen van de ESU-ECoS behoorlijk gestegen.
Ik had al vermeld dat ik in de HAL laag, de laag in de software die er voor zorgt dat alle centrales vanuit het gezichtspunt van de bediening op het scherm en de automaat het zelfde reageren, behoorlijk moest modificeren.
Later bleek natuurlijk dat een niet meer goed werkte bij de Marklin CS 3. (wet van murphy).
Ook aan de GUI kan bleek bij testen e.e.a. mis te gaan, waardoor ik min of meer een paar stappen terug moest gaan.

Het moet natuurlijk goed werken en de software moet ook ook nog onderhoudbaar zijn, dus de perfectionist in mij heeft mij doen besluiten hele stukken te herschrijven en te hergroeperen 

Dit lijkt nu eindelijk wat vruchten af te werpen, de hoeveelheid code wordt minder 

Ik ben heel veel automatische testen aan het toevoegen, zodat ik eerder kan zien als ik iets stuk maak en omdat ik nu voor de 2e keer door de Marklin implementatie heen ga leer ik toch weer wat dingen (belooft wat voor DCC-EX).

In het hoofd-scherm heb ik een "rare" lege plek opgevuld met een "mini" "Driver cap". Soort gelijke functionaliteit hebben veel andere besturing programma's ook en het is wel handing, dus moet ik ook hebben 



Het screen-shot hierboven is de weergave van JCS met het ingebouwde VNC scherm verbonden met mijn ESU-ECoS 50000.
Het gaat om het blokje links onder in:



Deze "Driver cap" bedient de geselecteerde locomotief in de tabel er boven. Het scherm is bi-directioneel. Dat wil zeggen je kun de snelheid, richting en functie van de locomotief kan bedienen, maar als je dit op de centrale doet geeft dit scherm ook de situatie weer.
het scherm "luistert" als het ware naar de centrale. Het scherm(pje) "luistert" ook naar de tabel er boven:



Als je daar een andere locomotief kiest dan "luistert" het naar die geselecteerde locomotief.
Ik vond dit op zich wel een mooie mile-stone.

De release laat helaas nog even op zich wachten, komt ook doordat ik een beetje perfectionistisch ben, maar het is hobby toch ?

Ondertussen ben ik ook aan een ander project begonnen en wel het her-bekabelen van mijn baan, zodat ik meerdere centrales kan aansluiten (nee niet tegelijkertijd) zonder dat alles om hoeft. Dit om JCS verder te te kunnen testen op een baan van ca 3 x 1,1 m waar 8 treinen kunnen rijden.
Zie filmpje toen reed het met Rocrail (maar ook om de kabels netter te maken dan in de film).

Groet,

Frans



 

 

Hallo,

Afgelopen tijd is het wat stil geweest over mijn JCS project. Dit komt deels door de zomer , maar ook om dat ik niet verder fysiek kon testen daar ik (als side project) mijn baan aan het her-bekabelen was. Deze baan, "Zolderhoek" ben ik in 2018 gaan bouwen en gedurende de loop van de bouw veel geleerd, maar er zaten dus ook een aantal zaken niet lekker. Toen er 2 wissel motoren en een K83 decoder defect raakten was dit voor mij het moment om de "koe bij de hoorns" te vatten het het nu goed, of in ieder geval anders, te gaan doen. Ik had hier gelijk de wens dat het relatief gemakkelijk moet zijn om van Centrale te wisselen, zodat ik JCS op een grotere baan als mij test baantje kan testen.

Eerste wens was alle decoders zoveel mogelijk centraal (en er geen last van hebben). Ik heb alle decoders op een omhoog klapbare plank geplaatst, die onder de tafel kan worden geklapt en vastgezet.
 


Voor de Sein decoders moet er waarschijnlijk zo'n 2e paneel komen.
Door dat ik de aansluitingen van de Link-S88 zelf heb vrij gehouden kan ik relatief eenvoudig de S88 modules om pluggen om ze bijvoorbeeld aan een ECoS centrale te hangen.

De bedrading van de baanspanning heb ik een ster, met een "sneeuwvlok" gemaakt van 0,75mm2. De sneeuwvlok slaat op de 2e (kleine) ster op het stuk baan dat fysiek boven de zoldertrap ligt en los-koppelbaar moet zijn om bij het dakraam te kunnen komen.
   


Ook wilde ik in de toekomst de verlichting van de gebouwen kunnen sturen, dus heb deze aansluitingen zoveel als mogelijk naar een centraal punt gebracht.
Doordat je dan bezig ben met de baan (heeft al met al zeker zo'n 7 a 8 maanden geduurd) kon ik ook het JCS project overdenken. Dat helpt soms de dingen beter te overzien...

Ik heb een aantal verbeteringen in de GUI doorgevoerd, zoals gebruik van toets combinaties in het edit scherm (dit was door een aantal volgers van deze blog voorgesteld). Met een toets combinatie (bv alt r voor roteren) kan je nu de layout wijzigen.
De grootste wijziging is echter "Drag and Drop", de Spoor componenten zijn in een overzichtelijk paneel geplaatst en je kan ze van hieruit op het spoorplan trekken. "Door" plaatsen, het laatst geplaatste component en richting wordt onthouden, bij nog een keer klikken op een onbezette plaats wordt dit component wederom geplaatst.



Ook bij het instellen van de Centrale heb ik de nodige verbeteringen doorgevoerd, zoals het automatisch zoeken van de centrale op het netwerk, nu tegenwoordig bijna (ieder geval ECoS en CS-3) alle centrales mDNS ondersteunen. De filosofie van JCS is dat de Centrale "het beter weet" dus heb veel tijd besteed aan het uitlezen van de centrale meta-data. Zoals het aantal melders, locomotieven, accessoires en eventuele iconen.



Last but not least automatisch rijden.
Tot nu toe heb ik dat met name alleen kunnen testen op mijn testbaan, waar ik max. 3 locomotieven heen en weer kon laten bewegen.


Nu de bekabeling op mijn baan voor 80% klaar is (komt het wel een helemaal af...?) en alle terugmelders en wissels het weer doen ga ik een nieuwe fase in om het automatisch rijden te kunnen perfectioneren (het echte werk begint dus nu  ).


 
Deze plattegrond representeert mijn baan "Zolderhoek" komende tijd ga ik JCS verder ontwikkelen, zodat hier 8 treinen kunnen gaan rijden.

Word vervolgt,

Frans

Even voor mij duidelijkheid, wat is de achterliggende gedachte van dit project? 

Het is natuurlijk mooi en knap wat je doet, ik snap er sowieso geen snars van, maar wat is het doel?

Dit vreet vreselijk veel tijd om te maken, en zeker om er iets goeds van te maken. Kijk maar eens hoe lang de commerciële en niet commerciële besturingsprogramma's er over gedaan hebben om te komen waar ze nu zijn.

Dus mijn vraag, wat is het doel? Ben je niet bang dat je er nu veel tijd in stopt en straks merkt dat het wel heel veel tijd kost en dat je het dan laat liggen?

Maar wel petje af voor wat je doet.

Hi @flyerman

Citaat van: flyerman op zaterdag 02 augustus 2025, 13:27:35Dus mijn vraag, wat is het doel? Ben je niet bang dat je er nu veel tijd in stopt en straks merkt dat het wel heel veel tijd kost en dat je het dan laat liggen

Dat lijkt wel op de vraag des levens 

Maar alle gekheid op een stokje, gewoon omdat ik het leuk vind.
Ik ben al zo'n 5 jaar bezig met dit project, dus heb inmiddels wel door dat het veel tijd kost  . Maar daarvoor is het hobby!
En ja ik weet dat er in de markt kant en klare programma's zijn te krijgen die dit doen.
De fascinatie is meer hoe het dan exact werkt.

Uiteindelijk lijkt mij het natuurlijk geweldig als anderen deze software ook kunnen en gaan gebruiken, maar daar is het op dit moment nog niet goed genoeg voor (tenzij je heel avontuurlijk bent ingesteld) .

Ik probeer in deze "blog" wat kennis over te brengen (hopelijk zonder betweterig te klinken) hoe modelspoor automatisering werkt en wat ik zoal tegenkom bij het maken er van (zoals als anderen vertellen over de vorderingen van hun modelspoorbaan).

Ik heb JCS als open source project gepubliceerd op Github,
zodat iedereen er van kan leren of eventueel aan kan bijdragen (en ja ik krijg soms email van over de hele wereld, dat erg leuk is).

Ik hoop dat dit jou vragen beantwoord,

Groet,
Frans

Jazeker, ik was gewoon nieuwsgierig waarom je zo'n groot project begonnen was. 

Das nu duidelijk.

Hallo,

Het is alweer bijna 8 weken geleden dat ik iets over de vorderingen heb verteld (tijd vliegt).
Ik heb in de tussentijd niet stil gezeten, naast helpen verbouwen, werk, vakantie, klussen heb ik ook veel getest en fouten op gelost in JCS.

Een van de belangrijkste issues was het "door-rijden" tot de vorige blog kon JCS alleen van blok naar blok rijden.
Een trein start in een blok rijdt naar het volgende blok, stopt. Vervolgens gaat het programma checken of de trein verder kan.
Op een grote baan rijdt een trein dan met schokken. Dit ziet er niet echt "natuur getrouw" uit maar was wel een eerste doorbraak m.b.t automatisch rijden.

Afgelopen tijd veel na gedacht en een grote verandering in de state machine, het technische "hart: van de JCS Autopilot.

Als een trein een blok inkomt wordt er nu gecheckt of de trein door kan naar het volgende blok. Er wordt een voor reservering gemaakt. Als de voor reservering lukt zal de trein niet bij het binnen rijden van het blok afremmen maar gewoon met dezelfde snelheid door rijden. Lukt de voor reservering niet zal de trein afremmen, maar bij het bereiken van de "in" melder wordt er eerst gecheckt op het volgende bolk gereserveerd kan worden is. Lukt dit nu wel zal de trein doorrijden en de snelheid wordt weer hoger gezet. Als het niet lukt dat wordt er natuurlijk gestopt.

In een volgende blog zal ik hier wat meer over vertellen, maar ik wilde nu eerst wat beelden delen van 7 treinen op mijn baan "Zolderhoek" bestuurd door JCS.


Op gastendag zal ik een presentatie en demo geven over JCS

Groet,
Frans

Hallo,

Na een leuke en leerzame 3-rail gastendag, waar ik uitgedaagd was door @wissels om te kijken of ik zijn testbaan in JCS kon besturen bleek dat in deze baan een 3-wegwissel zat.



Dit component zat, tot nu toe, nog niet in JCS (ook omdat mijn eigen baan geen 3-wegwissel heeft).
Het alternatief met een linkse en rechtse wissel werkte niet, ieder geval niet bij ESU, dat de centrale was voor deze baan. Kortom een uitdaging.



Het toevoegen van het icoon en de "tegel" voor de 3-wegwissel was niet zo moeilijk.



Pas toen ik ging kijken hoe de verschillende centrales ermee omgaan kwamen er behoorlijke verschillen naar boven.
Als eerste een 3-wegwissel kan de standen rechtdoor, links- en rechtsaf aannemen.





Als eerste begonnen met de ESU Ecos centrale. Deze centrale stuurt een event als de wissel van stand veranderd.
Dit event heeft het wissel ID (dat is niet het adres!) en de stand, als een numerieke waarde.
Hier in is waarde 0: groen of rechtdoor, 1: rood of rechtsaf en 2 (rood) linksaf. Die laatste heb ik dan maar rood2 genoemd.

Als vanuit JCS de waarde 0,1,2 naar de ESU Ecos wordt gestuurd (met het wissel id) veranderd de wissel van stand.

Vervolgens naar de Marklin CS gekeken. Daar gaat het (heel) anders.
Bij de CS is een 3-wegwissel een wissel met 2 adressen. Standaard worden dat de adressen van de wissel dat je instelt + 1.
In mijn test opstelling is de 3-wegwissel W 55 met (MM) adres 55 en 56.

Als de wissel rechtdoor wordt gezet komen er 4 berichten van de centrale, 2 hiervan kunnen worden genegeerd, de 2 overgebleven berichten zijn:
RX: 0x00 0x16 0x37 0x7e 0x06 0x00 0x00 0x30 0x37 0x01 0x00 0x00 0x00
RX: 0x00 0x16 0x37 0x7e 0x06 0x00 0x00 0x30 0x36 0x01 0x00 0x00 0x00

Dit naar menselijke leesbaar vertaald, vanaf byte 9 0x37; adres-1, naar decimaal omgezet 55. Hier moet 1 bij worden opgeteld om het adres te krijgen dus 56.
Byte 10, 0x01 is de waarde, 1 oftewel groen(!)
Het 2e bericht dat met een vertraging van de wissel schakeltijd achteraan komt:
Byte 9 0x36; adres -1, naar decimaal omgezet 54. Hier 1 bij optellen: 55. Byte 10, 0x01 is de waarde, 1 oftewel groen(!).
De wissel staat nu dus rechtdoor.

Schakel de wissel rechtsaf dan komen de volgende berichten:
RX: 0x00 0x16 0x37 0x7e 0x06 0x00 0x00 0x30 0x36 0x01 0x00 0x00 0x00
RX: 0x00 0x16 0x37 0x7e 0x06 0x00 0x00 0x30 0x37 0x00 0x00 0x00 0x00

Hierbij valt op dat adres 55 als eerste groen wordt geschakeld en als tweede adres 56 krijgt de waarde 0 (rood).

Schakel de wissel linksaf dan komen de volgende berichten:
RX: 0x00 0x16 0x37 0x7e 0x06 0x00 0x00 0x30 0x37 0x01 0x00 0x00 0x00
RX: 0x00 0x16 0x37 0x7e 0x06 0x00 0x00 0x30 0x36 0x00 0x00 0x00 0x00

Hierbij valt op dat adres 56 als eerste groen wordt geschakeld en als tweede adres 55 krijgt de waarde 0 (rood). 

Kortom de volgorde waarin de adressen worden gestuurd maakt uit.

Ik heb deze verschillen in de Hardware Abstraction Layer van JCS verwerkt (dat koste even tijd).
Een wissel kan nu door de autopilot geschakeld worden met de waardes GREEN rechtdoor, RED rechtsaf en RED2 linksaf.

Na het maken van de sturing was het traceren aan de beurt.
Een 3-wegwissel kan dus 6 verschillende rijwegen maken:



Deze heb ik in 6 x 4 (voor iedere oriëntatie van de tegel) dus in verschillende 24 test cases moeten checken.

Kortom qua spoorcomponenten denk ik dat ik nu compleet ben!



Nu verder werken aan de release.
 
Groet,

Frans

 

Dat was dus een aardige uitdaging Frans.

Henk

Bekend baantje, leuk dat je er voor gaat, vandaag na afgelopen zaterdag een klein probleempje in Houten, een broze wissel vervangen en de werking van de 2e spoel van de 3weg wissel nagekeken, tot over 1,5 week,

met vriendelijke groet,

Walter

Citaat van: fransja op vrijdag 14 november 2025, 15:41:01.

Kortom qua spoorcomponenten denk ik dat ik nu compleet ben!
 

Frans, er is nog 1 railcomponent die nog mist: een ontkoppelrail.
En eigenlijk nog 1 heel bijzondere, een draaischijf. 

Meine

Hi @Meine,

De ontkoppelrails is wel een goede!, nog niet aan gedacht.
Ik ga die in de volgende release toevoegen.

De draaischijf is een ander "beest" ik heb er zelf geen een op mijn baan dus houdt het voorlopig in gedachten
Ik wil eerst ondersteuning voor seinen erin gaan maken.

Kortom weer plannen genoeg .

Eerste prioriteit is om de huidige code releasebaar te maken.
Dat betekend nog heel veel testen.
Ik maak daar wel progressie, en probeer ook documentatie te maken dat veel werk is.

Groet,

Frans

Hallo,

Na een lange test periode, en 2 erg leuke presentaties bij de Gastendag 2025 en Stamtafel Bollenstreek, 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
 
 

Hallo Frans,

net even een eerste eigen stap gemaakt  om met jouw software te werken, het eerste begin snap ik,

met vriendelijke groet,

Walter