OpenLCB/NMRAnet

Jeg vil i den kommende tid nok komme til at skrive en del om OpenLCB/NMRAnet, da det er noget, jeg er gået i gang med at lege rigtigt meget med. Der er tale om en ny standard indenfor styring af modelbaner, og jeg synes, den er ualmindeligt smart. Den er også meget fleksibel, så selvom den er beregnet til at kunne overtage hele styringen af en modelbane, er den samtidigt smart nok til at kunne arbejde sammen med de fleste bestående standarder, så man kan blive ved med at bruge de digitale stumper, man allerede har anskaffet - og så opgradere til NMRAnet hen ad vejen.

I dette første indlæg vil jeg fortælle lidt om historien bag, og meget overfladisk om, hvordan det hele fungerer. Det skal nok blive uddybet i detaljer senere hen, ligesom jeg vil komme med eksempler, når jeg begynder at bygge fungerende systemer. I øjeblikket går jeg og venter på et udviklersæt, jeg har været så heldig at få til spotpris: Det har været sendt fra Canada til Danmark en gang, men røg retur, så nu krydser vi fingre for, at det lykkes her anden gang.

OpenLCB

OpenLCB stammer oprindeligt fra en kreds af modelbanefolk i USA og Canada. Som navnet antyder er det hele skabt ud fra Open Source filosofien, så her er ingen patenter (næsten ikke) og ingen rettigheder at slås med - man kan blot gå i gang med at bruge det, der allerede er lavet, og så eventuelt selv bidrage med nye ideer. I modsætning til mange af de andre systemer på markedet, bærer dette tydeligt præg af at være lavet af erfarne IT-folk med stort kendskab til komplicerede netværkssystemer - men også med udpræget kendskab til modelbane - heldigvis!

Da OpenLCB er opstået på den anden side af Atlanten, har selve udviklingsarbejdet naturligt nok været centreret omkring DCC og de systemer, der bruges til to-skinne drift; men der er absolut ingen grund til, at man ikke skulle kunne overføre stort set hele funktionaliteten til tre-skinne systemer også.

Hvad kan det så? Tjah - næsten alt det, alle de andre systemer kan - på een gang! OpenLCB kan bruges til at køre tog med - dvs. erstatte DCC og Motorola protokollen; det kan også styre alt muligt, så den kan også erstatte DCC og Motorola som tilbehørsprotokoller; det kan lave tilbagemelding, så det kan erstatte protokoller som S88. Og så kan det meget, meget mere. Og alligevel er det også lettere at bruge. Det lyder næsten for godt til at være sandt - men i virkeligheden er der egentligt blot tale om, at moderne teknologi langt om længe har ramt modelbanen.

NMRAnet

Ikke alle ved lige, hvad NMRA er - men det står for National Model Railroad Association, USAs svar på DMJU. NMRA er imidlertid også kendt for deres store arbejde for at standardisere modelbanen, så tingene kan fungere på tværs af fabrikater: Når nørder f.eks. taler om RP25 hjul, kommer betegnelsen fra NMRA, hvor "RP" betyder "Recommended Practice" og 25 betyder RP dokument nummer 25. I denne sammenhæng er det dog mere interessant, at det er NMRA, der står bag standardiseringen af DCC protokollen. Og nu også NMRAnet: NMRA har fundet OpenLCB så godt, at det er blevet gjort til officiel NMRA standard under navnet NMRAnet. Så de to navne betyder det samme: Det vil vel nok være NMRAnet, der overlever i længden, så jeg vil bestræbe mig på at bruge dette navn - men OpenLCB er så indarbejdet blandt os, der har fulgt det i længere tid, at jeg nok kommer til at bruge dette ind imellem også. Husk blot, at der er tale om præcist det samme.

Det hurtige overblik

NMRAnet er tænkt, så det kan være overordentligt fleksibelt: Det kan køre på en masse forskellige typer hardware, men i første omgang koncentrerer man sig om dels CAN bussen og dels TCP/IP.

CAN bussen er nok ukendt for de fleste, men det er et simpelt og meget robust system opfundet af Bosch til brug i biler, og det er den, der i dag forbinder alt muligt mærkeligt i nye biler. Det er også CAN bussen, mekanikeren bruger, når han skal "aflæse" bilens computer. CAN bussen udmærker sig ved at være simpel og billig, men også meget robust overfør støj fra f.eks. en bilmotor - og derfor er den også meget velegnet til modelbanen, hvor der også er meget elektrisk støj. Jeg antydede noget med et patent ovenfor - det finder man her, da Bosch har patent på CAN bussen; men det er frit tilgængeligt for alle, for i praksis betaler man licens til Bosch, hvergang man køber en elektronikchip, der kan bruges til at kommunikere på CAN bussen. Bosch får nogle få øre pr. chip, og til gengæld kan alle bruge disse chips uden flere dikkedarer.

