Modelspoorforum.nl

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.

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

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

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.

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

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.

Hallo,

Wat doe op een verregende Hemelvaartsdag dag? een beetje "pielen"....

Ik had al een tijdje geleden mijn ESU ECoS 50000 voorzien van firmware update V 4.3.3. In deze versie, (en die daarvoor) zit de Booster manager in het protocol ingebouwd.
Hiermee zou het dus mogelijk moeten zijn om de booster metingen naar de PC te halen.

Dit doe ik al voor de Marklin CS 2/3 (al werkt het dat behoorlijk anders).
De gemeten waardes worden onderin op de status balk van JCS getoond.
Het is een leuke feature, vind ik, daar je een indicatie van de load krijgt van je centrale.

Op mijn ECoS zie dat er dus zo uit: Dus als eerst gezocht naar de Documentatie, helaas is die sinds 2011 niet meer bijgewerkt.
De exacte commando's zijn niet beschreven. Kortom dan maar reverse engineeren (...).

Even een beetje technisch, het ESU ECoS protocol werkt met ASCII commando's.
Ieder object heeft een ID en je kunt aan een object vragen welke attributen deze heeft.
Bij objecten moet je denken aan b.v. locomotieven, accessoires, feedback modules etc. De Ecos heeft voor ieder groep objecten een "Manager", zo ook de "BoosterManager".

Via deze "Managers" kun je de Locomotieven en accessoires uitlezen. De boosters zou het zelfde moeten gaan.

Met behulp van het onvolprezen programma Packet Sender aan de slag gegaan.
De ECoS heeft een ingebouwde help functie. Deze maar eerst eens geprobeerd.
Als je naar TCP port 15471 het commando help() stuurt dan antwoordt de ECoS met:
Overigens kan dit ook met het programma telnet.

Uit de documentatie weet ik dat het id voor de booster 27 is dus:
help(27) Dan een query op de booster manager met commando queryObjects(27): Ah, 2 id's voor 2 boosters, zoals in het plaatje de in- en externe.

Dan met het commando get(65000) de details opvragen: Nu komen de benodigde key-words terug:

• 65000 is de id van de interne booster

• name is de naam, Interne booster

• status is GO, spanning staat aan

• limit: 4000 is de maximale stroom in mA

• current: 45, 55 is de gemiddelde stroom (45) en de piekstroom (55) in mA

• temperature: 39 is de temperatuur in de ECoS

• voltage is de spanning op de booster, 17443 mV of wel 17,443 V

De rest van deze key-words heb ik nog niet geïmplementeerd.
Nu ben ik wel benieuwd wat er gebeurd bij een externe booster (ID 65001). Die heb ik helaas niet dus alle waardes bij mij zijn 0, maar ik hou me aanbevolen als iemand die eens wil proberen

Ik heb nu de BoosterManager in JCS, geïmplementeerd, moet nog e.e.a. grondig door testen maar nu wordt ook bij de ECoS de baan(booster)-spanning en stroom gemeten, wel zo leuk.

Groet,

Frans