Her kommer historien om, hvordan jeg har sat JMRI op til at styre min bane. Forhåbentlig kan det tjene til at hjælpe flere i gang med at bruge JMRI.

Allernederst finder du en overordnet trin for trin anvisning på at komme i gang med JMRI.

Indledende ord:

Mine første erfaringer med JMRI tilbage i starten af 2014 var ikke entydigt positive. Programmet og dokumentationen er ikke sådan lige at overskue.

Programmet er ikke et program, men et bibliotek af grundlæggende interface-software mod diverse DCC-systemer, grundlæggende logik-programmel (kaldet Logix), et scripting interface (mulighed for at implementere stort set hvad som helst i Jython sproget) samt ikke mindst flere forskellige gode folks applikationssoftware, der bygger på dette grundlag. Nogle applikationer er kun halvfærdige, nogle er inkluderet i JMRI pakken og nogle (f.eks. CATS) er ikke.

Dokumentation:

Dokumentationen er tilsvarende fragmenteret. Der er ikke ét sted, hvor man kan læse om den eneste måde et eller andet kan gøres i JMRI. For det første er der næsten altid flere (meget) forskellige måder at opnå et eller andet på, og for det andet er der mange forskellige kilder:

Youtube videoer
JMRIs hjemmeside
Yahoo JMRI user group siden
Myriader af andre hjemmesider.

Jeg har følgende erfaringer/kommentarer:

– Yahoo gruppen er meget anvendt til at søge svar på specifikke spørgsmål. Der er livlig trafik og masser af hjælpsomme folk. De få spørgsmål, jeg har stillet, er blevet positivt besvaret på ganske kort tid. Det er til gengæld ikke overskueligt for mig at søge i de indlæg andre allerede har skrevet. Så det har ikke været en kilde til information for mig.

– Yahoo gruppen indeholder også et filområde. Det kræver medlemsskab af gruppen at tilgå, men det indeholder til gengæld en del god information, f.eks. manualen til AutoDispatcher2: https://groups.yahoo.com/neo/groups/jmriusers/files/AutoDispatcher/AutoDispatcher2manual/

– JMRI hjemmesiden er ikke overskuelig. Den har en god søgefunktion (dvs. Google) og ret mange velskrevne manualsider. Men der mangler et overblik og en guide til hvilke dele af JMRI, der bedst anvendes i hvilke sammenhænge.

– Kodebasen findes hos ~~Sourceforge.net~~ – rettelse: Den er flyttet til GitHub.com. Det er til gengæld overraskende nemt at finde rundt i. Især efter at have oversat og eksekveret i debuggeren i NetBeans.

– Der er mange Youtube videoer med instruktioner i, hvordan man installerer JMRI. Det ligger lidt tungere med den lidt mere avancerede anvendelse af JMRI. De findes muligvis, men Youtubes søgemuligheder har ikke gjort mig i stand til at finde guldet.

“Getting Started”:

Den første berøring med JMRI kan godt være ret forvirrende. Et godt råd er at begynde med at strejfe rundt på http://jmri.org/

På den rundtur skal man bl.a. forbi de såkaldte clinics, som er slideshows og videoer, som instruerer i visse specifikke anvendelser af specifikke dele af JMRI. Link til det generelle clinic område: http://jmri.org/community/clinics/

Jeg har især haft glæde af denne clinic, som instruerer i anvendelse af Layout Editor samt i opsætning af signalmaster. Bemærk, at allerede her ligger der op til flere valg, hvor jeg endnu ikke er helt sikker på, om jeg virkelig har valgt det optimale:
– Layout Editor fremfor Panel Editor
– Signal master og logik fremfor signal hoveder og simpel signal logik.
Forklaring følger senere.

For at komme i gang med selve programmet, begynder man naturligvis med at downloade og installere. Som nævnt er det meget nemt at finde hjælp til dette, hvis man finder det nødvendigt. Selve installationen er nu ellers lige ud af landevejen, så det er nok det punkt, hvor der er mindst brug for hjælp.