CAN bussen kan køre på mange forskellige kabeltyper, men i første omgang bruger man almindelige stik og kabler fra computernetværk. De er som bekendt billige og let tilgængelige.

TCP/IP er til gengæld det helt igennem normale computernetværk, der bruges overalt på Internettet. Det har forlængst vist sin styrke - men det ville være svært at lave et stort IP netværk til at styre en modelbane, hvis man ikke er netværksspecialist. Derfor er denne mulighed først og fremmest tænkt til at forbinde computere til modelbanens CAN bus, men den kan også bruges til at styre meget store modelbaner, hvor CAN bussens længemæssige begrænsninger begynder at gøre sig gældende. Som NMRAnet er opbygget, kan man lave færdige hardware gateways, der kan forbinde en CAN bus med TCP/IP. Sådan en gateway vil også kunne tillade en mobiltelefon at styre CAN bussen, selvom den ikke har hardware til det.

Her vil nogle nok indvende, at det jo allerede er muligt - men så har man ikke forstået ovenstående: Hvis man i dag vil styre sin modelbane med en mobiltelefon, skal man have en stor konsol som en ECoS, Intellibox eller Central Station - eller en PC, der har et program, der kan tage mod kommandoer fra mobiltelefonen og sende dem videre via DCC mm. Med NMRAnet behøver man ikke nogen central styreenhed - mobiltelefonen kan styre det hele uden en central konsol. Eneste forudsætning er, at man bygger hele sit NMRAnet på TCP/IP - eller kobler en gateway på, der kan forbinde TCP/IP med en CAN bus.

Events

Events er blevet et begreb indenfor nyere computerteknologi: Det engelske udtryk kan oversættes til "begivenhed", og det er det sådan set også - men indenfor computerteknik er det engelske udtryk også blevet et helt begreb, så jeg vil bruge dette som et "nydansk" ord. Man taler f.eks. om event-dreven programmering - det finder man i de fleste moderne operativsystemer som Windows, Linux og OSX: Når man rykker i musen, laver man en stribe events, og når man trykker på en knap på musen eller tastaturet, laver man også en event. Det er så op til operativsystemet og programmerne at bestemme, hvordan man vil reagere på disse events.

NMRAnet er en event styret protokol. Man taler i denne forbindelse om producers og consumers - de første producerer events, de sidste bruger dem. Som regel vil man finde begge typer i et stykke hardware.

Et meget simpelt eksempel kan være en trykknap og en lysdiode: De kan sidde på samme printkort, men de kan også befinde sig en halv kilometer fra hinanden - det betyder ikke så meget: Når man trykker knappen ned, genererer den en event, og når man slipper knappen, genererer den en ny. Mere præcist får man besked både når en event starter og når den slutter. Har man lige købt sin hardware, sker der ingenting, når man trykker på knappen; men man kan træne sin consumer - det vil her sige lysdioden - til at reagere på knappens events. Man kan f.eks. lære lysdioden, at den skal tænde, når man trykker knappen ned, og slukke, når man slipper knappen. Men man kan også lære den, at den skal tænde, når man trykker på knappen første gang, og slukke, når man trykker på knappen næste gang. I det sidste tilfælde bruges de events, der betyder "knap op", slet ikke.

Et lidt mere kompliceret eksempel kan være en styrepult med en trykknap og en lysdiode - lidt ligesom før, men denne gang er de bygget sammen. I den anden ende har man en servostyring til et sporskifte: Et tryk på knappen laver en event som fortæller sporskiftet, at det skal skifte til afvigende stilling. Det går det så i gang med, og når det er færdigt med at flytte sig, laver servostyringen en event, der fortæller, at sporskiftet nu står i afvigende stilling. Denne event kan så bruges til at tænde lysdioden henne ved knappen. Servostyringen kan imidlertid genkende mange flere events, så man behøver ikke nøjes med een trykknap: Man kan have mange forskellige, der alle sammen beder servostyringen skifte til afvigende stilling - det kunne være en måde at stille togveje. Men det kunne også være, at nogle events kom fra en styrepult, mens andre events kom fra en PC styring: Servostyrigen er ligeglad, den lytter blot efter events på bussen og reagerer, som den er blevet oplært til.

