Interessant innlegg!

Du spør i starten om "hvorfor leker vi i det hele tatt." Hvis man er interessert i å fordype seg i dette kan jeg anbefale klassikeren på området, nederlenderen Johan Huizingas Homo Ludens fra 1938, som fortsatt gis ut i nye oversettelser og utgaver. En dansk oversettelse (Huizinga, J. (1963). Homo ludens: om kulturens oprindelse i leg.  København: Gyldendal) hvis man ikke vil/kan lese den i engelske eller tyske oversettelser, og kan sikkert fås tak i på et bedre bibliotek.

Kan rapportere om fremgang på to områder :  programvare og maskinvare.

På maskinvaresiden, har jeg valgt å benytte en Arduino Uno for kontroll av programmeringssporet.  Den skal :

1.       Styre rele for kopling mellom kjørestrøm og programmeringsstrøm.

2.       Sporbelegg deteksjon, 4 blokker , med detektering på begge skinnestrenger.

3.       To , eller flere optiske detektorer.

4.       Ultralyd avstands / hastighetsmåling.

Jeg gjør også noen forsøk med lydmåling, for å se om jeg kan måle støyforskjeller  med forskjellige dekoderinstillinger.

En Arduino Uno, har 13 Digitale inn/ut porter og 6 analoge innganger.  To av de digitale portene går til seiekommunikasjon, slik at det kun er 11 ledige.  Jeg trenger flere.  Jeg har derfor valgt å teste ut en I2C basert I/O Expander.  Microchip MCP 230008 (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en021393 )har jeg liggende, og de kan skaffes fra flere leverandører.  Priser fra ca. USD 1 – NOK 30.  Jeg har aldri brukt disse så en prøveoppstilling ble laget.

