Programmering mod IntelliBoxen ?

Jeg har haft det til at virke en gang - jeg tror desværre ikke jeg har koden mere.

Prøv at smide din koder op her så kan vi jo kigge på den.

Hej frede2300

Jeg havde det engang til at fungere i VB6, men nu har jeg C# og det gamle VB6 kode at se efter - og nu kan jeg sgu' ikk' få det til at virke !

Her er koden til at åbne porten:

private void openPort(SerialPort p, string nm) {

p.PortName=nm;

p.BaudRate=19200;

p.Parity=Parity.None;

p.DataBits=8;

p.StopBits=StopBits.One;

if (!p.IsOpen) p.Open();

do { } while (!p.IsOpen) ;

p.DiscardOutBuffer();

}

og den virker fint. Herefter sendes et BREAK med denne kode:

private void sendBreak(SerialPort p, object sender, EventArgs e) {

if (!p.IsOpen) button_Open_Click(sender,e);

Application.DoEvents();

Thread.Sleep(200);

p.BreakState=true;

Application.DoEvents();

Thread.Sleep(1000);

p.BreakState=false;

Application.DoEvents();

Thread.Sleep(600);

}

Sleep-tiderne har jeg læst forskellige steder, at de skulle være meget vigtige - der er ikke rigtigt noget at se på portmonitoren, når BREAK sendes.

Så skal den prøve sig frem til den rigtige baudrate er fundet - og det forsøger jeg med denne kode:

private void tryUntilFoundOrMaxBaudFound(SerialPort p) {

int tryBaudRate = 2400;

bool found=false;

do {

setNyTestOp(p, tryBaudRate);

p.Write(new byte[] { (byte)Command.XNOP }, 0, 1);

Thread.Sleep(1000);

switch (p.BytesToRead) { <<

case 2:

found=true;

string dummy=p.ReadExisting();

break;

case 1:

break;

default:

tryBaudRate*=2;

break;

}

} while (!found && tryBaudRate<=38400);

}

private void setNyTestOp(SerialPort p, int bR) {

if (p.IsOpen) p.Close();

p.BaudRate=bR;

p.Parity=Parity.None;

p.DataBits=8;

p.StopBits=StopBits.One;

p.Open();

do { } while (!p.IsOpen);

p.DiscardOutBuffer();

}

efter første gennemløb med prøveværdien 2400 - ja, der returneres 2 bytes - to 0-ler - og når det er tilfældet, tror den den RIGTIGE baudrate er fundet - men det er den IKKE, da den er 19200.

Hvorfor returnerer den 00 efter første gennemløb, når det faktisk IKKE er den rigtige baudrate ?

Hvis jeg forstår dokumentationen her korrekt så skal du ikke sende XNOP, men værdien 0C4h hvor du så får svaret Ok hvis hastigheden er korrekt og intet svar hvis du kører med forkert bitrate.

http://www.google.dk/url?sa=t&source=web&cd=3&sqi=2&ved=0CDYQFjAC&url=http%3A%2F%2Fwiki.rocrail.net%2Flib%2Fexe%2Ffetch.php%3Fid%3Dintellibox-en%26cache%3Dcache%26media%3Dp50x%3Ap50x.txt&rct=j&q=rs232%20xnop&ei=qEhUTZ_ZIs-eOp3O8aEJ&usg=AFQjCNGw0dpn-1pSWVAlkQESSoRZYC-t8A&cad=rja

OK .. ja, jeg sender også "værdien" af kommendoen XNOP - og den ER 0C4h - og netop det at den GIVER et svar gør, at algoritmen går galt i byen.

Jeg kan huske at jeg fik det til at virke ved at lure på koden fra RocRail

For at gøre tingene lidt mere simple kunne du starte med at benytte en fast baud rate så du ikke skal håndtere denne del.

En ting der også drillede mig var at baud raten skal sættes flere steder: på IB'en, på driveren til usb/seriel, på den virtuelle com port og i c#.

> frede2300

Jeg har et par eksempler i diverse BASIC varianter på initialiseringsproceduren og de gør det stort set på samme måde, og det er denne BASIC koden jeg har oversat til C#, men det virker sgu' bare ikk' !

Du skriver "lure koden fra RocRail" - hvor har du den fra ?

Fair nok, jeg fik vist ikke læst den sidste linie du skrev ordentlig.

Er du logget ind med en bruger med administratorrettigheder?

