Modelspoorforum.nl

Java Central Station of JCS is het (hobby) project waar ik nu al een paar jaar (met tussen pozen) aan werk.
Als eerst toont dit de breedte van de modelspoor hobby, je kan je zelf "uitleven" in tal van richtingen, zowel Creatief als "nerd" technisch .

Helaas zijn er niet zoveel "nerds" zoals ik, in de tijd dat ik nu bezig ben heb ik met 2 Amerikanen gecorrespondeerd (kijk dat is ook leuk) over dit onderwerp en recentelijk ben ik in contact gekomen met @reinder van Traintastic. Vandaar dan nu deze bijdrage op dit forum in de hoop anderen te kunnen inspireren (en mogelijk t.z.t. testers te vinden )

Waarom ik dit project?
Er is namelijk zeer competente treinbesturing software op de markt, sterker nog, mijn baan wordt dm Rocrail bestuurd.

Waarom dan toch zelf maken?

• Omdat het leuk is!

• Omdat het heel boeiend op precies te begrijpen hoe je een aantal treinen op een baan kunt besturen.

• Omdat ik ruim 15 jaar geleden er ook aan was begonnen maar door omstandigheden heb moeten stoppen.

• Omdat als er weer een stuk(je) werk en er daadwerkelijk iets gaat rijden dat wel een soort van kik geeft.

Open Source
Ik ben een voorstander van Open source Software, dus heb ik JCS voor iedereen open op Github gezet zie https://github.com/fransjacobs/model-ra ... ter#readme
Wat is tot nu toe gemaakt?

• Communicatie met een controller, in mijn geval ondersteun ik de CS 2 en 3 van Marklin simpelweg om dat ik die heb.

• De Locomotieven en de accessoires kunnen worden uitgelezen en min of meer met de hand kunnen de Locomotieven, functies en de wissels en seinen worden aangestuurd.

• De terugmeldingen komen binnen en kunnen worden getoond

• De schematische plattegrond van het baanplan kan worden getekend.

• De symbolen (wissels, seinen en melder) kunnen worden gekoppeld met de fysieke wissel, sein en melder, en je kan deze dan bedienen of monitoren (als je op de CS een wissel omzet zie je dat op het scherm en vice versa).

• De routes van blok naar blok worden nu automatisch uitgerekend.

Wat nog te doen

• Tonen van functie plaatjes bij functie buttons

• Het automatisch rijden (is sneller gezegd en geschreven dan gedaan)

• ....

Kortom nog genoeg te doen.

Is deze software al te gebruiken op mijn baan?
Nee, tenzij je ontwikkelaar bent, dan kun je zelf de software bouwen en testen zie https://github.com/fransjacobs/model-ra ... UILDING.md.

Als er interesse is zal ik proberen zo nu en dan een update te geven en wat dieper in te gaan in en sommige onderliggende principes te beschrijven, m.a.w. hoe werkt het nou (echt), waarom is het soms zol moeilijk etc.
En hoop ook nog wat te leren van eventuele reacties .

Screen shot:


Groeten,

Frans

Hoi Frans,
Als Rocrail gebruiker vind ik dit wel interessant om te volgen. Ik ben geen programmeur maar heb wel wat ervaring met software ontwikkeling maar dan meer als gebruiker in het specificeren van de eisen en het testen van het resultaat.
Je baanplan ziet er al goed uit. Ik zie (denk ik) wel een typisch Rocrail verschijnsel, namelijk de + en - zijde van het bloksymbool. Klopt dat?

Misschien vind je het interessant om bij een ander project aan te sluiten: https://dcc-ex.com/index.html.

Ik blijf je volgen.

Hi Frans,

Mooi overzicht van je software zo! Vind het ook erg leuk dat we samen kunnen puzzelen om de wat minder goed gedocumenteerde zaken van de CS2/3 en de Marklin CAN te ontrafelen.

DCC-ex is ook een mooi project idd, communicatie protocol is goed en helder gedocumenteerd. Redelijk eenvoudig toe te voegen vond ik (Marklin CAN is meer werk )

Reinder

Heel leuk, ik moedig dit soort initiatieven alleen maar aan!

Hallo,

Dank voor de reacties.

AlbertG schreef: ↑07 sep 2023, 20:44 Misschien vind je het interessant om bij een ander project aan te sluiten: https://dcc-ex.com/index.html.

@AlbertG en @reinder, DCC-EX is zeker een optie. Ik heb het op de wensen lijst gezet: Add support for DCC-EX
Als er iemand een tip heeft waar alle componenten in NL te koop zijn zou dat fijn zijn.

JCS
Afgelopen dagen verder kunnen werken aan het verbeteren en toevoegen van nieuwe functionaliteit.
Een van de dingen waar ik ooit JCS voor ben begonnen was het kleine scherm van de CS groter te kunnen weergegeven (toen had ik nog een CS 2, met de CS 3 is dat inmiddels verbeterd door de web interface).
Een van de dingen die ik bv mis in Rocrail is dat als je in de CS iets wijzigt je dit niet terug ziet in Rocrail (behalve de power).
Een van de "features" in JCS is nu juist dat als je een verandering "ergens" maakt (in JCS of op de CS of op een aangesloten mobile station) je dit overal ziet.

Het protocol dat Marklin voor de CS gebruikt ondersteund de feature. Zie cs2CAN-Protokoll-2_0.pdf
Bijna elke setting of verandering wordt als een soort van event bericht op de CAN bus gezet en daar kan je dan naar "luisteren".

In JCS wordt dit principe dus veelvuldig toegepast. Zodra er een bericht komt dat er een setting is veranderd wordt dit door JCS herkend en naar het juiste object door gezet.

Hoe is dit dan gemaakt? Een kijkje in de keuken
Het CAN over UDP of TCP protocol zoals hier beschreven beschrijft redelijk alle mogelijkheden, echter het is al weer 11 jaar oud en Marklin heeft niet stil gezeten. Door de beschrijving te volgen en met reverse engineering ben ik er achter gekomen dat naast UDP nu ook TCP wordt ondersteund, dat dat er berichten mogelijk zijn die niet beschreven staan.

PacketSender
Door gebruik te maken van het programma Packetsender is het mogelijk om alle commando's een voor een uit tevoeren en de response op die commando's te zien.
Voorbeeld is een commando om de power status te bevragen (niet gedocumenteerd). Is de spanning op de rails AAN of UIT?. Dat is voor Modelspoor software erg handig te weten (in het laatste geval heeft enig stuur commando namelijk geen enkele zin).
Het onderste commando zijn de 13 bytes die ik stuur naar de CS. De CS antwoord (2e van onderen) met 2 bytes een is een Broadcast 2e is van de CS zelf (zie de groene markering is de CS UID)
De rode markering is data byte 4, het stop/go commando waarde in dit geval dus 0 ofwel uit.
De 3e van onderen is het zelfde verzoek, maar nu staat de spanning aan (eerste response regel van boven).