Adafruit har et Arduino bibliotek for MCP230008 og et eksempelprogram (https://github.com/adafruit/Adafruit-MCP23008-library ) .  Det fungerte på første forsøk.  Nå er det bare litt lodding som står igjen for å få blokkdetektoren til å fungere.

Programvare tar ofte litt lengre tid enn planlagt.  Status nå er at jeg benytter JMRI på Raspberry Pi for å lese lokomotivkonfigurasjonen, samtidig som min egen programvare  logger ved siden av.  De første testene på en web applikasjon er oppe å kjører  på

Men her er det fortsatt mye å gjøre, både på feilhåndtering, layout og funksjonalitet.  Første skritt er å lese CV’er for å identifisere hvilket lok som er satt på programmeringssporet.  Neste skritt er å kunne endre adresser fra Nettbrettet.  Deretter skal det lages programvare for å kjøre automatiske målinger av start, stop, og hastighet, og så kommer det første store målet, som er å automatisere innstillingene av Cvene for motorkontroll – basert på de automatiske kjøretestene.

Jeg har eksperimentert videre med Ultralyd avstandsmåleren.  På gulvet detekterer den et H0 lokomotiv med opp til 3,2 meters avstand.  Installert på programmeringssporet detekterer den opp til 22 centimeter.  Det er egentlig ikke noe stort problem fordi det er de siste centimeterene før stopp, og rett etter start som er viktig, men jeg har en mistanke om at det er hodet på en bolt som reflekterer signalet.  Skal forsøke å se om jeg kan bli kvitt denne.

Kortet for styringen av programmeringssporet er funksjonellt ferdig.  Først ble det en testoppkopling for å teste relestyring, som brukes for å veksle mellom kjørestrøm fra Roco sentralen, og programmering via MERG kontrolleren.

De  siste komponentene er  loddet på  kortet.  Nå gjenstår det bare å legge til sokkel  for Arduino prosessoren og tilkopling av ledninger, men dette vil jeg vente med inntill kortet med programvare er ferdig.  Jeg har derfor fullført testingen av kortet :

Etter dette har jeg montert alt sammen midlertidig ved siden av programmeringssporet, og koplet opp en USB kabel mellom Arduinoen  og Raspberry Pi.  Med denne oppkoplingen kan jeg teste ut kortet sammen med omkringliggende komponenter, og ha et godt miljø for utvikling av programkoden på kortet:  Jeg utviker på Raspberry PI, via en VNC klient, og laster ned v.h.a. USB kabelen, slik at det bare tar noen sekunder å teste nye versjoner av programkoden.

Arduino programkoden har allerede gjennomgått flere revisjoner.  Den første versjonen var for å teste relestyringen, ved at den slo av og på releet hvert 5 sekund.  Neste versjon sjekket alle de 8 spordetektorene ved å sende statusen til en terminalemulator en gang pr. Sekund.  Deretter ble det en versjon for å teste Ultralyd avstandsmålingen.  Nå er jeg igang med den endelige versjonen.  Den fungerer ved at det sendes en kommando til Arduinoen, som returnerer med et svar.  Kommandoer som er implementert i dag er:

• Q01VM
• Query 01 Version Major
• Returnerer versjonsnummeret for programvaren.  Svarer med:   M01P2
• Q01VS
• Query 01 Version Subversions
• Returner releasenummer for programvaren       : M0123
• Q01U1
• Query 01 Ultrasonic 1
• Skal returnere informasjon fra Avstandsmåleren
• Q01TA
• Query 01 Track All
• Returner svaret fra alle spordetektorer.  Det kan også spørres om hver enkelt med meldingen Q01Tn,  hvor N=0 – 7.

Utviklingen av programkoden på Raspberry har også gjort fremskritt.  Et av de første behovene er å finne ut hvilken Decoder type, som er installert i hvert enkelt lokomotiv.  De fleste decoderprodusenter benytter CV 7, software version number på en fornuftig måte.  Utfordringen min er at jeg har ganske mange dekodere fra ESU, som er ganske forskjellige, men hvor ESU har lagt inn samme verdi i CV 7.  Dette gjelder så forskjellige dekodere som,  LokPilot v. 2 3 og 4,  Loksound dekodere,  ROCO 10745 (fabrikkinstallert i mange ROCO startsett) i forskjellige versjon, og mange av dekoderne som selges som Bachmann 3-Function decoder  36-553.  Etter lesing av manualer, fra dekoderleverandørene og JMRI dokumentasjonen, samt egen testing har jeg laget denne tabellen (fortsatt ikke helt komplett)

Hele tabellen ligger her:

http://programmingtrack.no-ip.org/EsuRocoBachmannCVlist20140324.xls

Programkoden er kommet så langt at den klarer ved hjelp av å lese ut forskjellige CV’er, og om nødvendig forsøke å skrive til noen CV’er,  å finne ut om det er en basic decoder (ESU, Roco eller Backmann), og hvem av dem det er,  eller om det er en av de mere avanserte dekoderene.  Det gjenstår  fortsatt funksjonalitet for  å finne forskjeller mellom Lokpilot 2,3,3 og LokSound.  Tilsvarende funksjonalitet for Lenz og Zimo kommer senere.

Etter at jeg har funnet ut hvilken dekoder som er i loket, har jeg også laget funksjonalitet for å identifisere om loket har vært innom programmeringssporet før, og eventuelt programmerer CV’er fra en liste.  Måten jeg benytter er å sjekke dekodertype, hvis denne støtter lange adresser benyttes denne for å identifisere loket.  For NSB lok benytter jeg lokets 3 (med en null foran) eller 4 sifrede nummer,  for tyske lok benytter jeg typenummeret f,eks 218, og legger til kontrollsifferet, slik at jeg får 4 sifre.  Det gjenstår å se hvor mange kolisjoner jeg får.  For de dekoderene som støtter det, vil jeg benytte et løpenummer i CV 106 (User identification) .

Hensikten med alt dette, er å kunne ta vare på historikk på CV’er, for å kunne sammenlikne kjøreegenskapene for de ulike lokene, med ulike dekodere.  Når programmeringssporet, er ferdig med sensorer vil jeg få en automatisert dokumentasjon av dette.

Status i dag :

http://programmingtrack.no-ip.org/dynamic.php?system=ENGINEDB&page=10000&id=0

Til slutt har jeg også funnet dokumentasjon på hvordan styre vendeskiver med Arduino:

http://www.rmweb.co.uk/community/index.php?/topic/78578-dcc-controlled-peco-turntable-project/

Veldig hyggelig med tilbakemeldinger – er ofte vanskelig å selv vurdere om det man skriver er av interesse for andre.

Det enkle svaret er vel at jeg gjør det fordi det er gøy, men hvis jeg skal forsøke å forsvare det litt, kan jeg utdype :

JMRI er en glimrende CV editor for å lese og skrive CV verdier.  Jeg har koplet opp JMRI i parallell til egenutviklet programvare slik at jeg kan lese ut og skrive, og se hvilke kommandoer som blir generert over serieporten.

Mine viktigste argumenter for å lage en egen programmerer, er :

1.      I JMRI kan man lese ut og lagre CV’er på (XML) filer, slik at man manuelt kan se hvilke endringer man har gjort, eller legge tilbake gamle instillinger.  Jeg vil istedenfor filer, lagre innstillingene i en database (MySQL) slik at jeg kan ta ut rapporter, sammenlike, og gjøre mere komplekse operasjoner  som f.eks. resette dekoder til fabrikkinstillinger og deretter programmere inn gamle verdier for f.eks. CV1, lange adresser, ol, uten å gjøre dette som manuelle steg i JMRI)

