Tanker oktober 2014

Min bane skal styres af PC’en. Det giver helt overordnet følgende muligheder:
– Skriv selv noget software
– Køb noget kommercielt software
– Brug gratis software

Skriver jeg alt selv fra grunden har jeg selvfølgelig fuld kontrol over, hvordan det fungerer. Men til gengæld tager det en del år, før jeg har tilstrækkeligt kendskab til alle detaljer af diverse protokoller såsom Uhlenbrocks interface, DCC og LocoNet, samt har implementeret disse såvel som applikationskode til visualisering af banen og til at styre signaler, sporskifter og tog.

Ved at købe noget kommercielt software kunne man forvente at komme rigtig hurtigt i gang. Og man kunne forvente et let tilgængeligt og velfungerende program. Til gengæld er der ingen chance for selv at skrive videre på programmet eller for bare at tweake en lille smule i et eller andet hjørne. Selv den mindste fejl kan man ikke gøre andet ved end at rapportere den til leverandøren og håbe, at de vil gøre noget ved det. Og så vil man også blive mindst 1000 kroner fattigere – sandsynligvis flere tusinde. Jeg har lige hørt om noget, der hedder RR&Co. Den koster mellem 100 og 500 Euro afhængig af version. Og Windigipet synes at være en anden meget seriøs kandidat.

Gratis software (OSS) synes at være vejen frem. Det er som om der er to fremherskende: JMRI, som jeg allerede har lidt erfaring med, og RocRail, som jeg også har installeret og har haft “hul igennem” med.

JMRI er tilsyneladende et stort bibliotek af basal software med interfaces til diverse kommandostationer, en masse dekoderdefinitioner, noget dekoderprogrammering samt et scriptsprog og i øvrigt en del ufærdige applikationer til layout visning, automatisk dispatching m.v.

Der er også noget så interessant som en kunstig lokomotivlyd-generator, dvs. en mulighed for lyd til lokomotiver, der ikke er udstyret med lyddekoder.

JMRI har også en gratis throttle app til Android. Til iPad er der også en gratis light udgave, mens den fulde version koster 65 kroner. Jeg kan ikke umiddelbart se, hvad forskellen på de to versioner er, men det støder jeg nok på, når jeg begynder at bruge light udgaven.

Den helt store downside ved JMRI er, at IB-COM interfacet tilsyneladende ikke fungerer. Jeg har måttet patche for at få tilbagemelding til at være pålidelig samt for overhovedet at få sporskiftestyring til at fungere.

Og DCC dekoder programmering virker slet ikke. Den er tilsyneladende slet ikke implementeret for IB-COM. Og der er træls, eftersom det skulle være en af JMRI’s store forcer. Hvordan det forholder sig med LocoNet programmer er uvis. Men der burde være en LocoIO programmer. Resten må så klares med Uhlenbrocks noget basale software.

JMRI er skrevet i Java. Det er i princippet et godt valg, som sikrer, at det kan afvikles på mange forskellige operativsystemer (Wndows, Linux m.v.). Det gør dog ikke noget hurtigere – især ikke opstart af programmerne. Og det betyder, at der er mange lag af bibliotekskode, før man når ned til hardware som f.eks. PC lyd, USB porte, harddisk osv.

RocRail ligner mere et forsøg på at lave en færdig applikation til styring af tog. Men den kritiseres for ikke at understøtte ret mange dekodertyper. Jeg går ud fra, at det kun gælder i forbindelse med programmering. Den skulle dog have en bedre mulighed for at programmere LocoIO end JMRI.

Også til RocRail er der apps til Android og IOS. Den til iPad koster 69 kroner. Der findes så vidt vides ingen gratis udgave. Den til Android er gratis, men kører kun i 5 minutter, med mindre man donerer et beløb og får en nøgle.

Desuden har der vist nok en gang været mulighed for en WEB-udgave, og der er en Java udgave, som jeg ikke helt forstår hvad er, men som er begrænset på samme måde som Android.

RocRail er skrevet i C/C++. Det gør tingene lidt simplere med mulighed for mere direkte adgang til operativsystemet. Det er dog gjort, så RocRail kan compiles til flere forskellige operativsystemer, så muligvis er der ikke den helt store forskel.

RocRail består af to dele: En server (RocRail) og en client (RocView). De to dele behøver ikke at køre på samme PC. Og man kan have flere instanser kørende samtidig – velsagtens dog kun client delen.