Dernæst kommer forvirringen frem: Man har ikke fået et program ved navn JMRI. Man har fået et antal programmer, hvor nogen har et ikon på skrivebordet og andre ikke. F.eks. har man fået PanelPro og DecoderPro.

Jeg kan ikke helt gøre rede for alle de forskelle, der er på de forskellige programmer. Men forskellene er ikke overvældende. Det er stort set de samme menupunkter og knapper, der er tilgængelige. Og alt (næsten) kan konfigureres.

Den grundlæggende ide er dog, at DecoderPro er beregnet til når man vil programmer dekodere og PanelPro er til opsætning og anvendelse af de “paneler” (dvs. vinduer), der viser og definerer det fysiske layout på banen.

Efter installation af JMRI kan man dobbeltklikke på en vilkårlig af de ovennævnte ikoner på skrivebordet for at starte JMRI og komme i gang med konfiguration m.v.

Der er dog lige en enkelt komplikation: Hvis man som jeg og efterhånden de fleste Windows brugere har en 64-bit Windows version, så kan der være lidt komplikationer med at få lyd ud af Virtual Sound Decoder (en tilføjelse til JMRI, som kan lave lyde ud af PC højttalerne stort set som en lyddekoder indbygget i et lokomotiv – bare noget mere primitivt).

Det lykkedes mig at få det til at fungere med en blanding af voodoo og gode råd fra Yahoo gruppen. Jeg tror, at der var disse to afgørende faktorer:
1. Installere Open AL.
2. Tilføje /32bit optionen til alle de shortcuts, der bruges til at starte JMRI. Se også http://jmri.org/help/en/html/doc/Technical/StartUpScripts.shtml

Det næste er i princippet at få forbundet JMRI og PCen til sit DCC system.

Man kan dog vente lidt med det og begynde med at vælge Digitrax -> Loconet Simulator. Så kan man med PCen uden forbindelse til den fysiske verden pusle med at sætte sit system op – i hvert fald hvis det også er Loconet baseret lige som mit.

Senere kan man forbinde JMRI til det fysiske system, når man på et tidspunkt mener at have fået defineret sit layout med sporskiftere, signaler m.v. og checket at det hele fungerer.

Jeg vil dog nok råde til, at man begynder med at forbinde til det fysiske og i det mindste tester om man kan få et lokomotiv til at bevæge sig, skifte et sporskifte osv., så man får en første fornemmelse af, hvor godt eller skidt man synes det hele fungerer.

Det var stort set på dette punkt, at jeg var ved at give op i foråret 2014, fordi intet tilsyneladende fungerede sammen med min Uhlenbrock IB-COM.

Men det gør det nu. Både dekoder programmering, høje funktionsnumre i lokomotiver m.v., modtagelse af signaler fra feedback moduler og styring af sporskifter er blevet rettet i JMRIs Uhlenbrock IB-COM/Intellibox II interface.

Så hvis du har et Uhlenbrock anlæg er det i hvert fald ikke det, der skal holde dig væk fra JMRI.

Senere hen har jeg også rettet igennem med hensyn til ESU ECOS. Så også med dette system fungerer JMRI nu inklusive dekoder opsætning m.v.

Definition af dit layout i JMRI:

Processed with Snapseed. — *Moderne styrepult hos Banedanmark.*

JMRI har to forskellige forgreninger, der begynder med valget af værktøj til at definere sit layout inde i JMRI. Der er i princippet intet til hinder for at gå begge veje. Så kommer man bare til at have cirka dobbelt arbejde, for stort set alt gøres på forskellig måde i de to JMRI grene.

Jeg ved det, for jeg har opsat begge dele – først i Layout Editor og (langt) senere i Panel Editor. Og det skal siges, at anden gang var rimelig hurtigt overstået. Men mit layout er så heller ikke blandt de største. Hvis/når jeg på et tidspunkt laver en større bane, Så kommer jeg nok igen til at lave opsætningen begge steder – I Layout Editor for at få signal-mast logikken til at fungere og i Panel Editor for at få Warrants til at fungere. Læs videre. Jeg kommer tilbage til både signaler og Warrants længere nede i teksten.