2.      Jeg ønsker å autmatisk sette parametre for styringen,  både CV i lokket, men også parametre i styringsprogrammet for å oppnå jevneste og mest mulig forbildetro, hastighet, aksellerasjon og bremsing.  JMRI har en automatisk hastighetsmåler som måler tiden mellom to punkter, og derved beregner konstant hastighet for toget (eller egentlig gjennomsnitlig).  Jeg håper å få til en nøyaktig måling av retardasjon og akselerasjon v.h.a. Ultralyd avstandsmåling.  Denne målingen vil jeg gjøre fra enden av programmeringssporet, og når jeg/eller programmet er fornøyd med profilen, vil jeg lagre den, og benytte den under kjøringen senere.

3.      JMRI DecoderPro er en PC applikasjon, som ikke kan benyttes på nettbrett.  Jeg lager grensesnitt slik at det kan brukes på PC, iPad, iPhone, Android etc.  I tillegg tror jeg at jeg vil kople til en enkel fjernkontroll (type TV) med enkle funksjoner, som f.eks:

·        0 – Identifiser Lok på programmeringsspor.

·        1 – Les og lagre alle CV’er i lokket.

·        2 – Tildel og programmer en midlertidig unik adresse for loket, slik at det kan prøvekjøres.

·        3 -  Kjør testprogram for lokomotiv,  for å grovinstille CV’er

·        4 – Kjør avansert testprogram for fininstiing av CV’er

Andre ting jeg har sett at jeg kan lage bedre enn JMRI er dekodertype identifisering.  JMRI kan f.eks. ikke skille mellom ESU dekodere som f.eks. Lokpilot, Loksound, Basic, Roco 10745 i forskjellige varianter, og Bachmann 3-function.

Mine viktigste argumenter for å lage et eget styringssystem, er:

 (her er jeg litt på tynn is fordi jeg ikke har sett mye på alternative løsninger) :

1.      Da jeg begynte med dette for ca. 30 år siden fantes det ikke noe alternativ.  Den gangen så jeg litt på CMRI, men valgte å lage egne blokkkontrollere med DC styring under MS-DOS.  Dagens versjon av styringen er laget i løpet av de siste 15 årene, men støtter fremdeles scriptene som jeg laget for 30 år siden.

2.      Ambisjonsnivået er relativt høyt. F.eks. lag en tidtabell hvor lokaltoget starter fra utgangstasjonen hver time (mellom 06:00 og 23:00), og returner klar til innsats nesten to timer senere. (slik at det er behov for minimum to togsett).  Det betyr at jeg ikke kan lage script for hvert enkelt tog, men lage generelle script for å kjøre etter tidtabellen, og andre script som finner ut hviket materiell som skal brukes i denne avgangen.  Andre funksjoner, eller separate programmer er f.eks. togekspeditør på en stasjon (må løse komfikter i forhold til sporbruk ved forsinkelser/ekstratog), lokfører som kjører toget etter signalene/rutetabellen, og signalstyring / linjeblokk.  Alle programmene kommuniserer via TCP/IP, slik at de kan kjøres på en eller flere PC’er.  Jeg kan også velge hvilken funksjon jeg selv vil utføre manuelt.  (Neida jeg er ikke ”helt” ferdig med alt enda).

