Twentse Modelspoorweg Club (TMC): Digitale besturing

[bask185]

Waarom zou je dat doen? naast dat dat ding duur is. De rails zijn zelf al galvanisch gescheiden van de inputs. Ik wil het 5V circuit wel vanuit loconet voeden.

[AP3737]

Beste Forum lezers

Zoals in een eerdere bijdrage al vermeld, Hebben we een XpressNet library (DLL) geschreven, zodat onze (Visual Basic) PC-programmatuur makkelijk kan praten met met DCC Command Stations. Alhoewel het ons vooral om wissel (accessory) en terugmeld commando's gaat, hebben we ook de meeste andere XpressNet commando's geïmplementeerd. Omdat het XpressNet protocol op een aantal plaatsen overeenkomt met het Z21 protocol, hebben we de library ook meteen maar uitgebreid met een aantal Z21 commando's.

Tijdens het testen van wissel commando's met de Lenz en Yamorc centrales liepen we tegen een aantal (voor mij verrassende) verschillen op. Aan de hand van een tweetal plaatjes zal ik deze verschillen uitleggen.


Het bovenste plaatje toont wat er gebeurt als de PC een XpressNet "Schaltbefehl" (blauw) naar een Lenz centrale (LZV100/LZV200) stuurt (zie §3.2.24 van de XpressNet V3.6 mit
LAN/USB Interface specificatie). In dit XpressNet commando is het "Ausgang aktivieren" bit gezet (het rode bit).

Na ontvangst van dit commando begint de centrale met het versturen van een continue stroom van identieke DCC "Zubehördecoder" pakketjes (zie 
§2.1 van RCN 213). Bij ieder van deze DCC-pakketjes is eveneens het "Ausgang aktivieren" bit gezet (rode bit). Zolang de "Ausgang" geactiveerd is, zet de decoder spanning op de betreffende uitgang (bv. een wisselspoel). Afhankelijk van wat de centrale nog meer te doen heeft, wordt ruwweg elke 20ms dit pakketje opnieuw gestuurd. Het idee hierachter is dat je op je handbediening net zo lang een knop ingedrukt kunt houden, totdat "iets" zijn eindstand heeft bereikt. Ik vermoed dat deze manier van werken door Lenz is bedacht, in een tijd dat er alleen handbediening, maar nog geen computer besturing bestond.

De stroom pakketjes stopt pas, als de PC een XpressNet "Schaltbefehl" (groen) stuurt, met daarin het "Ausgang aktivieren" bit op 0 (het rode bit). De Lenz centrale stopt dan met het sturen van DCC wissel commando's. De Lenz centrale stuurt echter geen DCC "Zubehördecoder" pakket met het activeren bit op 0!

Het continue versturen van identieke DCC wissel commando's zorgt voor een onnodige belasting van de DCC centrale en bekabeling, zeker als er ook veel andere DCC commando's verstuurd moeten worden. De DCC-specificaties (van de NMRA en RCN) geven daarom ook alternatieven om een decoder uitgang te deactiveren. Het eerste is gebruik te maken van specifieke CVs (Configuratie Variabelen), die aangeven hoelang (im ms) een uitgang geactiveerd moet zijn. Het tweede alternatief is het versturen van een DCC "Zubehördecoder" pakketje waarin het "Ausgang aktivieren" bit is uitgezet (dus de waarde 0). Het blijkt dat Lenz dit laatste pakketje NIET verstuurd.

Zoals uit het onderstaande plaatje blijkt, stuurt de YAMORC centrale dit DCC deactiveren commando WEL. Ook dit commando wordt een (instelbaar) aantal keren herhaalt (default: acht). Mocht de PC geen Xpressnet deactivate sturen, dan zal de YAMORC centrale na een bepaalde tijd (2,5 sec), uit zichzelf een DCC deactiveer commando sturen (de groene pijlen rechts onder).