Se i øvrigt denne beskrivelse fra JMRI siden, som også kort nævner en helt tredje mulighed – CATS: http://jmri.sourceforge.net/help/en/html/apps/PanelPro/PanelPro.shtml

I Panel Editor (ikke at forveksle med PanelPro) opbygger man et panel, som f.eks. det, der er vist på billedet ovenfor vha. ikoner. Det er tilsyneladende den mest oprindelige gren af JMRI. Eksemplerne viser mest klassiske amerikanske paneler, men man kan sagtens bygge det op, så det ligner hvad som helst – også et dansk panel som det på billedet ovenfor. Man kan i sidste instans lave sine egne ikoner.

PanelPro er tænkt til at ligne virkelighedens verden, hvor man i kontrolrummene har disse paneler, som betjenes af dispatcherne. Jeg kender ikke meget til den verden, men fra hvad jeg har læst og fra hvad jeg har set på Youtube minder det meget om jernbanens pendant til luftfartens flyveledere.

I starten brugte jeg ikke Panel Editor. For jeg havde den opfattelse, at hvis eller når jeg kommer til at føle trang til at have en rigtig styrepult, så køber jeg nok en touch skærm og definerer et panel i Panel Editor til at køre på den skærm. Det er nok trods alt både nemmere og billigere end at bygge en rigtig pult som den på billedet ovenfor.

Senere er jeg dog gået over til Panel Editor – ikke for at lave en styrepult, men for at definere mit layout som ikoner, der viser spor, sporskifter, signaler m.v. Mere om årsagen til dette skifte senere.

Til en begyndelse nøjedes jeg dog med Layout Editor.

Layout Editor synes jeg mere lignede noget, hvor man kan komme hurtigt i gang, og mere noget, hvor jeg kan se min sporplan og dermed bedre forstå.

I modsætning til Panel Editor, hvor man kan lave vilkårligt mange paneler, der viser vilkårlige udsnit af ens bane, så er man i Layout Editor nødt til at definere hele sit layout i et og samme panel. Det er den eneste måde den gren af JMRI kan forstå sammenhængen og dermed få signalsystemet, ruter, mere eller mindre automatisk styring af tog osv. til at fungere.

Jeg tror, at Layout Editor er “den nye skole”. Men jeg kunne tage fejl, Jeg kan dog forstå, at detaljerne omkring signalsystem m.v., der bygger ovenpå Layout Editor, har udviklet sig over de seneste år.

Forgreningerne og dermed beslutningerne ender ikke med valget af Layout Editor. Det er kun begyndelsen. Det næste valg er om signalsystemet skal bygge på signalhoveder anbragt ved sporskifterne eller på signal master anbragt mellem blokkene.

I mine første forsøg gjorde jeg det, der umiddelbart virkede nemmest, nemlig at placere signalhovederne ved alle sporskifter, som de gør det i denne clinic, der er en udmærket introduktion til Layout Editor: http://jmri.org/community/clinics/NMRA2008/LayoutEditorClinic2008/LayoutEditorClinic.pdf

Men det fungerer ikke rigtigt tilfredsstillende. Især fordi det ikke ligner den danske måde at signallere på. Se mit afsnit om signaler.

Jeg er derfor gået over til signalmaster som beskrevet i denne clinic: http://www.jmri.org/community/clinics/UK2011/

Jeg har dog gjort det med danske signaler i stedet for engelske. Det krævede lige en smule editering af nogle XML filer og tegning af ikoner. Resultatet er danske signaler på skærmen. Se mere i afsnittet om signaler. Disse tlføjelser af danske signaler er i øvrigt nu en del af JMRI. Så det behøver ingen at gentage selv.

Jeg har tyvstartet med signalopsætningen ved nogen af de aftener, jeg har tilbragt på hotelværelser (firmarejser) at have defineret den nye bane inklusive signaler i JMRI opsat til Loconet Simulator. Jeg synes, at jeg fik testet alt godt igennem – både train tracking og signal logikken.