3.      Ønsker å automatisere skiftebevegelser og samenstilling av godstog (Her er jeg avhengig av bedre kontroll med lokegenskapene –  ref. Egen programmerer)  f.eks. er en av de viktigste kundene et aluminiumsverk (samme produksjonsnivå/produkter som Årdal Verk), som har behov for levering av riktig mengde Aluminium oksid og  Kull (for anodeproduksjon), og transportkapasitet for ferdige aluminiumsprodukter. (20000 – 200000 Tonn pr. År avhengig av årstall) og Anoder.  (10 femtitals vogner med last på 10 tonn hver, per dag – eller nyere vogner med 80 tons kapasitet på 2000 tallet)

4.      Ønske om norske signalbilder og stillverk.  Ved å selv lage programvaren, kan jeg få norske signalbilder uten avansert elektronikk, men overlate kompleksiteten til programvaren.

Dette er en enkel test som kjører det testede lokomotivet forover i 20 sekunder, ut av programmeringssporet på hastighetstep 4 med spedstepmode 14.  Stopper lokomotivet, og kjører tilbake inn i programmeringssporet og stopper når den innerste spordetektoren oppdager lokomotivet.  Ved å kjøre testen mange ganger og sjekke avstanden med Ultralydmåleren for jeg ut statistikk over hvor nøyaktig kontrollen er.  Det har etterhvert begynt å fungere, men stopposisjonen er ganske unøyaktig – sansynligvis bl.a. fordi jeg kun leser ut sensorene en gang per sekund.  Her er en liten tabell, over avstanden i centimeter, Ultralydsensoren har målt for de siste testene:

149        Test001StopPosition        13

150        Test001StopPosition        3

151        Test001StopPosition        5

152        Test001StopPosition        18

153        Test001StopPosition        19

154        Test001StopPosition        18

155        Test001StopPosition        3

156        Test001StopPosition        15

157        Test001StopPosition        6

158        Test001StopPosition        12

Ikke impoenerende presisjon her, men et greit utgangpunkt.  For hver kjøring får jeg også ut en rapport om hastigheter og responstider under testen.  Her er et eksempel fra den siste kjøringen :

Forklaringer til tabellen :

TimerSensor002001 – Tidsforbruk fra spordetektor 002 til  001.  Her er en svakhet ved at den kun beregner hele sekunder.

KMHSensor003001 – Hastighetsmåling fra spordetektor 003 til 001.  Unøyaktig fordi den benytter TimerSensor  (Uten desimaler)

Test001StopPosition – Ultralydmålerens avstandsmåling I hele cm.

-         Hastighetsberegninger pr sekund fra  20 cm  til stopp.  I Eksempelet over

o   164854 klokkeslett

o   6.0 – Centimeter, kjørt siste sekund.

o   19.0:13.0 – Hvor lokomotivet kjørte fra og til på dette sekundet.

-        Vi ser derfor at lokomotivet bråstoppet her. Og det stemmer lokomotivet ble kjørt i skiftemodus.

TestrunSec – Hele testen tok 52 sekunder.

TestRunMessages – 441 meldinger gjennom systemet i løpet av testen.

TestrunMessagesSec  -8,48 meldinger pr. Sekund

TestRunUltra – 59  avstandsmålinger i løpet av testen.

TestrunUltraSec – 1,18  avstandsmålinger pr. Sekund – Derfor er unøyaktigheten i alle målinger på nesten et sekund.  -  Så her er det bare å jobbe videre med å få opp frekvensen.

Oppstart etter sommerferie, begynte med korrupt SD brikke på en av Raspberry’ene.  Dette er den tredje SD brikken som er ødelagt i løpet av et år hos meg (fordelt på 5 Raspberry Pi).  Backup er ikke så dumt, alternativt, som jeg gjør er å ikke lagre viktig informasjon på SD brikken, og ha automatiserte rutiner for å reinstallere.  Jeg har derfor forbedret den automatiske installasjonsprosedyren for JMRI, og samtidig oppgradert til siste versjon av JMRI, 3.8.  Denne har jeg lagt inn i min automatiske installasjonsprosedyre.  Hvis noen vil prøve er kommandoene :