Netværksadresser

Erfarne netværksfolk vil nu begynde at få nervøse trækninger - for på et større anlæg kunne dette godt tyde på en meget kompliceret opsætning; men det er der heldigvis taget højde for. Adresserne på NMRAnet er sat i hardware ligesom MAC adressen på et Ethernet kort, så man skal slet ikke tænke på adresser, når man skal have sit anlæg til at fungere. Tildelingen fungerer på den måde, at NMRA tildeler de forskellige producenter en kode, der skal bruges som start på adressen, og producenten kan så selv bestemme underadresserne. Det har fungeret fint på Ethernet i årtier, og vil givet også gøre det her. Eksisterende DCC producenter har allerede en kode, de kan genbruge, men der er også sat plads af til, at f.eks. en klub kan få en ID kode, og så kan klubben selv underinddele de mulige adresser - her foreslår NMRA, at man bruger medlemsnumrene på medlemmerne, så de alle kan få mulighed for at lave deres egen NMRAnet hardware.

Almindelige brugere skal dog overhovedet ikke tænke på den slags: Svinger man ikke selv loddekolben, har andre klaret problemerne for en. Til gengæld vil almindelige brugere kunne værdsætte, at alle ens NMRAnet apparater automatisk har en helt unik adresse, så man kan koble sit udstyr sammen med vennernes - uden at risikere nogen form for adressekonflikt. Adresserne skal man slet ikke spekulere på - det virker bare. Også selvom man tager sine moduler med til et FREMO træf - alt NMRAnet udstyr har unikke adresser, så man kan blot begynde at oplære de elementer, der skal kommunikere med hinanden. Når man kommer hjem fra træf, behøver man ikke "slette" eller "rydde op" - den oplæring, man lavede under træffet, gør ingen skade.

Gateways

For at få alt dette til at virke i et bestående anlæg, kan man lave en eller flere gateways. De kan laves som et stykke hardware, f.eks. som en boks, man køber hos sin forhandler, men det kan også være et program, der kører på en computer.

En gateway kunne f.eks. oversætte mellem NMRAnet og DCC. Bruger vi det tidligere tilfælde med en trykknap og en servostyring til et sporskifte, kunne man forestille sig, at man lavede en ny styrepult med NMRAnet elementer: Det ville i sig selv være særdeles praktisk, da man blot ville behøve et standard netværkskabel mellem styrepulten og resten af anlægget - uanset hvor mange knapper, lysdioder og andre sjove ting, man måtte bygge ind i styrepulten.

Men har man allerede et anlæg, kunne man forestille sig, at der sidder en servostyring, der kun forstår DCC. Her kan man så sætte en gateway på, der kan lære, at når man laver en event ved at trykke på en knap på styrepulten, skal gateway'en sende en DCC kommando, der får sporskiftet til at skifte. Det kan heldigvis laves nemt og billigt, så på den måde kan man indføre NMRAnet på sit anlæg lige så langsomt - uden at skulle udskifte alt det bestående.

Universalprotokollen

NMRAnet er lavet, så det kan - men ikke behøver - erstatte alle andre protokoller: Man kan få kørekontroller, der via NMRAnet kan styre lokomotiver - i første omgang via en DCC gateway, men det vil også være muligt at lave lokomotivdekodere, der bruger NMRAnet direkte i stedet for DCC, Motorola og MFX. NMRAnet kan erstatte LocoNet, Railcom, S88 og alle de mange andre systemer, man bruger i dag. Man kan på den måde nøjes med en enkelt protokol, der er langt mere fleksibel, og slippe for alt bøvlet med at få de mange andre protokoller til at spille rigtigt sammen. Man sparer også en frygteligt masse ledninger.

Hvis NMRAnet kommer godt fra start, går vi en rigtigt spændende fremtid i møde.

Jeg vil her på min blog fortælle løbende om mine erfaringer med denne spændende protokol og ikke mindst det spændende udviklersæt, der forhåbentligt snart kommer frem fra Canada. Indtil da er her nogle links, hvor man kan læse mere:

OpenLCB hjemmesiden
NMRAs hjemmeside
NMRAnets hjemmeside

Og så et par producenter:

Railstars - se produkterne Io og Io:duino
TCH Technology - se OpenLCB Nodes

Jeg kan fortælle, at Don Goodman-Wilson - manden bag Railstars - havde bemærket en masse besøg fra Sporskiftet efter mine tidligere links, så han har studeret os og sendte mig en mail, da han havde dekodet mit danske indlæg om PC stik - og tilbød sin assistance.