JMRI gemmer layouts m.v. i en stor XML fil. Det er meget smart, for så kan alle og enhver bare loade filen ind i deres JMRI installation, så man på den måde kan udveksle erfaringer.

Med definitionen af dansk signallering burde alt jo nærmest klare sig selv. Men der var lige et par problemer på vejen:

– Med Uhlenbrock IB-COM (og sikkert meget andet LocoNet baseret udstyr) har alle sensorer og alle sporskifter en ukendt tilstand efter at JMRI er startet. Jeg har derfor måttet lave et script til at initialisere til en kendt tilstand. Scriptet kaldes, når jeg trykker på en knap i layout vinduet. Eller rettere, så startes scriptet op sammen med JMRI, fordi jeg har lagt ind i Preferences -> Startup, at scriptet skal startes.

Scriptet stiller sig i starten til at vente på en intern sensor, som er hæftet op på en knap (dvs. et ikon), som jeg har anbragt i Layout Editor. Dvs., at der intet sker, før jeg trykker på knappen.

Scriptet initialiserer derefter alle sporskifter, sætter alle sensorer til at indikere fri blok samt slukker og tænder for strømmen (for at få Uhlenbrock stationen til at rapportere om alle optagne blokke), samt initialiserer de virtuelle signal master ved bommene.

Alle andre signaler behøver ingen særskilt initialisering. De reagerer på sensorer og sporskifter og initialiseres derfor sammen med disse.

Efter at have indført ECOS command station har store dele af dette script kunnet undværes, fordi aktuel tilstand af sporskifter og sensorer kan læses fra ECOS modsat Uhlenbrock stationen.

– Visse signaler fungerede ikke med den autogenererede logik. Nogle steder kunne der f.eks. være et sporskifte, som den autogenererede logik mente skulle være THROWN, mens den i virkeligheden skal være CLOSED. Men så går man bare ind og editerer pågældende logik ved at sætte kryds i listen af sporskifter og vælger CLOSED.

Andre steder – især rundt om krydssporskiftet – var der mere, der skulle gøres. Her har jeg defineret nogle flere stumper Logix. Det forklares ganske udmærket i ovennævnte clinic, hvordan man laver disse forholdsvis simple regler for signallering. Men husk lige at slette den ikke fungerende automatisk genererede logik for de master du laver Logix for. Begge dele på samme tid gør intet godt.

Efter at have lavet alt denne opsætning af signaler og prøvet dem af med simuleret Loconet, traf det sig, at jeg også blev færdig med at bygge min nye bane op i virkeligheden.

Først da gik det op for mig, at to af mine blokke hver indeholdt sporskifter i både den yderste og den inderste “cirkel” på banen. Og det ville reelt betyde, at to tog ikke ville kunne passere hinanden. Så hver af disse blokke måtte deles i to.

Det tog ikke lang tid at lave det fysiske med at par ledninger mere til input modulerne. Men det var mere eller mindre forfra med signal logikken. Så den del tog cirka 6 timer bare for denne lille bane.

Jeg tror egentlig ikke at JMRI er meget værre end andre futtogsstyreprogrammer. Men det er lidt tungt at definere et layout i alle de detaljer, der er. Til gengæld har JMRI den helt gevaldige fordel, at alt er meget dynamisk. Man kan bare bygge på, hvis man har en god ide. F.eks. placere en knap et eller andet sted og få den til at gøre hvad man vil.

Og efter at være blevet mere dus med JMRI er der en del ændringer, som jeg laver direkte i XML filerne. Det er meget nemmere og hurtigere end at klikke sig rundt i en grafisk brugergrænseflade. Men det kan naturligvis kun anbefales, hvis man ved hvad man gør, og hvis man er omhyggelig med sikkerhedskopiering af filerne, før man ændrer noget.

Men jeg ser muligheden for at manipulere XML filerne direkte som en fordel ved JMRI, som jeg ikke tror, man får i de kommercielle programmer.