Hidtil har jeg forsøgt mig med JMRI. Men det har ikke været sådan lige at få til at fungere. Jeg tror næsten, at næste forsøg må være med RocRail.

Så går jeg ganske vist glip af den virtuelle lyddekoder. Men hvis resten virker bare en anelse mere stabil, så må jeg jo købe en lyddekoder og lade den skifte adresse og lydindhold alt efter hvilket lokomotiv, den skal bruges med. Måske findes der endda noget selvbyg? Det gør jo ikke noget, at det fylder lidt, hvis det bare skal skrues fast et eller andet sted i stedet for at være i lokomotivet.

Tilføjelse december 2014:

De indledende forsøg med Rocrail er mere positive end dem for JMRI. Rocrail er noget nemmere at komme i gang med. Det fremtræder i meget højere grad som et lækkert program for den almindelige bruger.

Desuden er der en meget aktiv bidragyder, som det ser ud til kører ret selvstændigt med klatten og bestemmer på godt og ondt hvilke forbedringer han implementerer. Der er op til flere ændringer hver dag, dvs. i dagens nye build.

Og umiddelbart fungerer programmet også ret så pålideligt.

Mine forsøg med automode er dog indtil videre ikke 100% succesfulde.

Der skal ret meget fidleri til for at få lokomotiverne til at standse samme sted ved perronen og for at få synkroniseret en lyd (f.eks. en stationmelding) med en togafgang.

Men værre endnu, så fungerer den random-auto funktion, som er indbygget i programmet, ikke særlig stabilt. Jeg vover kun at køre med mit BR216 lokomotiv indtil jeg ser en hel del mere stabilitet. Jeg oplever følgende problemer:

1. Nogle gange kører lokomotivet ikke, selvom man kan se på throttlen, at Rocrail tror, at den har sendt en kommando til lokomotivet om at køre i marchfart. Der er to måder at få lokomotivet til at køre på: Enten kan jeg trykke på en funktionstast for lokomotivet, feks. at tænde eller slukke lyset, eller man kan bare vente et par minutter. Så mister rocrail nemlig tilsyneladende tålmodigheden og gensender kommandoen til lokomotivet.

2. En gang imellem går programmet besærk og glemmer at standse lokomotivet. Og så er den helt ude i tovene og meget svær at få ordentlig i gang igen. Det hjælper ikke at genstarte Rocrail. Man skal ind og vælge “Soft Reset” og “Reset All” i en eller anden kombination, som jeg ikke helt har gennemskuet. Og derefter har Rocrail glemt alt om hvilket lokomotiv, der er i hvilken blok.

3. Hvis det ikke lykkes at resette ordentligt (eller også skyldes det noget andet), så vil toget ikke standse i en bestemt blok. Og når så lokomotivet kører ud over blokkens ende går det helt besærk.

4. Dekoder programmering virker. Men man får ikke at vide, hvis der opstår læse- eller skrivefejl. Og det er farligt. Så kan man jo ikke stole på oplysningerne eller på programmeringen.

Desuden er Rocrail ude af stand til at tracke, hvor man kører et lokomotiv hen på manuel vis. Det skyldes dog muligvis, at jeg bare ikke har fattet pointen i, hvordan man reserverer en rute og derefter kører lokomotivet via denne. I hvert fald lader det til at være en “works as defined”.

Man skal naturligvis ikke helt afvise købesoftware. Måske er det mere stabilt? Måske nemmere at bruge? Måske ikke særlig dyrt. Følgende programmer kendes p.t.:
– Win-Digipet
– iTrain
– Train Controller http://www.gotthardmodell.ch/digitales/software/traincontroller/
– Railware

Jeg ved ikke helt, hvornår jeg tester prøveversioner af disse købesoftware pakker. Men indtil videre har jeg ikke opgivet Rocrail.

Jeg kunne sikkert sagtens få hjælp til det via Rocrail forum. Men så skal jeg nok først bekende kulør og melde mig som bruger på nævnte forum samt indbetale et støttebeløb, som måske reelt er et service gebyr pr. år på €10. Se http://wiki.rocrail.net/doku.php?id=donate-en&DokuWiki=4ad465ee2e5ec1e3b662d9a9c6abf18f