wget programmingtrack.no-ip.org/setup010308.sh
. ./setup010308.sh

Resten er som før – se blogg 6 Januar 2014

Programmmeringssporet

For å få mere nøyaktige malinger, startet jeg feilsøking I grensesnittet mot Roco sentralen.  Etterhvert fant jeg så mange programmeringsfeil (som jeg selv har laget for 8 år siden), at jeg konkluderte med at det var på tide å programmere dette på nytt.   Har nå ferdig en prototype som fungerer mye bedre, men foreløpig kun støtter 14 Step, lokomotivkontroll.  Rapporten fra den siste testen viser at maksimal responstid for TCP/IP meldinger nå er nede i omtrent 0,1 sekund.  Alle målinger blir derfor mye mere nøyaktig.   Det kan man bl.a se på hastighetsmålingene.  Here er rapporten for kjøring nr 388.  

Hvordan gjøre enkle ting vanskelig.

Første forsøket med z21 gikk ikke veldig bra.  Jeg pakket opp startsettet, koplet opp z21 boksen og ruteren som fulgte med.  For å oppgradere firmware til siste versjon lastet jeg også ned siste versjon av z21 Maintenance tool på PC’en.  For å oppgradere måtte jeg også kople den medfølgende ruteren til nettet mitt.  Koplet til strømmen på begge enhetene og forsøkte å få kontakt fra PC’en.  Og det fungerte selvfølgelig ikke.  Adressen til z21 skal være 192.168.0.111, men den svarte ikke engang på ping.  Dagen etter gjorde jeg et nytt forsøk.  Jeg hadde nå en mistanke om at noen hadde pakket opp settet før jeg kjøpte det, og endret adressene, både på router og z21 boksen fordi de kjørte med feil oppsett.  Istedenfor 192.168.0.x nett, var router satt opp med LAN range på 192.168.1.x nett.  Hadde ikke lyst til å forsøke å endre router oppsettet, men etter en stund gikk det et lite lys opp for meg :  192.168.0.x nettet var jo den samme adressa rangen jeg benytter på nettet mitt.  Tok derfor bort den medfølge routeren og koplet z21 boksen rett i den andre routeren,  og da fungerete alt.  Så anbefalt fremgangsmåte for å sette opp z21 boksen, bør derfor være :

1. Kople opp z21 og medfølgende router uten å kople routeren til hjemmenettverket.
2. kople opp PC mot router og forsøke å pinge 192.168.0.11.
3. hvis hjemmenettverk ikke kjører på 192.168.0.x adresser kan den medfølgende router koples til     hjemmenettet.   Hvis hjemmenettet kjører på 192.168.0.x, sjekk om det er noen devicer som har adressen 192.168.0.111,  hvis ikke er det bare å kople z21 rett inn i hjemmerouteren, men pass på at dhcp range ikke overlapper med 192.168.0.111

Mitt router oppsett er :

Router Ip address 192.168.0.1

Ip Subnet mask 255.255.255.0

DHCP 192.168.0.200 – 192.168.0.253

Status på z21 boksen min nå er at den er opp i nettverket – men ikke koplet til anlegget.  Har testet ut å kjøre lok med iPad (uten at noe fysisk lok kjører) og det fungerer.  JMRI har foreløpig ikkeordentlig støtte for z21, men det er på vei i de siste utviklingsversjonene.  Protokollen som benyttes mot z21 er basert på å pakke inn det gamle Lenz serieport grenssnittet inn i UDP pakker.  Jeg har laget et lite testprogram som kopler seg opp, og gjør enkle kommandoer som ”Track Power on/off” etc.

Utfordringen min nå er at jeg har tre potensielle DCC sentraler, og jeg må bestemme med for hvilke jeg vil benytte for kjøring og programmering :  Roco LokMaus II/Multimaus,  z21 eller MERG ?

Her er oppsettet mitt som det er i dag :