De vraag die je nu zou kunnen stellen is "waarom zijn bovenstaande details voor de TMC van belang?". Het antwoord is eenvoudig: de meeste wisselaandrijvingen hebben 2 spoelen. Als er spanning wordt gezet op de eerste spoel, schakelt de wissel in een bepaalde positie; als er spanning wordt gezet op de tweede spoel, schakelt de wissel in de andere positie. Bij de TMC worden wissels echter geschakeld met (oude) telefoonrelais. Als er spanning op het relais wordt gezet (activeren), schakelt de wissel naar de ene positie. Als de spanning weer wordt weggehaald (deactiveren), schakelt de wissel naar de andere positie. We dachten dus door middel van het activate bit in het XpressNet (en DCC) commando de wissel in de ene dan wel andere stand te kunnen zetten. Dat blijkt dus niet zo te zijn.

Weer wat geleerd,
Aiko

[bask185]

Ik weet nog van experimenten met die Xnet library van Gathow dat de Xnet bus ook echt vast liep als ik niet op tijd een nieuwe instructie verstuurde met die activation bit op 0. Dan zag ik op de multimaus bijvoorbeeld zowel de stand voor rechtdoor als gebogen tegelijkertijd en niks werkte dan nog.

Ik weet dat marklin hun eigen Motorola decodeer chip had laten ontwikkelen. Zo konden ze zonder software een accessoire decoder op de markt krijgen. Dan wordt zo'n activation bit best belangrijk. Ik heb het idee dat de nieuwe K83/M83 decoders er nog steeds gebruik van maken. Ik weet nog mij de MSA dat die marklin banen (bediend) door iTrain altijd absurd lange pulsen stuurde en dat in 2 voud. Die schakelde 2x 500ms per wissel ofzo. Met de verwijderde eindafschakelaars kon je dat goed horen brommen.

Het blijkt dat Lenz dit laatste pakketje NIET verstuurd.

Dit vind ik heel raar eigenlijk. Je zou denken dat dit met sommige oudere decoders mis zou moeten gaan? Wanneer de spoelen niet meer uit gaan.

In mijn source negeer ik die activation bit als die 0 is. Ik kijk dan alleen naar de direction bit. Een goede decoder doet zijn eigen puls tijd regelen. Misschien 1x instellen maar dan heb je nooit meer last van 'vreemd handelende centrales'.

We dachten dus door middel van het activate bit in het XpressNet (en DCC) commando de wissel in de ene dan wel andere stand te kunnen zetten.

Ik zou dan eerder denken om de code van de decoders aan te passen? Ik neem aan dat jullie wissels al een tijdje operationeel zijn toch? Wat is er veranderd?

Mvg,

Bas

[AP3737]

Beste allen

Eerst een vraagje aan de mensen met verstand van loconet: is er ergens een loconet monitor waarmee ook de belasting op de bus, aantal collissions (=te korte berichten) en transmissie fouten (XOR?) bekeken kunnen worden?

Achtergrond, we hadden gisteren tijdens testen massieve problemen, die pas overgingen nadat we de JMRI PC met Z21APP en monitor software helemaal afkoppelden. We merken dat we behoefte hebben aan betere monitoring.

@Bas: volgens de NMRA/RCN specs is het versturen van een DCC Accessory Command met activation bit =0 OPTIONEEL. Vind ik ook raar, en kan dat alleen verklaren uit het feit dat (de "uitvinder van DCC) Lenz het niet stuurt.

@Bas: Natuurlijk schrijven we onze decoder software zodanig dat het gewoon werkt. Een gedachte dat we gewoon het relais (de spoel) activeren dan wel deactiveren, leek echter ook best verdedigbaar. Maar werkt dus toch niet.

@Bas: de Z21PG gaan we ook nog wel testen :-)

Groet, Aiko

[bask185]

Ik denk dat je de mrrwa library redelijk makkelijk kan aanpassen om minstens het aantal berichten te monitoren en te tellen hoeveel verkeerde checksums er binnen komen. Dan kan je met een Arduino en een loconet interface het eea monitoren via usb en een terminal.

Het moet ook mogelijk zijn om collisions te volgen die andere apparaten veroorzaken. Het laatste wat ik me herinner is dat er dan een pauze plaatsvindt waardoor iedereen weet van de collisie. Maar ik moet dan met mn neus de documentatie induiken en dan iets van een callback toevoegen aan die Library.

Bas