Op deze manier ben ik bijna alle mogelijke commando's af gegaan en samen met de documentatie om te begrijpen hoe dit dan werkt. Vervolgens heb ik dat in JCS geprogrammeerd.
JCS "luistert nu naar de response berichten van de CS, zoals in het voorbeeld, maar als je de spanning op de CS aan of uit zet wordt het response bericht dus ook gestuurd (zonder dat je er om vraagt).
Door nu dit bericht te "vangen" weet je dus of de spanning aan of uit staat. Dat wordt in JCS weergegeven in de Power button en met de "Leds" in de snelheid meter van de "Driver Cab" Met het "Driver Cab" scherm kun je een locomotief kiezen en besturen, ook worden alle functie iconen weergegeven zoals op de CS (ze worden uit de CS gedownload).
Als je op de CS de zelfde locomotief selecteert en bv de snelheid veranderd wordt dit ook direct in JCS weergegeven.

Tot zover de vorderingen.

Groet,

Frans

Hallo Frans,

Geen aandelen, maar hier een klein lijstje met NL leveranciers. Kan uiteraard ook bij anderen, zoals Conrad AZ-delivery, etc.

Arduino Mega (Genuine, preferred):
- Amazon nl
- Kiwi Electronics
- Open Circuit

Arduino Mega (ELEGOO, preferred)
- Amazon nl

Arduino Mega kloon
- Open Circuit

Arduino L298 motor shield (Genuine , preferred):
- KIWI Electronics
- Open Circuit

Deek Robot L298 motor shield (kloon, preferred)
- Amazon nl

Dank je wel @Momfer , ik ga me oriënteren op de beste prijs

Inmiddels weer een stukje je verder gewerkt aan JCS. Ik heb een z.g. "Driver Cab" scherm gemaakt, waarmee je een locomotief kan besturen. JCS Haalt automatisch de locomotieven op uit het Central Station, en download ook automatisch de bijbehorende plaatjes. Een tekortkoming van de meeste besturings-software is dat de functie koppen meestal de aanduiding F0 tm Fx hebben en dat je zelf deze van "iconen" kan en mag voorzien. In JCS is het idee de zelfde iconen te gebruiken al op de CS worden getoond.