Efter at være begyndt forsøgene med automatisering som beskrevet i et senere afsnit er det gået op for mig:
1. At den “double-crossover”, altså krydssporskifte, som jeg har defineret i Layout editor, og som jeg har i virkeligheden, ikke fungerer optimalt i JMRI: Der er ingen måde at vise automatikken, hvordan krydset skal passeres.
2. Der er et eller andet galt med definitionen af paths i mit layout.

Punkt 1 har jeg løst ved at fjerne krydssporskiftet fra layoutet og erstatte det med to almindelige sporskifter (defineret som “internal”, hvilket vil sige ikke-fysiske alias virtuelle) samt (i første omgang) et stykke logix til at sætte mit fysiske krydssporskifte (som stadigvæk er defineret i JMRI – bare ikke som en del af layoutet) ud fra kombinationen af hvordan de to virtuelle sporskifter er sat.

Logix er dog senere skiftet ud med et Jython script, som det har taget en del iterationer at få til at fungere optimalt.

I løbet af december 2015 er der bl.a. indført en ECOS command station, hvor JMRI er patchet (og pathcen gjort til en del af næste JMRI version, selvfølgelig), så sporskifter er MONITORED lige som for LocoNet, samtidig med at knownState er UNKNOWN mens sporskifterne skifter.

Udover at det hjalp på et problem i Dispatcher med at togene ikke ventede på at sporskifterne skiftede, så har det også kunnet bruges til endelig at få Jython scriptet til at styre krydssporskiftet ordentligt, samtidig med at også de to internal sporskifter opfører sig på samme måde med knownState lig med UNKNOWN mens krydssporskiftet skifter.

Punkt 2 (“et eller andet galt med paths”) fandt jeg ud af at løse ved at gå ind i Tables->Blocks og i menuen i det pågældende tabel-vindue fandt jeg ud af at man kan slette alle paths.

Det gjorde jeg, gemte derefter layoutet og genstartede JMRI, hvorved Layout Editor gendanner alle paths. Efter at have gjort det, kunne jeg slette alle de Logix, som jeg havde lavet til blok- og indkørselssignaler og i stedet lade Layout Editor danne signal mast logik.

“Junction” hovederne styres stadigvæk af Logix, men de er sådan set også kun til pynt. Så hermed røg den mest komplekse og veludtænkte Logix væk. Hmmm. Men jeg fik da lært at definere Logix…….

Dette fik dog ikke umiddelbart Dispatcher til at fungere særlig godt. Men mere om det senere.

Train Tracking:

Train tracking er JMRI’s evne til at holde rede på, hvilket tog, der befinder sig hvor. Det fungerer ved at knytte en variabel til hver blok, og skrive tog navnet på den blok, hvor det befinder sig. Når man derefter kører rundt med toget og blokke derved bliver optaget og frigivet, flytter JMRI togets navn med rundt.

Jeg har anvendt train tracking til at teste, at de data, der ligger i systemet, virkelig hænger sammen, altså at blokkene hænger sammen på samme måde i den fysiske verden, i det layout, der kan ses på skærmen samt i de data, der ligger inde i JMRI. Jeg fandt faktisk en fejl, som jeg endte med at måtte rette direkte i den XML fil, hvori Layout Editor gemmer alle data.

Automatisk togkørsel:

Næste tiltag var at læse om Warrants, Dispatcher og AutoDispatcher2, som er nogen af JMRIs muligheder for at automatisere togdriften. Alle tre metoder ser ud til at kunne lidt af det samme: Styre togene automatisk og/eller halvautomatisk og samtidig tage hensyn til signalerne, og dermed til hvis jeg selv kører et tog manuelt. Men lad os nu se, om det holder hvad det lover, samt hvad forskellen mellem de forskellige muligheder er. Og så holder jeg stadigvæk muligheden for noget Jython kode åben – enten som supplement til eller erstatning for de nævnte automatiseringsmuligheder.