[AP3737]

Ik denk dat je de mrrwa library redelijk makkelijk kan aanpassen om minstens het aantal berichten te monitoren en te tellen hoeveel verkeerde checksums er binnen komen.

Ja, aanpassen van de mrrwa library is inderdaad een mogelijkheid

Het moet ook mogelijk zijn om collisions te volgen die andere apparaten veroorzaken. Het laatste wat ik me herinner is dat er dan een pauze plaatsvindt waardoor iedereen weet van de collisie. Maar ik moet dan met mn neus de documentatie induiken en dan iets van een callback toevoegen aan die Library.

Ik vermoed dat collisions het makkelijkst gedetecteerd kunnen worden door te kijken of er een signaal is, dat na korte tijd (enige us) wordt afgebroken. Daarna moet het even stil zijn. Pauze alleen lijkt me een onvoldoende voorwaarde.

Het lijkt me dat dit alles low-level in de mrrwa library moet worden aangepast, dus in de statemachine die het loconet pakket samevoegd. De mrrwa library is helaas niet bijzonder "onderhouds vriendelijk" geschreven. Heeft niemand anders zoiets geschreven?

Groet, Aiko

[Karst Drenth]

Tja.... mrrwa...

dit zijn de autoren: Alex Shepherd, John Plocher, Damian Philipp, Tom Knox, Hans Tanner, Björn Rennfanz

Stuk voor stuk "kopstukken" van de internationale LocoNet scene...

Ik heb geen ervaring met hun LocoNet lib, alleen... dat heb ik wel met de DccNMRA lib. Gemaakt door dezelfde mensen. En daarover heb ik een hele stellige mening, die ik hier niet zal ventileren 

De mrrwa library is helaas niet bijzonder "onderhouds vriendelijk" geschreven.

dat geldt ook voor de dccNMRA lib, Aiko heeft het naar mijn menig hééél erg netjes verwoord

Grtzz,
Karst

[Karst Drenth]

Ik vermoed dat collisions het makkelijkst gedetecteerd kunnen worden door te kijken of er een signaal is, dat na korte tijd (enige us) wordt afgebroken. Daarna moet het even stil zijn. Pauze alleen lijkt me een onvoldoende voorwaarde.

Correct. Collisions kunnen echter uitsluitend op bitlevel ( en dan ook nog de 1 bits ) door de zender gedetecteerd worden! ( 1 bit wil gestuurd worden, maar 0 bit wordt gelezen. Dat betekent, dat een andere deelnemer mee zit te blèren op de lijn)

Vanaf extern kun je alleen een evt. framing error of de al genoemde "break" detecteren. Dat break-detecteren kun je gewoon met de UART doen als je daarvoor kiest.

Voor alle andere gevallen ben je aangewezen op het controleren van de het hele bericht én de daarbij behorende XOR. 

Allemaal niet heel makkelijk dus. Je moet dus eigenlijk bit-bangend verzenden. en een paar microseconden daarna teruglezen wat er op de lijn staat. Allemaal niet erg timing en processor vriendelijk. Ik gebruik daarom zowel voor het zenden als het ontvangen gewoon de UARTs. Dat doet de job uitstekend. Het enige dat me kan overkomen, is dat ik een paar honder microseconden te laat door heb dat er een collision is. Maar het is toegestaan door De LN specs

All transmitters are responsible for detecting TRANSMIT COLLISIONS on a 1 bit or whole echo-byte basis. If a TRANSMIT collision is detected the TRANSMITTER will force a line BREAK of 15 BIT times with a Low or "SPACE" on LocoNet, and decrement the Transmit Attempt count. (The device can attempt the next acess at the same Priority, or change it by some small amount, depending on an internal Phase reference, if the delay from Network free to Seizure is greater than 2uS).
All receivers will process the BREAK as bad data framing and reset Message parsers The network is then free to re-arbitrate access. Any message that has format or framing errors , data errors or is a fragment caused by noise glitches and does not completely follow the MESSAGE FORMAT will be ignored by ALL receivers, and a new OPCODE will be scanned for re-synchronization.

Grtzz,
Karst

[AP3737]

Hi Karst