Jeg tænker på om du rent faktisk kører 2400, som du forventer eller en anden hastighed fordi du ikke har rettighederne til at sætte porten som du har lyst til.

Prøv at starte HyperTerminal og snak med boksen ved forskellige hastigheder for at se hvordan den reagerer.

Koden til rocrail er på projektets forside, øverst til venstre. http://wiki.rocrail.net/doku.php

Jeg er logget på med administratorrettigheder.

Den IB'en er stillet til 19.200 og UANSET, hvad den stilles på, så returneres 2 bytes i det første gennemløb af loopet, hvor den skal prøve sig frem med at finde baudraten.

Jeg har også prøvet at stille porten til samme hastighed som IB'en og med paritet=none, databits=8 og stopbits=1 (de kan vist IKKE ændres i IB'en) - så har jeg forbindelse og kan sende STOP og GO med decimal værdierne hhv 97 og 96 (side 91 i tyske IB manual) - og IB'en slår fra og til som den skal, MEN ... bruger jeg XPwrOff=A6 eller XPwrOn=A7 fra P50 dokumentationen, så virker de IKKE !

Mht. RocRail kildekoden er det lidt ligesom den med "høstakken og nålen" - det er da fuldstændig uoverskueligt - jeg fandt stort set ikke andet end XML-koder og det har jeg aldrig fattet - så det dropper jeg at få forstand af.

Du kan browse sourcen til RocRail her

http://bazaar.launchpad.net/~rocrail-project/rocrail/Rocrail/files

ellers må du installere bazaar og hente det den vej.

Koden til p50 interfacet findes her:

http://bazaar.launchpad.net/~rocrail-project/rocrail/Rocrail/view/head:/...

Så fandt jeg min c# kode. Denne kode virker - jeg har netop kørt den og fået et lok til at tøffe hen ad køkkenbordet.

Først koden der forbinder til IB. Jeg har ikke implementeret noget som søger efter com porten - find den rette inden du kalder ConnectToIb:

[code] private bool ConnectToIB(string port, int speed) { string reply; int[] bauds = new[] {2400, 4800, 9600, 19200}; Console.WriteLine("Opening " + port + " at " + speed + " baud"); serialPort = new SerialPort(); serialPort.NewLine = Encoding.ASCII.GetString(new byte[] {13}); serialPort.DataBits = 8; serialPort.DiscardNull = false; serialPort.DtrEnable = false; serialPort.Handshake = Handshake.None; serialPort.Parity = Parity.None; serialPort.ParityReplace = 0; serialPort.ReadBufferSize = 100; serialPort.ReadTimeout = 500; serialPort.ReceivedBytesThreshold = 100; serialPort.RtsEnable = false; serialPort.StopBits = StopBits.Two; serialPort.WriteBufferSize = 200; serialPort.WriteTimeout = 500; serialPort.PortName = port; try { serialPort.Open(); } catch { return false; } //dump the buffer just in case some garbage has accumulated Console.WriteLine("Emptying buffer"); Thread.Sleep(200); string garbage = serialPort.ReadExisting(); //reset the IB by sending a long break Console.WriteLine("Sending break"); Thread.Sleep(200); SendBreak(serialPort, 1000); Thread.Sleep(600); serialPort.Close(); //now, we need to find the baud rate in use by trial and error. Console.WriteLine("Identifying baud rate"); int baseBaud = 0; bool found = false; while (!found) { serialPort.BaudRate = bauds[baseBaud]; serialPort.Open(); string sDummy = serialPort.ReadExisting(); try { serialPort.WriteLine("Xt1"); //get status of turnout 1 Thread.Sleep(200); reply = serialPort.ReadTo("]"); //if comms is bad we get a timeout here serialPort.Close(); found = true; break; } catch { //catch timeout } serialPort.Close(); //bump up the speed Console.WriteLine("... not " + bauds[baseBaud] + " baud"); baseBaud += 1; Thread.Sleep(200); if (baseBaud > 3) { break; } } if (!found) { Console.WriteLine("Connection to IB could not be established"); return false; } //assuming found from hereon Console.WriteLine("Baud rate should be " + bauds[baseBaud]); Console.WriteLine("Testing mode"); serialPort.BaudRate = bauds[baseBaud]; serialPort.Open(); //check if p50x is enabled bool p50xEnabled = false; try { serialPort.WriteLine("X"); Thread.Sleep(200); reply = serialPort.ReadTo("]"); p50xEnabled = true; } catch { } if (p50xEnabled) { //bump speed to desired serialPort.WriteLine("xB" + speed); } serialPort.Close(); //open with new baud rate serialPort.BaudRate = speed; serialPort.Open(); found = false; try { serialPort.WriteLine("X"); Thread.Sleep(200); reply = serialPort.ReadTo("]"); found = true; Console.WriteLine("Re-connected at desired speed " + speed); } catch { } if (!found) { Console.WriteLine("Could not connect at desired speed " + speed); serialPort.Close(); serialPort.BaudRate = bauds[baseBaud]; serialPort.Open(); Console.WriteLine("Re-connected at " + serialPort.BaudRate); found = true; } return found; }[/code]

Og så er der en stump kode til at sende noget ud på skinnerne

[code] /// digital address /// speed to set /// flags (e.g. functions) private void setLocState(int index, int speed, int flags) { serialPort.Write( new[] {(byte) 'X', XLOK, (byte) (index & 0xff), (byte) (index >> , (byte) speed, (byte) flags}, 0, 6); serialPort.WriteLine(""); }[/code]

hej frede2300

Det ser rigtig godt ud - det vil jeg prøve at tykke igennem.

Fandt du det på RocRail - jeg synes slet ikke jeg kunne hverken C elle C# nogen steder.

tak for det !

C# koden har jeg selv skrevet - med inspiration fra rocrail (se link til p50 koden lidt længere oppe i tråden)

vh

Hej frede2300

Der manglede en metode, men jeg går ud fra det er noget ala:

private void SendBreak(SerialPort p, int wt) {

p.BreakState=true;

Thread.Sleep(wt);

p.BreakState=false;

}

?

Lige nøjagtigt. Her har du den som jeg havde skrevet

[code] private void SendBreak(SerialPort port, int delay) { port.BreakState = true; Thread.Sleep(delay); port.BreakState = false; }[/code]

..og disse to skal du også ha med.

[code] private SerialPort serialPort; private bool connected { get; set; }[/code]

Desværre !

Din kode - med de smårettelser, som jeg har skrevet her - kommer frem til nøjagtigt det samme fejlagtige baudrate (2400 = den første, der testes med) som min egen kode gør - den kan IKKE læse baudraten fra IB'en ELLER min IB svarer forkert !

Nu vil jeg prøve at connecte med kendte værdier og se om jeg kan få et lok til at køre.

Godt så!

Prøv at sætte hastigheden ned til 9600

1: Tjek IB'en: 9600 n 8 1

2: Device manager -> find din comport -> samme hastighed

Kør igen

Præcis hvilken IB har du?

Kører du en eller anden usb/seriel adapter?

og : kan du få et eller andet andet program til at virke? Rocrail?

Hej igen frede2300

Jeg jeg har et prof. program - TrainControler - som virker.

IB'en er en Intellibox IR.

Og det er IKKE en "USB to Serial" - det er et godt gammeldags kort med 2 COM-porte.

Det andet du foreslår hjælper ikke på det at aflæse indstillingerne i IB - never mind that !

Men hvordan sender du besked til lok'et ?

- 3 textboxe, angive decimal værdien af Adresse og køretrin ?

- hvordan angives "flags" - bitsvis 0 eller 1 for hver funktion ?

tryk på en knap og så sende textboxenes indhold som parameterværdier til setLocState eller hva' ?

Jeg kan nu styre mine loks med hastighed, lys og diverse funktioner, også flere på en gang på skinnerne.

Jeg kører på 19.200 baud, men har nogle problemer med stopbits - min portmonitor melder fejl på den værdi Two (= 2), som jeg vil indsætte, men det ser ud til at virke alligevel - don't know how !

BABI, BREAK, @ og @@ kan jeg heller ikke få til at virke og har valgt at springe dem over indtil videre, og så arbejde med fast kendt opsætning af kommunikationen (dog stadig problemet med antal stopbits !) - det går også fint, MEN ...

jeg synes dokumentationen til IB'en er mildt sagt fuldstændig ubrugelig - de enkelte kommendoers funktion er ikke beskrevet - det store overblik mangler og i detaljen er der direkte fejl og komplet uforståelige og ofte selvmodsigende sætninger ... men det er åbenbart, hvad der findes - så det må vi jo leve med.

Jeg har det problem lige pt., at når IB'en har været slukket - altså uden strømforsyning - så kan jeg ikke få status på mine Lok's med kommandoen xLokSts - jeg skal ligesom "indtaste adressen" på IB'en først.

Jeg har en teori om, at der er et slags FIFO lager (som forsvinder ved strømsvigt), men oprettes ved indtastning af adresse på IB'en.

Der er 119 pladser i dette lager, og de loks, som jeg ønsker at styre fra pc'en skal være oprettet i dette lager. Oprettelsen kan så ske ved

"indtastning" på IB'en (Lok# > angiv adresse > tryk knækket pil

ELLER

via programkode ved brug af xLkDisp.

Men er det rigtigt opfattet med dette FIFO-lager og xLkDisp ?

(Håber nogen kan svare !)

Hej igen,

Dejligt du har fået hul igennem!

Med hensyn til at hente status på lokomotiverne mm så fungerer IB'en sådan at den gemmer den status som den sidst selv har sendt ud - der forekommer altså ikke nogen hentning af status fra f.eks. lokomotivet.

Hvis du tager strømmen, ja så ryger al status.

Jeg kan ikke lige svare på om genbrug af lageret fungerer efter fifo eller noget mere begavet, men jeg er sikker på at du ikke behøver at "gøre noget" før du kan styre lokomotiverne fra pc'en. Tværtigmod kan det være et problem hvis det lok du prøver at styre allerede er tildelt en knap på ib'en

Når du kigger på dokumentationen ... er det så denne her vi snakker om?`

http://uhlenbrock.de/intern/20/I9A694CA-001.apd/P50X.zip

det er nok bedste bud på en fungerende dokumentation.

Både ja og nej og ved ikke - MIT problem er, at jeg opretter loks på disken og når jeg henter et sådant frem igen, vil jeg gerne have, at formularens diverse "instrumenter" indstiller sig efter det fysiske lok, og derfor er det første jeg spørger efter, når et lok åbnes fra diske netop en status og den er IKKE tilgængelig FØR jeg har indtastet adressen på selve IB'en - altså som om FIFO lageret lige skal have oprettet adressen igen.

Jeg har (endnu) ikke prøvet bare at begynder st styre lok'et - det vil jeg da prøve - så kunne jeg jo gemme status på diske i stedet !

Det med at at Lok'et allerede ER styret fra IB'en er ikke noget problem, idet der NETOP er en mulighed for at vælge om programmet skal OVERSTYRE IB'en eller ej - og der har jeg prøvet begge varianter - men føler mest, at programmet SKAL overstyre - det vil i min situation forekomme yderst sjældent (når børnebørnene skal køre, er det nu rart lige at have styr på, hvad de gør, ved at have "deers" lok åbnet på pc'en også).

Ja, egentlig er det den, men jeg har fået en omskrevet udgave fra en Koos Boen i Holland - hvor den er tilrettet med overskrifter m.v. som gør den lidt mere læsevenlig. Det andet der er fuldstændig ubrugeligt som "læremateriale".

Mht BABI er der også den mulighed, at jeg kan aflæse SO#1 direkte med xSOGet - det vil jeg prøve i morgen. Der er vel egentlig bare det, som sker ved en BABI - ud over det lange BREAK, som vel bare nulstiller in/out-bufferne.

Jeg forstår heller ikke rigtigt alle det sleep/wait, der er i programeksemplerne - det burde da kunne alves bedre med at vente på det antal bytes, som skal gives tilbage på en kommando - FORUDSAT, at IB'en faktisk GØR, som dokumentationen siger og sender de angivne svar.

Hvor høj en baudrate kører du med ?

Jeg ku' sgu' alligevel ikke vente til i morgen med at afprøve det - og ja, du har ret, man kan styre loks umiddelbart - så skal jeg bare gemme "en pæn" status (= frem, med lys og hastighed på disken i stedet for at aflæse den i IB'en - den vil alligevel IKKE være tilgængelig, hvis IB'en har været slukket - that's it !

Tak for inspirationen !

Hm nu blir det jo teknisk...

Med hensyn til internt lager: ja du har fat i den lange ende. Hvis ikke nogen har "styret" dvs sat status på et lok med kanpper eller via seriel så kender IB'en ikke status og kan ikke melde den tilbage. Gem hellere status i dit program det er nok mere stabilt.

mht "babi" halløjet: som jeg læser dokumentationen har det lange break flere fordele: det sætter al kommunikation til 2400 bps samt enabler p50x mm. Efter breaket kan du være sikker på at det næste du sender bliver opfattet som starten på en ny kommando. Om du vil respektere brugerens valg i SO #1 må være op til dig. Du kan jo også bare pløje op i hastighed og se hvor langt den går..

Jeg kører bare 9600 hardcoded - havde ikke den store tålmodighed til at skrive algoritmer der kunne finde maksimal hastighed.

Grunden til de mange delays og underlige sager i qbasic eksemplerne er at de er fra en tid hvor man programmerede direkte til sin uart og desuden for at tilpasse intelliboksens særheder. En del af dette halløj vil forsvinde når du koder om i c# hvor al tilgang til seriel porten er pænt pakket ind.

ksor gør du fremskridt?

vh

Ja, det går fint - idag fik jeg lavet kabel mm. så jeg kunne prøve at køre med ALLE lok på én gang på den store bane - IB'en kan trække flere end jeg regnede med i første omgang - jeg kan køre med 6-8 loks på én gang !

Der er dog noget med de sidste kommandoer, som jeg ikke kan få til at lykkedes - W- og CReset (@ og @@), BREAK og BABI - de volder problemer.

Så virker det fuldstændig uforståeligt, at noget som en kortslutning IKKE reporteres som en event ud af COM-porten - man skal "spørge" om den slags - den som har designet IB'en har vist ikke særlig meget begreb om, hvad events er !

Det viste sig også, at én de mine 2 COM-porte var defekt - skønt jeg lige havde købt kortet - men alt i alt har det ikke været noget særlig god oplevelse at programmere mode IB'en - jeg troede den var lavet mere avanceret - det er jo næsten et dårligt "begynder projekt" mht. kommunikation.

Så nu vil jeg igang med at lave noget elektronik til styring af skiftesporene og signaler/bremsestrækninger gennem IB'en - jeg har lavet softwaren hertil.

Så fik jeg styr på BREAK-kommandoen !

Hvad er så specielt ved @ (WARM-start eller RESET) - jeg prøver med

comPort.Write("@");

og

comPort.WriteLine("@");

men igen af dem "virker" - når jeg siger de ikke virker, er det fordi jeg regner med at se den "normale" reset rutine i displayet på IB'en.

Men, VISES rent faktisk den "normale" reset-rutine i displayet på IB'en, når reset foretages fra et program - er der nogen, som har prøvet ?

Et det en p50x kommando eller noget specifikt i kommunikationenmed ib? Hvor ser du dokumentationen for reset kommandoen?

Kommandoen er en P50X-kommando og er omtalt som @, RESET eller WARM-start i det elendige dokumentationsmateriale fra Uhlenbrock.

Men jeg HAR nu fundet ud af, hvordan den skal fyres af nu - der skal sendes:

comPort.Write("x@"+(char)13);

Med denne kommando gør IB'en det samme, som hvis du holder GO/STOP-knapperne nede i et vist stykke tid - altså laver et RESET.

Det er dog vigtigt, at man liiiiige bemærker indholdet af SO#663 - det skal nemlig være 1 for at kommandoen virker - default er 0, men det var jeg nu opmærksom på - jeg havde ikke fået x'et med - DET var problemet.

Jeg vil bruge kommandoen til den alternative BABI-procedure, som også er omtalt i dokumentationen - for jeg synes det er noget rigtigt roderi, der foregår i den du sendte mig - men det er sådan de fleste BABI'er ser ud !

BABI betyder udelukkende "Break and Automatic Baud rate Identification" og så skal man ikke blande protokolbestemmelse ind i det samtidig - det er noget roderi og må (og kan) gøres på anden vis.

Der ER dog lige et problem tilbage, men det er op til Uhlenbrock at rette op på - og det er desværre IKKE gjort i den nye version 2.001 - når man via programkode spørger på indholdet af SO#803 returneres ALTID et 0 - og det UANSET hvilket sprog IB'en er indstillet til. Dokumentationen omtaler i øvrigt KUN sprogene UK, FR, IT, NL, SE, ES og PT - og der ER faktisk tale om to mere nemlig DK og DE.

Så nu tror jeg, jeg har skovlen under det hele mht. IB'en - jeg fik i øvrigt også presset hastigheden op på 38.400, så nu jeg kan KØRE mine loks fra det, som på sigt bliver min "sportavle" - og det virker faktisk rigtig godt.

Sportavlen VIRKER rigtig godt på skærmen, så nu skal jeg "bare" have bygget dekodere til skiftespor, signaler og bremsestrækninger.