Det med de mange muligheder er et resultat af, at der er mange bidragsydere til JMRI. Det er på den ene side lidt en skam, at man ikke har været i stand til at arbejde sammen om en enkelt løsning, der kunne have fungeret perfekt, men er endt med mange forskellige mere eller mindre halvfærdige løsninger. Men til gengæld har alle derved mulighed for at vælge det, man synes bedst om, og så i øvrigt præge det ved at hjælpe til med at finde og måske endda fikse eventuelle problemer.

Jeg besluttede mig for at begynde mine forsøg med Dispatcher, fordi:
– Dispatcher bygger oven på Layout Editor og Signal Mast logik.
– AutoDispatcher2 kræver, at man fjerner sin Signal Mast logik. Hvor er man så henne, hvis man vover at blande sig med lidt manuel kørsel?
– Warrants kræver, at man bygger hele sit layout op en gang til i form af OBlocks m.v. Det er delvist automatiseret i Panel Editor, men er helt forfra i forhold til min situation, hvor jeg har valgt Layout Editor. Man kan som tidligere nævnt sagtens gøre begge dele, men det ønsker jeg ikke i første omgang.
– AutoDispatcher2 er Jython kode. De andre to er Java kode, hvilket gør, at de kan køres inde i en debugger. Og eftersom jeg ikke tror på, at jeg undgår at debugge mig frem til et stabilt niveau af virkemåde, så er det ret essentielt.

Desværre viste det sig efter mange måneders arbejde med Dispatcher, hvor jeg forsøgte mig med mange tests og rettelser i Java koden, at Dispatcher er implementeret mindre heldigt. For software kyndige: Koden er multitrådet efter spaghetti princippet, men uden at være re-entrant. Eller sagt på almindelig dansk: Det kommer aldrig til at fungere pålideligt.

Som en konsekvens af ovennævnte problemer med Dispatcher skiftede jeg i julen 2015 hest og gik over til Warrants og dermed Panel Editor. Det virkede noget bedre. Men på min bane med korte blokke fungerede det heller ikke ordentligt. Java koden var dog langt mere gennemskuelig og velstruktureret. Så jeg lavede min egen variant af warrants, nemlig SCWarrants, som nu (naturligvis) er en del af JMRI. Man må bidrage til fællesskabet. Det er ideen med Open Source software.

Desuden har jeg lavet mig et Jython script, der opererer på en definition af mine tog, hvor jeg har defineret hvilke warrants, der bringer toget rundt på banen på rette vis. Det er dette script, der i sidste instans fuldautomatiseret togdriften. Se mere her.

Så nu virker det.

Opsummering:

Hvis du vil i gang med automatisk togdrift i JMRI, anbefaler jeg følgende rækkefølge:

Anskaf eller byg al den elektronik, jeg beskriver her.
Forbind din PC til dit layout.
Installer JMRI.
Test om du fra JMRI kan få et lokomotiv til at køre og et sporskifte til at skifte.
Check at tilbagemeldingsmodulernes status vises i JMRI.
Prøv også eventuelle andre basale ting af, som f.eks. dekoder programmering, hvis du har tænkt dig at bruge det.
I tilfælde af problemer med disse basale ting, så bed om hjælp enten i Yahoo gruppen eller hos mig. Det kan bringes til at fungere.
Definer dit layout i Layout Editor. (Kan undlades.)
Opsæt signal mast logik vha. Layout Editor. (Eller manuelt i signal mast tabellen, hvis Layout Editor ikke anvendes – det er faktisk lettere).
Definer dit layout i Panel Editor – inklusive OBlocks osv.
Lav nogle Warrants eller SCWarrants og lav et script, der afvikler disse warrants (eller tilpas mit script til dit layout).
Nyd at se dine modeltog futte afsted.

Bemærk, at Rom blev ikke bygget på én dag. Og du vil heller ikke kunne få noget som helst til at virke på en dag – hverken med JMRI eller med noget andet program.

Det tager noget tid. Men er det ikke en del af glæden ved modeltog?[:en]Her kommer historien om, hvordan jeg har sat JMRI op til at styre min bane. Forhåbentlig kan det tjene til at hjælpe flere i gang med at bruge JMRI.