Ik gebruik daarom zowel voor het zenden als het ontvangen gewoon de UARTs. Dat doet de job uitstekend. Het enige dat me kan overkomen, is dat ik een paar honder microseconden te laat door heb dat er een collision is. Maar het is toegestaan door De LN specs

Klopt het dat je dan, nadat een compleet byte is verstuurd, het ontvangen byte vergelijkt met het verstuurde? Hierdoor wordt dus na ongeveer 500us gecheckt of er een collission heeft plaatsgevonden? Lijkt me (bij hoge belasting) niet ideaal, maar ik ben met je eens dat continue interrupts afhandelen nog minder is. Ik heb het nog niet in detail begrepen, maar misschien is de aanpak van Mikael Ejberg (https://www.ejberg.dk/portfolio/loconet-avr-da/) toch wel interessant.

Groet, Aiko

[piksov]

Hallo Aiko ..

<dames en heren, nu iets heel anders>

is dat lage houten stoeltje met afgezaagde pootjes nog steeds op de club?

Die pootjes afzagen heb ik iets van 32 jaar geleden gedaan .....

:-)

Guus

[bask185]

Ik heb wel eens gelezen dat iemand bij gebruik van RS485 op een atmega een pin change interrupt gebruikte op TX om daarmee een hardware timer en een ISR te starten waarmee hij periodiek (1 bit lengte) de niveaus deed checken van zowel Rx als Tx. Als Rx dan niet gelijk was aan Tx, dan had je een collision te pakken. Wordt wel een interrupt feestje zo  , maar als het werkt?...

[Karst Drenth]

Klopt het dat je dan, nadat een compleet byte is verstuurd, het ontvangen byte vergelijkt met het verstuurde? Hierdoor wordt dus na ongeveer 500us gecheckt of er een collission heeft plaatsgevonden?

Correct, zo wordt het behandeld. Maar het is minder erg dan gedacht. Bij bit-wise check zit je tussen 120 en 540 us aleer je een collision detecteerd.

Lijkt me (bij hoge belasting) niet ideaal, maar ik ben met je eens dat continue interrupts afhandelen nog minder is.

A) het valt binnen de specs, B) bitbangen is een groter euvel in een RTOS omgeving

Ik heb het nog niet in detail begrepen, maar misschien is de aanpak van Mikael Ejberg (https://www.ejberg.dk/portfolio/loconet-avr-da/) toch wel interessant.

De AVR-DAx is zo in te stellen, dat het teruglezen op bit-level gedaan kan worden door de USART zelf. Dan zit je dus op het niveau van bitbangen, zonder te bitbangen


@bask,

Het gaat over LocoNet, niet over XpressNet (RS485) en op XpressNet heb je geen collisions, omdat dat een gepolled protocol is, met voorgeschreven time-out tijden.

Grtzz,
Karst

[bask185]

Ja dat weet ik, ik had ook helemaal niet over XpressNet. Waar het om ging is dat bij je loconet dezelfde approach zou kunnen gebruiken voor een snellere collision detectie op de genoemde primitievere atmega. Bij beiden heb je een Rx en Tx pin.

[Karst Drenth]

 

[AP3737]

@Bas: Zou je niet veel beter een logisch poortje kunnen nemen, in plaats van iedere 60us een interrupt? Want interrupts zijn behoorlijk kostbaar.

@Karst: Ik ken de precieze structuur van Loconet berichten niet, maar voor zover ik begrijp kan een zender pas een collision vaststellen als hij zelf een HIGH zend (en dus een lijnspanning verwacht van > 4  Volt) terwijl een ander een LOW zend (dus de lijnspanning naar 0V trekt). Een collision kan daarom alleen gedetecteerd worden als de bitpatronen die twee zenders versturen, ergens verschillen. Dat kan dus best een tijdje duren. 500us lijkt me dus inderdaad geen probleem; ik vermoed zelfs dat het kan voorkomen dat de collision pas in het tweede byte gedetecteerd kan worden.

Om heel eerlijk te zijn, verbaast het me wel als nog niemand een Loconet monitor heeft geschreven die ook collissions en transmissiefouten kan tellen.

Groet, Aiko