Det er dog ikke meget i forhold til prisen for en af ovennævnte købeprogrammer. De koster nemt €300. Og opdateringer koster også. Så det giver jo Rocrail inklusive support i uendelighed, før man når op på samme pris. Men overvejelsen kunne dog alligevel være, hvorvidt købeprogrammerne er mere stabile?

Det næste må være at “skrue” noget mere på Rocrails forskellige konfigurationsmuligheder. Jeg har allerede downloadet kildeteksten og installeret et udviklingsmiljø (hvilket slet ikke passer med den forældede opskrift på Rocrail hjemmesiden). Så jeg kan godt klare ærterne selv. Men det er stadigvæk ikke lige det, jeg synes er sjovt. Jeg vil hellere køre futtog.

I øvrigt: Jeg har kun en sensor pr. blok, nemlig en occupancy detektor i form af en strømføler, som føler i hele blokkens udstrækning. Det burde kunne fungere, selvom anbefalingen er at have minimum to sensorer pr. blok. Win-Digipet kræver tilsyneladende tre.

Efter lidt mere tænken, lidt Youtube søgning efter JMRI automation og JMRI scripting samt et besøg her http://www.kayhernan.com/jmri-scripts/sensor-shuttle/ er jeg måske fremme ved følgende del-erkendelser:

1. Købeprogrammerne er for den bruger, der bare vil lege med tog. Jeg går ud fra, at de fungerer stabilt og holder hvad de lover. Dvs. (generelt set), at man definerer sit layout og sit rullende materiel, og så kan programmet enten trille rundt med materiellet automatisk eller man kan vælge at køre manuelt.

Automatikken findes i flere smagsvarianter: Enten køres der rundt på banen på må og få, eller man definerer ruter, som de enkelte lokomotiver så følger. Sidstnævnte kan lægges ind i deciderede køreplaner, eller togene kan bare konkurrere om frie blokke. De kolliderer ikke, for programmet lader ikke et tog køre ind i en blok, der allerede er reserveret til et andet tog.

2. Rocrail forsøger at gøre det samme som købeprogrammerne. Min erfaring siger mig bare, at det ikke er helt stabilt og/eller vanskeligt at konfigurere, så det fungerer helt stabilt.

Derudover stoler jeg ikke 100% på, at det virkeligt fungerer som et open source projekt. Det er for meget domineret af en person, der ganske vist yder en beundringsværdig og gratis indsats, men som til gengæld bestemmer for meget – både med hensyn til, hvordan programmet skal fungere, hvilke fejl, der er fejl, og hvilke, der skal ignoreres. Endelig er der et eksempel på forummet, hvor iPad throttlen bliver udsat for et skænderi og en bruger, som vil et eller andet. Enden på det skænderi er, at kildeteksten lige pludselig ikke er tilgængelig længere. Så den del er jo i hvert fald dermed ikke open source mere. Hvornår sker det samme med selve Rocrail?

Et andet forhold er, at samme person har bestemt sig for, at der ikke længere findes stabile versioner / releases, altså versioner, der er testet og fundet i orden. I stedet er der dagens version med dagens ændringer. Det er vældig fint, så længe der kun rettes fejl og indføres ny funktionalitet.

Men enhver med bare et perifært kendskab til software udvikling ved, at når man indfører sådanne positive ændringer i sin kode, så er der også en vis risiko for, at man indfører fejl i koden. Og det sker også i Rocrail.

Jeg påstår ikke, at Rocrail er fuld af fejl, men jeg kan se i forummet, at den ustabilitet, jeg oplever, også opleves af andre. Og i de indlæg er der typisk et mønster med, at dette eller hint plejede at fungere, men da man opdaterede til en eller anden nyere version fungerede det pludselig ikke længere.

3. JMRI er et helt andet dyr. Det er i bund og grund ikke tænkt som andet end et bibliotek af kode, som man kan benytte til at bygge sin egen styring af sit eget layout ovenpå. Og det ser ud til, at Jython alias Java udgaven af Python er måden at gøre det på.

Jeg kender ikke Python. Men jeg ved så meget som at det er et objektorienteret script sprog. Altså hvad jeg betragter som et fuldgyldigt programmeringssprog. Det virker ret så tiltalende for en inkarneret programmør som mig. Men sikkert ret så skræmmende for mange.

Jeg tror, at JMRI er rigtig open source, dvs. styret af et community og ikke en enkelt person. Der defineres stabile releases. Til gengæld fungerer IB-COM interfacet ikke optimalt. Men jeg kan vel debugge mig igennem det, som jeg er begyndt på, og derved bidrage til communetiet.