Hoe werkt dat dan?
Als eerste de locomotieven. In het CS-2 protocol staat beschreven dat je met het commando "Anfordern Config Data" met als variabele het woord "loks" via CAN de "lokomotive.cs2" file in gezipte vorm terug krijgt. Dit werkt op zowel de CS 2 als 3 en wordt bv door een Mobile Station gebruikt om de lijst op te vragen. Enfin na wat heen en weer proberen en mailen met @reinder is dit gelukt en krijg ik keurig de file (btw je kunt de file ook via http opvragen op http://<cs ip adres>/config/lokomotive.cs2).

Het formaat van deze file is wat curieus, maar staat redelijk omschreven in de documentatie, enfin lang verhaal kort ik heb nu een lijst van de locomotieven.

In deze file staat in het veld ".icon=RRF 272 001-9" het locomotief plaatje, die kun je vervolgens downloaden via:

• CS2: http://<cs2 ip adres>/icons/<icon naam.png>

• CS 3: http://<cs3 ip adres>/app/assets/lok/<icon naam.png>

Functies
In de "lokomotive.cs2" staan ook de functies van iedere locomotief gespecificeerd als:

.funktionen
..nr=0
..typ=1
..wert=1
.funktionen
..nr=1
..typ=4
..wert=0
.......

In bovenstaande voorbeeld zijn dat de functies F0 en F1. Het plaatje of icoon van de functie staat verborgen in de velden "typ" en "wert".
"typ" is de aanduiding van het plaatje en "wert" of de functie aan of uit staat.
Als je dit als volgt "vertaald" dan krijg je de URL van het functie icoon op de CS: "FktIcon_<a/i>_<ge/we>_01.png
a en kleur "ge" als wert is 1 (aktief), i en kleur "we" als wert=0 (inactief) en 01: typ met 1 voorloop 0 plus ".png".
De URL wordt dan http://<cs ip adres>/fcticons/FktIcon_a_ge_01.png. en Dit werkt op zowel de CS2 als CS3 voor de meeste "oudere" locomotieven.

Moment functies
Functie die als een moment zijn geconfigureerd kun je herkennen door dat de waarde in veld "typ" groter is dan 128 en kleiner dan 150. het juiste plaatje vindt je door er 128 eerst vanaf te trekken (...) Maar toen
Zo dacht ik, het werkt en voor de meeste van mijn locomotieven klopte het, maar toen kreeg ik eindelijk, na 18 maanden op mijn bestelling te hebben gewacht, de 37298, 1102 RRF G2000 binnen.
Natuurlijk gelijk aan gemeld op de CS 3. De locomotive file opnieuw in JCS ingelezen. Het locomotief plaatje kwam mee, maar de functies was een desillusie. wat blijkt:

.funktionen
..nr=0
..wert=1
.funktionen
..nr=1
..wert=0
.funktionen
..nr=2
..wert=0
.funktionen
..nr=3
..wert=0

Er is geen "typ" veld(!) Maar op de CS3 worden gewoon de plaatjes getoond...
Enfin verder gezocht en wat blijkt de CS3 gebruik intern een JSON file voor de locomotieven en plaatjes. zie http://<cs3 ip adres>/app/api/loks/
Daar staat (ongedocumenteerd) :

{
"name": "1102 RRF G2000",
"internname": "1102#20RRF#20G2000",
"uid": "0x4017",
"tachomax": 140,
"symbol": 1,
"dectyp": "mfx+",
"icon": "/usr/local/cs3/lokicons/RRF 272 001-9",
"dir": 0,
"speed": 0,
"recent": 179,
"funktionen": [
{
"nr": 0,
"typ": 0,
"fs": 0,
"typ2": 1,
"dauer": 0,
"state": 1,
"isMoment": false,
"icon": "fkticon_a_001"
},
{
"nr": 1,
"typ": 0,
"fs": 0,
"typ2": 48,
"dauer": 0,
"state": 0,
"isMoment": false,
"icon": "fkticon_i_048"
},.....

Kennelijk zijn er dus velden bij gekomen (type2, dauer, state en isMoment). Dank je wel Marklin.
Uiteindelijk is dit veel beter, daar er nu duidelijk is of het een momentele functie betreft of niet. het functie icoon verwijst naar een ander JSON bestand op de CS3 waar alle functie als SVG zijn opgeslagen (http://<cs3 ip adres>/images/svgSprites/fcticons.json) Uiteindelijk dit nu ook toegevoegd in JCS en afhankelijk of er een CS 2 of 3 wordt herkend gebuikt JCS de ene of de ander methodiek.

Eind resultaat Groeten
Frans

Tegeltjes wijsheid of...

Het spoorplan de, schematische, weergave van de layout. Dan is bij software voor modelspoor automatiseren ook een van de belangrijkste functionaliteiten. Er zijn meerdere mogenlijkheden dit te doen maar in JCS heb ik er voor gekozen dit te implementeren met tegels (tiles).

Als eerste heb ik een raster gedefinieerd van vierkantjes van 40 x 40 pixels. Een stukje rails, wissel etc. moet dus hier binnen passen. Er zijn op dit moment 2 uitzonderingen op deze regel nl een blok en een kruiswissel.
Vervolgens heb ik de volgende soort tegels gedefinieerd:
Straight of te wel rechte rails
Curved, gebogen rails in de tekening eigenlijk diagonaal
Sensor, melder
End, "stop blok"
Signal, sein
Switch, wissel
Cross, kruiswissel
Block, blok

Er zijn natuurlijk meer mogelijke symbolen, maar dat is meer voor de toekomst. Met bovenstaande symbolen kan ik mijn huidige baan schematisch weergeven.

Maar goed, wat dat ik kan nu symbolen op een zg canvas plaatsen en dan gaat het op een plattegrond van de baan lijken. Wat nu?
Een recht rails kan op 2 manier worden geplaatst, Horizontaal en Verticaal, een "Ronde" rails kan op 4 manier worden geplaatst. Kortom ik heb iedere tegel een Oriëntatie gegeven, Noord Oost, West en Zuid. de default is Oost.

Vervolgen het tekenen van een Tegel, Om toch enige datails te kunnen laten zien wordt iedere tegel 10 zo groot getekend nl 400x400 pixels
Voorbeeld een uitrij sein: Uiteindelijk komt het dan zo in de plattegrond: Als alle plaatjes die op een plattegrond staan stuk voor stuk getekend en verkleind moeten worden zou dit (te) veel computer power vragen, dus ieder tegel type wordt wordt maar 1 keer getekend eb vervolgens wordt van de tekening een image gemaakt die een cache wordt geplaatst voor hergebruik, zodat de GUI responsief blijft werken en er niet te veel computer power wordt gevraagd (JCS werkt zelfs op een Raspberry Pi 4).
In teken mode ziet het er uiteindelijk dan zo uit. Een blok is een een speciaal geval. Het is de plaats, waar in een toekomstig stadium, een trein in kan staan. Een blok heeft daarom een richtingsindicatie nodig. @AlbertG had dit in mijn eerste post al goed gezien. Het lijkt inderdaad een beetje op Rocrail. Ik heb voorlopig maar een "+" en een "-" aangehouden on de richting te kunnen aanduiden. Als er een lezer is met een beter idee hou ik mij aanbevolen

Tot zover deze bijdrage, heb zojuist de spulletjes binnen gekregen om een DCC-EX Command station te kunnen maken. Dus @Momfer er wordt aan gewerkt.

Groeten,

Frans

Weer een mooie gedetailleerde uitleg zo. Leuk om de vorderingen zo te kunnen volgen.

Ik ben benieuwd naar de volgende stappen. Veel plezier en succes met de ontwikkelingen

Is een pijl als richting aanduiding in een blok niet makkelijker?

Mooie progressie @fransja!

Mooie verzameling seinen ook al!, stuur je die ook al aan qua seinbeeld op basis van wat achter het sein ligt?
Dat is met sommige seinen best een uitdaging, in elk land werkt het weer net een beetje anders.

Leuk om te zien dat je een andere teken strategie gebruikt, In Traintastic teken ik juist elke keer opnieuw. (Niet het hele bord overigens, alleen het deel dat invalid is. Moet nodig eens testen hoe goed dat performt op een RPi 4.

Heb je ook een "dubbele" bocht tegel? Bij dubbel spoor bocht kan dat handig zijn, anders liggen de sporen zo ver uit elkaar.

Zijn de blokken altijd 3 tegels lang, of kun je ze ook groter maken?

Of het een beter idee is weet ik niet, in Traintastic gebruik ik A en B, waarbij A = West for horizontal blocks, South for vertical blocks en B = East for horizontal blocks, North for vertical blocks..

Leuk dat je ook DCC-EX gaat ondersteunen, ben benieuwd naar je vorderingen.

Reinder

Hallo,
Het is alweer enige tijd geleden dat ik iets heb geplaatst op het forum, bij deze een update van JCS.

Afgelopen weken veel tijd besteed aan de ondersteuning van DCC-EX. Als eerste natuurlijk het Dcc-Ex command station (centrale) gemaakt, en dit aan een proef spoortje aangesloten. Vervolgens een beetje gespeeld met wat op de markt zijnde Throttles op de telefoon om via het netwerk en seriële poort de centrale te bedienen en zo te leren hoe het e.e.a. werkt.

De verschillen in het protocol met wat ik tot nu toe gemaakt heb, (Marklin CAN protocol) zijn enorm, kortom ik moest het een en ander refactoren (herorganiseren).
Als eerste een scherm gemaakt zodat je verschillende centrales kan kiezen.

Vervolgens ben ik begonnen met de netwerk implementatie van het DCC-EX protocol.
Het DCC protocol werkt volledig asynchroon. Dit betekend dat als je een bericht (command) stuurt naar de centrale dit "fire en forget" is.
Dit in tegenstelling met het Marklin CAN protocol die op elk commando direct response terug geeft.

DCC-EX geeft uiteindelijk wel een response maar de volgorde waarin en wanneer zijn volgens de maker niet gegarandeerd.
DCC-EX protocol geeft altijd een "echo" van ieder commando als response, dus ook als er via een andere Throttle (client) iets wordt gestuurd, wordt dit naar iedere aangesloten client gestuurd.
Dit is een handige eigenschap. Dit doet bv de Marklin CS 2/3 ook en alle schermen in JCS reageren daar dan dus op.

Enfin vanavond had ik dus het eerste moment dat ik via JCS een locomotief kon laten rijden via de DCC-EX centrale JCS kan verbinden met de DCC-EX centrale en kan nu commando's sturen om een loc te bedienen, maar JCS zie ook als er via een andere Throttle een locomotief wordt bediend. Zowel de snelheid, de richting als de functies.

Kortom het eerste begin is er pfff.

Natuurlijk is er nog genoeg te doen:

• Bedienen via seriële poort
• Melders
• Wissels / seinen
• Metingen
• Invoeren van Locomotieven en plaatjes
• Invoeren van Wissels en seinen
• ...

kortom ik ben nog wel even bezig

Groeten,
Frans

Marklin Bug...

Hallo allemaal,


Recentelijk heb ik mijn Mobile station WLAN mogen ontvangen en deze geconfigureerd en aangesloten op mijn CS 3.
Nadat de locomotieven zijn geladen kun je deze nu draadloos besturen.
Wat ik zelf een enorm handig ding vindt is de "paddestoel" (geen idee hoe dat heet) achterop, zodat je hem in 1 hand kan houden en besturen.

Een paar weken geleden schreef ik over het op halen van de functie bij de CS 2 en 3 en de verschillen.
En wat scherts mijn verbazing bij het selecteren van de 37298, 1102 RRF G2000 in de MS WLAN geen functies! (of althans maar 4 van de 20).

De 1102 RRF G2000 functies in de CS 3 Functies 0-7 in de MS WLAN. Alleen dus F7 Functies 8-15 in de MS WLAN. Alleen F10, F13 en F14 Kortom de MS WLAN gebruikt kennelijk op de achtergrond ook de "lokomotives.cs2" file en heeft dus "last" van deze bug.
Geen idee waar je dit bij Marklin kan melden, maar het is ieder geval curieus....

Groeten,

Frans

Hallo,

Alweer enkele weken geleden dat ik iets het gepost, soms gaat de tijd vreselijk snel (...).
Alle lezers/volges ieder geval dank voor de reacties die ik zo af en toe krijg

Ik had het DCC-EX stuk voor het "Command en Control" stuk min of meer ingebouwd, maar bleef ik het idee houden dat het niet helemaal goed zat.
Natuurlijk, de individuele commando's werkten, maar de hele integratie voelde toch niet goed.
Kortom ik loop met het idee in het achterhoofd dat ik in JCS misschien ook andere centrales wil kunnen ondersteunen (al moet ik daar dan wel de beschikking over hebben).

Ik het het tot nu toe alles gebouwd gebaseerd op een Marklin CS-3 dat een redelijk uitgebreide functie set heeft. Bij de implementatie DCC-EX kwam ik er achter dat die welles waar de hoofd zaken kan, maar bv specifieke dingen als het kunnen downloaden van een lok plaatje oid vanuit de centrale niet ondersteund.

Ik ben een rond gaan kijken om het ontwerp te voorzien van een "centrale HAL" (Hardware Abstraction Layer) m.a.w. een laag die op functioneel iedere centrale zou kunnen zijn.
Ik kom tot nu toe op de volgende functionaliteiten (na enig rond kijken):

Verbinding met de centrale, serieel, via netwerk etc
Command en Control, aansturen van locomotieven en accessoires (met verschillende protocollen denk aan MM,DCC,MFX, SX etc).
Feedback, het kunnen uitlezen van sensoren (melders) via een of andere bus (S88, loconet etc.).
Opvragen van de in de centrale bekende locomotieven (roster?)
Opvragen van de in de centrale bekende accessoires (Wissels, seinen)
Opvragen van de locomotief afbeeldingen
Opvragen van de locomotief functies en afbeeldingen
Manueel kunnen opvoeren van locomotieven met evt plaatje
Manueel kunnen opvoeren van locomotief functies met evt plaatje
Manueel kunnen opvoeren van accessoires (wissels en seinen)
Manueel kunnen opvoeren van melders


Zie ik nog iets over het hoofd?

Ik ben ieder geval met een prototype begonnen van een Centrale keuze scherm die toont welke functionaliteiten een centrale heeft zodat de software weet of iets kan of niet kan. Enfin dus een stapje terug om het uiteindelijk beter te krijgen.

Groet,

Frans

Hi @fransja ,

Ja, zn HAL is wel must zodra je meerdere centrales gaat ondersteunen. Ik heb het in Traintastic opgelost door elk protocol/systeem een aantal controllers te geven.

Een Interface (=brug tussen hardware en traintastic) ondersteund een of meerdere Controllers:
- DecoderController - Aansturen van locomotieven
- InputController - Uitlezen van melders
- OutputController - Aansturen van uitgangen/accessory decoders
- IdentificationController - Uitlezen van identificatie sensoren, b.v. RailCOM of LISSY IR.

Die identificatie mist denk ik nog in je lijstje, ik weet niet of Marklin daar een systeem voor heeft, DCC-EX niet iig. LocoNet en ECoS iig wel

In mijne mist een generieke manier om lok info op te halen, de ECoS en Marklin CS kunnen dat, dat is nu in Traintastic nog niet echt generiek. Dat zou eigenlijk wel moeten #goedidee

Elke Interface heeft ook een of meerdere IOHandlers, een IOHandler regelt de Seriele of Netwerk communicatie, zodat de rest van de software niet meer hoeft te weten of het nu serieel of netwerk is

Dit is overigens versie 2 van Traintastic's HAL, met de eerste versie liep ik vast op wat beperkingen. Zodra je meer hardware gaat ondersteunen kom je er al snel achter dat er toch wel wat verschillen zitten tussen de systemen. Traintastic ondersteund nu 9 soorten: DCC-EX, HSI-88, LocoNet, XpressNet, ECoS, Marklin CS 2/3, Z21, Traintastic DIY en ben bezig met Selectrix.

Reinder

Het is alweer enkele weken geleden dat ik melde dat ik terug naar de tekentafel moest met het ontwerp van JCS.
Het bleek dat ik de programmatuur teveel op de CSen van Marklin had gebaseerd en dat het toevoegen van de, relatief eenvoudige, DCC-EX centrale toch lastiger was dan gedacht.

Dus heb ik de stoute schoenen aangetrokken on het ontwerp zodanig te wijzigen dat het mogelijk is om in de toekomst andere hardware toe te voegen (zou zelf graag een naar de ESU ECOS kijken, maar die heb ik helaas niet, maar als ik er een kan lenen voor een tijdje hou ik me aanbevolen ).

Daarvoor heb ik nu een zogenaamde Hardware Abstraction Layer gemaakt in JCS.
Ik heb een "hardware centrale" in de volgende (min of meer) losse delen (functionaliteiten) opgeknipt:

• [li]Decoder controller; de hardware die het digitale signaal op de rails zet. hier zitten bv de de functies om de locomotieven te besturen. Hier kan er maar 1 van zijn.[/li]
  [li]Accessoire controller; kan accessoires schakelen, denk hierbij aan wissels, seinen, verlichting, etc. Er kunnen er meer dan 1 zijn.[/li]
  [li]Feedback controller; "luistert" naar terugmeldingen, er kunnen er meer dan 1 van zijn.[/li]

@reinder de Identificatie controller heb ik nog even op de "back burner" staan daar ik geen Esos of loco net apparatuur heb om het überhaupt te kunnen testen, maar is wel een zeer valide optie.

Het kan natuurlijk zo zijn dat de aangesloten centrale al deze 3 controllers functioneel implementeert, maar dat hoeft dus niet.

Een centrale kan worden aangesloten via een seriale (USB) of een netwerk verbinding.
Dan kan een controller nog speciale "capaciteiten" ondersteunen, denk hierbij aan bv het downloaden van locomotief afbeeldingen synchroniseren van accessoires, stroom metingen van de rails, etc.

Kortom dit alles kan worden ingesteld op een configuratie scherm van de ondersteunde centrales (nu Marklin CS en DCC-EX). Omdat er nu ook centrales kunnen worden gebruikt waar uit je niet de locomotieven en accessoires uit kan importeren moest ik daar dus nieuwe invoer schermen voor maken zodat je dus locomotieven kan importeren uit de centrale of manueel kan invoeren. Dit ook gemaakt voor de accessoires. Ik had al een zg driver cab of throttle scherm gemaakt (zie vorige post) hier is nu ook een accessoire keyboard aan toegevoegd. Kortom gestage vorderingen, ben nu bezig met het terug meld gedeelte.
Voor de DCC-EX centrale moet ik nog uitzoeken hoe ik dit precies hardware-matig ga aanpakken met bv een S88 ingang.
Voor de CS-2 werkt het al min of meer, voor de CS3 moet ik sinds de update naar software versie 2.5.1 het e.e.a. uitzoeken (lees reverse engineeren) daar die niet meer werkt zoals in de documentatie staat.

Groet,
Frans

Hallo,

Afgelopen weken verder gewerkt aan mijn software project, of toch niet. Ik kom nu in een stadium dat ik "echt" locomotieven kan laten rijden van uit de software. Echter het is nog niet zover dat ik dat op m'n baan kan doen, vandaar dat ik ben begonnen met de constructie van een test baantje. Hiervoor diep in de berging gedoken om eea aan oude M rails op te halen.
Voor de besturing wordt de DCC-EX gebruikt, maar omdat ik ook terugmelders nodig heb en dat, in eerste instantie, het lieft op S88 basis wilde doen, die ik nog had liggen .
Heb ik, geïnspireerd door het filmpje van @AlbertG, een HSI-S88 gemaakt.
DCC-EX
Komende tijd het HSI 88 protocol toevoegen aan JCS, dat nu "soepeler" moet gaan daar er een HAL is, dus gelijk een goede test .

Testbaantje opgebouwd, en opgepoetst(!) zie hier de test opstelling.
Het moet nog op een plank worden geschroefd en de bedrading natuurlijk een beetje netter, maar het eea werkt nu.
Ik kan met 2 kleine locomotieven heen en weer rijden

De (code) vorderingen zijn te volgen op github, maar kan niet beloven dat het altijd werkt

Groet,

Frans

Mooie stappen! Ik blijf het volgen

Van mij krijg je een vind het geweldig dat je dit kan.

Testers gezocht!
Met gepaste trots ben ik eindelijk zover gekomen dat ik denk dat het project min of meer bruikbaar is.
Zeker als een Throttle voor DCC-EX.

Wat kan er nu mee:

• Throttle voor DCC-EX, via de schermen kun je (DCC) locomotieven besturen.

• Bedienen Wissels en Seinen.

• Tekenen en tonen Spoorplan.

• Tonen van Sensor status en bedienen van Wissels via Spoorplan.

Voor terug meldingen heb je een losse HSI-S88 nodig. JCS ondersteund nog niet de Feedback van DCC-EX centrale zelf.

Ik heb een geprobeerd JCS vanaf de download te configureren op een "schone" windows PC.
Daar kwamen nog wel de nodige foutje mee aan het licht, dus dat was een hele goede test

Uiteindelijk heb ik mijn test baan hierin geconfigureerd.
Ik kan in met 2 locomotieven rijden, de 2 wissels bedienen en 8 sensors zien.

De DCC-EX en de HSI-S88 zijn via de seriele poort verbonden met de computer.
Ik denk niet dat alle issues er al uit zijn vandaar dat dit dan ook versie 0.0.1 is.
Jullie hulp met testen en of suggesties worden op prijs gesteld!

De files zijn te hier te downloaden
Er is een zip file voor Windows, Max en Linux.
De source code staat hier.

Ik ben ook begonnen met het maken van documentatie. Dat is een hele klus!
Een begin is hier te vinden.
Let op: Niet alles is al beschreven (...).

Om de software te kunnen draaien is een JDK of JRE versie 21 benodigd, hier is uitgelegd dit gaat.

De eerste stappen met JCS staan hier beschreven.

:important: Letop dit is Werk in Uitvoering dus voortschrijdend inzicht kan van toepassing zijn

Voor mensen met een Github account [kun je me gelijk een Star geven ] kan je hier issues maken.

Voor degenen die willen testen alvast bedankt!

Groet,

Frans

Hallo allemaal,

Als eerste dank voor de reacties op de eerst release. Aan een 2 update wordt gewerkt.
Het is erg leuk om te zien dat dit opensource project dat op github staat wereldwijd door mensen mensen als inspiratie en als throttle voor DCC-EX wordt getest/gebruikt (en als je een github account hebt geef een ster ).

Een aantal maanden geleden had ik al iets verteld hoe de layout in JCS wordt getekend, nl met "tegeltjes".
Een "tegeltje" representeert een stuk rails. Dit kan een gewone rechte rails zijn, een bocht, een wissel, een kruising, een blok, etc.

Om automatisch te kunnen rijden moet een trein dus "weten" hoe die van A naar B komt, m.a.w de route. Kortom er moet een soort van "Tom Tom" functionaliteit zijn die de plattegrond kan "lezen".
Ik heb hier voor een Router gemaakt. Deze router vertaald als eerste de plattegrond in een zg grafisch object model.
Vervolgens wordt er een route algoritme op "los gelaten" die de verbindingen maakt (soms wordt het zelfs AI genoemd, maar zo ver wil ik niet gaan daar de methodiek reeds vele tientallen jaren bestaat).

Ik mijn onderzoek naar deze functionaliteit kom je gek genoeg enorm veel voorbeeld programma's en blog post's tegen over het laatste stukje van de routing puzzel, het algoritme.
De 3 meeste gebruikte hiervan zijn:

• [li]Dijkstra of Kortste pad algoritme. [/li]
  [li]A * (ster) (wordt in JCS gebruikt).[/li]
  [li]Breathfirst (wordt veel in games gebruikt).[/li]

Maar bij al deze blog post's en voorbeelden was de grafische data structuur er al bij gezet.
Het maken de grafische structuur is nu juist het meest lastige stuk, hoe vertaal je een plattegrond in zo'n grafische structuur?

Hoe heb ik dat in JCS opgelost:

Een graph structuur bestaat in essentie uit nodes en edges. Een node kan gezien worden als een fysieke locatie. De edge is de verbinding tussen 2 nodes. Een Edge, (wordt ook wel vector genoemd) heeft een richting, dus van er is een Edge van A naar B en een van B naar A.
Een Edge heeft ook een lengte, Deze lengte wordt later gebruikt om de optimale route te vinden.

In de Graph structuur wordt in JCS iedere tegel een node. De Edges zijn de verbindings punten van de rails die op de tegel wordt afgebeeld. (de "paarse" cirkels in de tekening).
De Node kan dus van A naar B en van B naar A (in de tekening met 3 tegels dus van A naar B en B naar A en van B naar C en C naar B).

Een Wissel is een "specialtje", daar kan je 3 kanten op. Een wissel heeft 6 edges. Echter een wissel heeft een beperking.
Ja kan nl van A naar B, van A naar C, van B naar A en van C naar A maar niet van C naar B. Deze beperking wordt actief tijdens het routeer proces. Bij het maken van de grafische structuur zullen in eerste instantie alle Edges, ook die van B naar C en C naar B gemaakt worden.

A * (ster) algoritme

Zodra de grafische structuur is gemaakt wordt er getraceerd.
In een blok gestuurde omgeving zoals bij de meeste trein besturing programma's kan een trein van blok naar blok rijden. De route tussen 2 blokken wordt ook wel de rijweg genoemd.
In JCS wordt er een lijst gemaakt van alle blokken en vervolgens wordt er getest of er een route bestaat van een blok naar een ander blok.

Voor mijn test baan bijvoorbeeld zijn er 8 routes of rijwegen mogelijk. In het route paneel kun je ze selecteren en dan wordt de rijweg getoond. Tot zover de vorderingen van JCS, naast het verhelpen van foutjes in de eerste release ben ik nu bezig met het opzetten van automatisch rijden. Dit is de volgende grote puzzel.

Groeten,

Frans

Hallo allemaal,

Als eerste dank voor de reacties

Afgelopen weken heb ik weer wat vorderingen gemaakt met JCS.
Ik ben begonnen met het van automatisch rijden. Dit is een hele kluif! (maar wel zeer leerzaam )

Als eerste een z.g. State machine gemaakt.
Het functioneel op een rijtje krijgen wat je precies allemaal moet doen heb ik zo getracht te modelleren.
Het volgen van dit state-machine pattern helpt mij om functioneel te beschrijven wat je moet doen en dit dan om te zetten in code.

Iedere locomotief die automatisch gaat rijden wordt gezien als een apart (sub) proces, een Thread.
De status kan pas verder springen als en aan bepaalde voorwaarde(s) is voldaan.

Voordat de auto mode wordt gestart wordt er "geabonneerd" op alle melders.
Zodra een melder afgaat die niet is verwacht wordt dit als "Spook" gezien en wordt de spanning van de centrale uitgeschakeld.

Ik heb de volgende functionele stappen gedefinieerd::

• [li]Idle. Initiële status, als de locomotief in een blok staat kan naar de volgende status worden overgegaan.[/li]
  [li]SearchRoute. Zoek een route naar een volgend blok. Als er geen route is check of de locomotief van richting kan veranderen (een pendeltrein) zo ja probeer het met omgekeerde richting. Door als route is gevonden[/li]
  [li]LockRoute. Reserveer de route, zet de blokken in de juiste status, zet de wissels om. Een gereserveerde route of routedelen kunnen niet door een andere route worden gebruikt. Door als dit gelukt is.[/li]
  [li]Start Loco. Zet de melders in het vertrek blok tijdelijk uit, abonneer op de aankomstmelder in het bestemmings-blok. Start de locomotief op kruissnelheid (75%).[/li]
  [li]EnterDestination. Wacht op de aankomstmelder in het bestemmings-blok. Zodra deze afgaat (de trein rijdt dan het blok binnen) verlaag dan de snelheid van de locomotief tot 10%. Zet de status van het bestemmings-blok op "Binnenrijden", zet de melders in het vertrek blok weer aan. Abonneer op de bezet melder van het bestemmingsblok.[/li]
  [li]DestinationReached. Wacht op de bezetmelder van het bestemmings-blok. Zodra deze is afgegaan stop de locomotief (de bestemming is bereikt). Zet de status van het vertrek blok op "Vrij" Zet de status van het bestemmings-blok op "Bezet". Geef de route weer vrij, schakel alle melders vrij. Spring naar de wacht status.[/li]
  [li]Wait. Wacht een vooraf ingestelde tijd, als de automode is uitgeschakeld spring naar einde, anders naar SearchRoute.[/li]

Als ik dit zo opschrijf lijkt allemaal simpel, maar is het viel soms behoorlijk tegen voordat ik het goed functioneel had beschreven, laat staan geprogrammeerd.
Ik kwam allerlei deelproblemen tegen. Met name aan de GUI kant. Om namelijk het proces te begrijpen is een goede grafische terugkoppeling naar de gebruiker essentieel.
Idle, locomotief in Blok 1 geplaatst. Bv bij de reserveer stap wordt de route in een bepaalde kleur getekend, die per stap kan verschillen. Hiervoor moest ik nogal wat rededesign doen, omdat ik iedere tegel waaruit de layout tekening is opgebouwd moet kunnen adresseren vanuit de "Auto Pilot" om feedback over het proces te geven. Ook de tekening van de blokken heb ik aangepast om meer ruimte te krijgen. De + en - zijn vervangen door een dikke streep aan de + kant. Deze ruimte was nodig om de locomotief naam en afbeelding en de richting van de route te kunnen tonen.
Aankomst in bestemmings-blok (enter). Aangekomen in bestemmings-blok (in)
Ik heb een "Statemachine stepper" gemaakt en een virtuele centrale om e.e.a te kunnen debuggen. Dit proces is nog in volle gang. Komende tijd nog veel debuggen nodig, maar hoop binnen niet al te lange tijd het fysiek op mijn te kunnen gaan testen B) .

Groeten,

Frans

Hoi Frans,

Wat een werk!

En knap ook hoe je het zo begrijpelijk opschrijft. Dan kan ik er nog steeds niet veel mee, maar ik vind het volgen van het proces wel interessant.

Hallo,

Een heugelijk moment voor mijzelf: de eerste keer dat JCS een locomotief automatisch laat pendelen op de test baan.
https://www.youtube.com/watch?v=CyLmGk6gfHA

Er moet nog veel gebeuren maar ik ben blij met dit resultaat.
Centrale is DCC-E Melders via HSI-S88.

Mooie sprong vooruit, Frans!

Hallo,

Als eerst dank voor alle reacties!
Het is alweer enkele weken geleden dat ik meldde dat ik automatisch kon pendelen met 1 locomotief.
Inmiddels kan dat met 2 of meer. Dit vergde toch wel weer wat refactoring.
Met meerdere locomotieven moet je er namelijk zeker van zijn dat de rijweg maar door 1 locomotief bereden kan worden. Ook moeten wissels die door meerdere rijwegen gedeeld worden een locked status hebben, zodat ze niet ineens worden omgezet.
Hiervoor waar dan ook de nodige wijzigingen in mijn programma noodzakelijk.

Ook het resetten van rijwegen bleek zeer wel noodzakelijk en ben ik nu aan het implementeren.
De State machine zoals ik die die in een eerdere post beschreef is dan ook behoorlijk veranderd.

Heel belangrijk bij software ontwikkeling in het algemeen is testen.
Behalve de testen om m'n buro in een "nerd" setting, ben ik nu begonnen met het toevoegen van automatische testen.
Daar leer ik ook veel van, omdat je ieder stapje van de state machine moet zien na te bootsten in een multi-threaded omgeving.

De eerste testen zijn nu gemaakt. Als voorbeeld:

• Zet locomotief in een blok.

• Zet de blok status van een van de 2 mogelijke bestemmingen op buitengebruik, zodat je zeker weet dat er maar 1 route gekozen kan worden.

• Start de automaat voor deze locomotief.

• Check of de verwachte route gevonden wordt naar de verwachte bestemming.

• Start de locomotief (virtueel).

• Check of de kruissnelheid is ingesteld en de vertrek blok sensors zijn uitgeschakeld.

• Meld de bestemmings- blok inrij sensor (enter).

• Controleer of de status van de State machine van StartState naar EnterState verspringt.

• Controleer of de locomotief een lagere snelheid heeft gekregen.

• Laat de 2e melder van het bestemmings-blok melden (in).

• Controleer of de locomotief stopt.

• Controleer of de state machine de InState verspringt.

• wacht heel even (100ms).

• Controleer of de state machine de WaitState verspringt.

• enz..

Er moeten er nog een heel aantal gemaakt worden...

Een ander belangrijk aspect is de bediening.
Ik heb ook veel tijd gestoken aan het verbeteren van de UI.
Ik kwam er pas achter bij het testen van de Autopilot dat je allerlei menu's of menu items nodig hebt (daar sta je pas bij stil als je zo iets probeer zelf te maken) om bv een locomotief in een blok te zetten, te starten, stoppen, resetten etc. Ook het in een blok plaatsten van een locomotief. Visueel heb ik dit opgelost door het locomotief icon te tonen in het blok. De rijrichting van de locomotief t.o.v. het blok moet je kunnen instellen. Ook het op de UI laten zien van wat er aan het gebeuren is is zeer belangrijk om een gebruikers vriendelijk programma te krijgen waar de gebruiker ook kan begrijpen wat er precies gebeurt is soms een hele uitdaging.

Enfin, ben nu naar de 2 release aan het toewerken, maar eerst vakantie

Iedereen een fijne vakantie toe gewenst.

Frans

Hallo,

Hier een korte update van JCS. Door de vakantie een paar weken even niet aan mijn modelspoor automatiserings project (JCS) gewerkt.
Dat heeft goed gewerkt. Na mij vakantie was het op sommige punten even nadenken wat ik ook alweer aan het doen was
Dus er even uit help ieder geval tegen tunnel visie.

Vlak voor mijn vakantie had ik al gemeld dat ik met meerdere locomotieven kon rijden maar die ging niet helemaal foutloos.
Na mijn vakantie heb ik mijn gestort in het schijven van test cases, zodat ik de State Machine stap voor stap kan door testen.
Hier kwam veel uit. (Grappig hoe je altijd weer wordt afgestraft als je ergens een short-cut maakt om iets voor elkaar te krijgen).

Enfin na de nodige issues met Threads (~tegelijkertijd tijd lopende “processen”) heb ik nu een versie die heel netjes meerdere locomotieven kan besturen.
Om verde testen te vereenvoudigen heb in een Virtuele Centrale in JCS toegevoegd (naast de bestaande fysieke centrales Markin CS 2/3 en DCC-EX plus HSI-S88). Deze Virtuele Centrale triggert automatisch de eerst volgende sensor die een locomotief nadert als die rijdt.

Ik heb in middel een nieuwe virtuele test baan gemaakt. Waar in dit voorbeeld 2 locomotieven rijden, ik heb er een
YouTube filmpje van gemaakt.

Nu moet ik nog een hoop scherm wijzigingen maken, bv om de wachttijd per blok te kunnen instellen.
En natuurlijk test cases.
Werk nu toe naar de 2e release.

Inmiddels ben ik ook op zoek naar iemand die mij een ESU Ecos voor enige tijd kan lenen, zodat ik deze hardware ook kan ondersteunen.

Zoals altijd staan de laatste wijzigingen op Github (actieve branch op dit moment is 15-automatic-control)

Frans

Hallo,

Afgelopen weken heb ik verder gewerkt aan mijn besturings- software project JCS.
In de vorige bijdrage had ik al vermeld dat ik bezig was met het maken van testcases, zgn Unit tests. Deze Unit tests testen "los" een functie in de software.
Ik heb hard gewerkt om de module die het automatische rijden “regelt", grondig door te testen.
Hier kwamen de nodige issues naar voren. Het is een redelijk complex stuk, daar het in meerdere threads (processen) asynchroon draait. Er gebeuren er allerlei dingen tegelijkertijd.
Het heeft me enkele brein krakers en tijd gekost om het goed door te testen.

Ik denk dat ik nu op een punt gekomen ben gekomen waar het er nu echt op lijkt dat de software stabiel en goed werkt, althans bij mij dan

Vervolgens ben ik aan de gang gegaan met het maken van documentatie. Dit werkte voor mij verhelderend om eens alle stappen op te schrijven die je moet nemen voordat je überhaupt automatisch kan rijden. Ik heb dit aan de hand van mijn testbaan met de DCC-EX gedaan.
Dit bleek okk een hele goede test. Ik heb me verbaast over het aantal stappen dat je moet nemen.
Als je bezig ben met de software zelf te maken sta je er niet zo bij stil, daar je bezig bent met een klein stapje te bouwen, maar nu ik naar het geheel kijk was dat toch heel verhelderend.
Nooit echt bij stil gestaan hoeveel stappen moet nemen voordat je automatisch kan rijden. Inmiddels ook documentatie gemaakt in het Nederlands, Setup Guide voor JCS en Rijden met JCS

Als klap op de vuurpijl, met toch wel een beetje gepaste trots, heb ik m’n eigen baan (zolderhoek) in JCS getekend en kan nu met 4 treinen automatisch rijden. Terwijl dit rijdt heb ik alweer nieuwe ideeën om het programma te verbeteren

Ook is er een nieuwe release, versie 0.0.2 gepubliceerd.
Ik nodig iedereen, uit te testen, daar kan ik nog wel hulp gebruiken hoe meer hoe beter.

Inmiddels ben ik in het bezit gekomen van een ESU Ecos 50000. Volgende stap is het toevoegen van deze centrale.

Groet,
Frans

Hallo,

Het is alweer enige tijd geleden dat ik iets het gepost over mijn JCS project. Ik maak nog steeds vorderingen

In mij laatste post had ik al vermeld dat ik in het bezit ben gekomen van een ESU EoS 50000. Ik ben nu bezig met het implementeren van het protocol.
En ik heb inmiddels verbinding.

Daar deze ECoS (inmiddels) 2 strepen in het scherm heeft (als iemand weet waar ik een vervangend scherm zou kunnen krijgen, graag).
Ik heb bedacht ik dat het "leuk" zou zijn dat JCS een ingebouwde VNC viewer krijgt (ook handig voor de Marklin CS3) dus ben ik daar mee begonnen en zie hier het eerste resultaat.
Toen ik deze VNC viewer aan het bouwen was en tijdens reverse engineering van het protocol kwam ik er achter dat ESU Ecos MDNS ondersteund.

Voor die genen die dit niets zegt, MDNS is een methodiek om apparaten op je netwerk automatisch te vinden. Dus ook dit ingebouwd.
JCS vindt nu de ECoS automatisch, je hoeft het ip-adres niet in te voeren.
Het enige is dat ze in het zelfde netwerk segment moeten zitten, maar dat is bij de meeste thuis netwerken meestal wel het geval.

Wat bleek verder dat ook de Marklin CS 3 dit ondersteund (al had ik automatisch vinden van het CS-3 ip-adres al op de "Marklin" manier geïmplementeerd).

Het protocol van de ESU is compleet anders als bij Marklin. Heb inmiddels "first light"
Kan nu het ECoS basis object uitlezen, krijg door hoeveel terug meld modules er zijn geconfigureerd en krijg nu de terug meldingen binnen.
Kan ook de rail spanning aan en uit zetten en krijg events binne als de rail spanning op de ECoS zelf wordt in of uitgeschakeld.

Ga nu beginnen aan het Locomotief gedeelte.
Ik moet binnen JCS wel het e.e.a. aanpassen om het ook met de ECoS te laten werken. Helaas blijkt de HAL nog niet abstract genoeg, maar het wordt er dus uiteindelijk alleen maar beter van.

Tot zo ver de vorderingen.
Zoals altijd is dit ook te volgen op github.

BTW heb je een github account laat een ster achter

Groet,
Frans

Ondersteuning van het Z21 protocol opent de weg naar Digikeijs, Yamorc en de Roco/Fleischman z21/Z21 familie.
Is dat iets wat je op de roadmap wil zetten?

Als het op lenen van apparatuur gaat dan is er wellicht wat te regelen.
(Heb zelf 2x een DR500 omgebouwd naar YD7001 en een witte z21.)

En wellicht wil Martin of Karst ook wel iets regelen qua lenen.

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

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

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:

• [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]

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

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

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.

Ahhh. Sliding windows verhaal uit de TCP/IP wereld.
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.

reinder schreef: ↑18 jan 2025, 22:26 Heb je ook simulatie gemaakt voor Marklin CS3 en DCC-EX?

Die staan nog op de nominatie om te doen, ik wil tenslotte overal min of meer de zelfde structuur hebben.

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.

Goede suggestie, ga hier zeker naar kijken, al heb ik met mijn testen tot nu toe er geen last van gehad.

Grappig hoe de "nog te doen dingen" queue steeds weer vol loopt

Groet,

Frans

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

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

hey Frans, knap werk man, het NERD gehalte staat op hoog,
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

Hi Reinder,

Dat is inderdaad een leuk idee.
Door jou idee zit ik er nu aan te denken dat ik de virtuele commandos dus ook naar buiten zou kunnen sturen (waardoor JCS een virtueel command station zou kunnen worden)...
Daardoor zou je dus cross technologie kunnen testen (JCS is java en Traintasic is C++) en met verschillende inval hoeken (verschillende auteurs los van elkaar).
Bijvoorbeeld : Ik laat een Traintastic virtuele centrale draaien on de JCS functionaliteit te testen en vice versa.
Ik zie een hoop mogelijkheden

Volgens mij mag dat bij Marklin zonder problemen, maar bij ESU licentie technisch mag het niet om dat je dan voor "server" speelt...

Qua planning komt dit idee wel goed uit daar ik nu na de GUI issues ben begonnen aan de "virtuele CS 3".
Dit omdat ik dat ook al voor de Ecos had gedaan en omdat ik de CS implementatie moet aanpassen aan de gewijzigde HAL.

Welke centrale emuleert die nu?
Ik ondersteun nu CS2/3, ESU Ecos en DCC-EX.

Enfin dat houdt je van de straat

Groet,
Frans

Hi Frans,

De Traintastic simulator emuleert geen centrale, dat doet Traintastic server, dat heb ik er in den beginne direct al ingemaakt.

Het werkt in Traintastic server als volgt, het systeem bestaat grofweg uit drie soorten objecten:
1. De interface, het basis object voor een verbinding met de buiten wereld.
2. Kernel, deze wordt aangemaakt op het moment dat de interface online gaat, hierin wordt het hele protocol afgehandeld op bericht niveau.
3. IOHandler, vertaling van serieel/netwerk etc.naar protocol berichten.

Voor elk systeem: LocoNet/XpressNet/ECoS/Marklin/Z21/DCC-EX etc. is er 1 interface, 1 kernel en 1 of meer IO handlers.
Voor DCC-EX zijn er bijvoorbeeld twee: 1 voor serieel en 1 voor netwerk.

Wat ik in simulatie mode doe is een SimulationIOHandler aan de kernel koppelen, dit is een speciale IO handler die dus het gedrag van een centrale nabootst.

Met de nieuwe Traintastic simulator werkt het als volgt, ik bouw de opstelling hierboven op met zn SimulationIOHandler.
Vanuit de SimulationIOHandler maak ik verbinding (TCP) met Traintastic simulator.
Als er bij de SimulationIOHandler een lok commando binnen komt dat stuur ik een lokcommando naar Traintastic simulator.
Als in Traintastic simulator een trein een sensor triggert dan stuurt die een bericht naar de SimulationIOHandler, die zet dat vervolgens om naar bijvoorbeeld een LocoNet OPC_INPUT_REP, dat gaat naar de LocoNet kernel en dan vervolgt het zn weg door de software.

Hoe kun je hem aan JCS koppelen?
Vanuit je virtuele ECoS maak je verbinding met Traintastic Simulator, op het moment dat je op je virtuele ECoS een lok command binnen krijgt stuur je een bericht naar de simulator.
Als je van de simulator een sensor bericht krijg zet je dat om naar wat JCS wil en dan zou het moeten werken.

Beide Traintastic simulator protocol berichten zijn kleine bineare berichten, zie: https://github.com/traintastic/traintas ... otocol.hpp

Groeten,
Reinder

p.s. hoop dat het beetje duidelijk omschreven is
p.s.2. verwacht dat de work in progess simulator ergens dit weekend in windows installer komt

Hi Frans,

Inmiddels heb ik een Traintastic simulator in de Windows installer zitten, je kan deze vinden op: https://traintastic.org/en-us/download/ ... -simulator

Reinder

Hi Reinder,

Mooi dat het in de installatie zit scheelt weer compileren .

Ik ga er mee aan de slag, maar door ziekte van mijn ega zal er wel enige tijd overeen gaan.
Moet dus eerst nog de Marklin implementatie aan de HAL aanpassen en dan ga ik kijken of ik met de Traintastic centrale simulator kan verbinden.
Ik neem aan dat ik het op een Windows "doos" kan draaien en over het netwerk met JCS kan praten, altans dat heb ik nu min of meer in gedachte.

Groet,

Frans

Hi Frans,

Strekte met de ziekte van je ega! Dat gaat natuurlijk voor.

In de installer ff een vinkje zetten en het zou moeten werken, standaard staat het uit namelijk.
Op het moment luister de simulator alleen op localhost, dat zal ik nog ff instelbaar maken.

Reinder