4. Baseret på 1 – 3 er der et ulogisk og to logiske valg: Rocrail er ulogisk, fordi der ikke er mere end måske 2.500 kroner at spare i forhold til at købe et færdigt program.

Dette under den forudsætning, at færdigprogrammet er stabilt. Men det er det vel? Jeg forventer, at hver releaset version har gennemgået en intens test. Det er bare lidt ærgerligt, for Rocrail med sin pris på €10 om året er næsten det rigtige produkt.

Hvorvidt et købeprogram eller JMRI er det rigtige valg? Det må bero på, hvad man gerne vil. Bare sætte stikket i og se togene køre, eller selv programmere sine køreplaner i Python?

Lige nu er jeg i tvivl. For et lille års tid siden ville jeg have svaret JMRI og Python.

JMRI vejen kunne bestå af:
1. At forstå Logix rigtigt og få det til at styre signaler.
2. Et Jython program til at måle hastighed gennem en bestemt blok.
3. Et Jython program (med mindre Logix allerde kan det), der holder øje med alle togs placering – uanset om de bare kører manuelt uden at reservere ruter m.v. eller om de kører på baggrund af en eller anden form for automatik. Programmet skal gribe ind, hvis et lokomotiv er på vej ind på forbudt område (reserveret eller optaget). Måske ved at detektere, når der røres ved et sporskifte på vej ind i en forbudt blok. Så skal programmet standse forbryderen og bakke den tilbage til foregående blok.
4. Et Jython program, der kan afvikle en køreplan.
5. DCC programmering via IB-COM. Det kan også gøres vha. SPROG II. Men Rocrail kan. Ved at lure i koden (eller måske kan en simpel trace gøre det???) må det kunne implementeres i JMRI også. Og måske er der information at hente i de eksempelprogrammer m.v., der ligger på den CD, der var med til IB-COM.
Jython eksempler på hjemmesiden og her https://groups.yahoo.com/neo/groups/jmriusers/files/Script%20examples/

Opdatering 22/12-2014:

Jeg har netop postet en patch til JMRI. Nu kan jeg bruge JMRI til dekoder programmering. Og det fungerer bedre end Rocrail, idet JMRI’s fejlhåndtering er noget bedre. Med Rocrail kunne man ikke stole på om en værdi er læst rigtigt. Det kan man tilsyneladende med JMRI.

Og nu hvor jeg har set JMRI dybt i kortene vedrørende interfacet til Uhlenbrock IB-COM, er jeg rimelig tryg ved at jeg nok skal kunne løse diverse andre problemer, som jeg måtte finde i det interface. Og de mere generelle dele af JMRI fungerer sandsynligvis en del bedre. Der er masser af brugere, som sandsynligvis bruger alle mulige andre typer af kommando stationer, men som alle bruger de generelle dele af JMRI.

Jeg har oplevet rigtig god respons på Yahoo brugergruppen. Der er masser af indlæg hver eneste dag, og da jeg havde et problem med at oversætte den downloadede Java kode, var der hjælp fra flere sider indenfor få timer.

Desuden har det vist sig, at man sagtens kan få sine tog til at køre uden at programmere selv – lige bortset fra de fejl og mangler, som jeg har udbedret på alle IB-COM og (se senere) ECOS brugeres vegne.

Så fra nu af er det JMRI. Og hvis det på et tidspunkt bliver andet, så bliver det købe-software. RocRail gider jeg ikke spilde mere tid på.

April 2020

“Märklin of Sweden” har lige lagt en video på Youtube, hvor han reklamerer voldsomt for Rocrail. Han har sikkert ret. Det har han vist som regel. Rocrail er sikkert meget kapabel og nemt at gå til. Det ser i hvert fald ud til, at dokumentationen er blevet rigtig god.

Så jeg gik ind på Github og ville lave en klon. Bare sådan hvis nu de skulle finde på, at det ikke længere skal være open source. Men så læste jeg licensbetingelserne: “Kloning verboten”. Hvor open source er det så?

Og så så jeg på antallet af bidragydere. Reelt kun en person. Hvor open source er det så?

Jeg tror jeg bliver ved med at bruge JMRI. Det har ikke et smukt brugerinterface. Men det er stabilt. Jeg kender det. Og der står en bred kreds bag, som jeg er blevet inviteret til at være en del af.