Dinamo

Sorry als nog de bijlage

Ik krijg (DinamoConfig 1.41 en 1.40C)

• bij 2 x TM44 1.24 en RM-C 1.31A Clock OK
• bij 2 x TM44 1.24 en RM-C 1.40C Clock OK

Heb je alle TM44's bijgewerkt naar 1.24?
Mvg, Leon

Hallo Leon,
Ik heb er nu nog maar 2 in gebruik en als ik via DinamoConfig kijk dan zie ik na het updaten ook beide op V1.24 staan met een OK er achter echter als ik de check doe krijg ik bij master/slave dat het correct in is ingesteld en bij clock op beide TM no clock, zie bijlage

Ik zie het. En ik heb exact dezelfde configuratie en 2 x Clock OK.
Ik kan het dus niet reproduceren.
Is er wel een clock, dus doen beide TM44's het?

Ik heb TM44 met adres 0.0 nu in gebruik op een testovaal met inhaalspoor dus ja die werkt en staat als master ingesteld.
De 2e TM44 met adres 0.1 is al wel aangesloten (voeding en bus via utp kabel) maar nog niet in gebruik, dit gaat komen na een aanpassing die ik vandaag met Martin (DTS) heb besproken.
Ik zal morgen bij daglicht nog eens versie 1.24 erin schieten en dan kijken.
Voor zover ik als beginner het systeem begrijp gebruiken alleen de TM44's een "clock" en die wordt toch verstuurd over een 2e aderpaar??

Voor zover ik als beginner het systeem begrijp gebruiken alleen de TM44's een "clock" en die wordt toch verstuurd over een 2e aderpaar?

Klopt

De clock heeft een andere frequentie en ander patroon bij 1.21 en 1.24. Dus 1.24 begrijpt de clock van 1.21 (en TM-H 5.21) niet en andersom. Maar 1.23 en 1.24 zijn volgens mij identiek.
Als er een bedradingsfout zou zijn kan dat wellicht verschil maken (dat 1.21 het wel ok vindt en 1.24 niet), maar dan zou ik geen verschil verwachten tussen 1.23 en 1.24.
Als er een trein rijdt en je hebt detectie, dan moet er een clock zijn.

@ Leon,
Ik heb vanmiddag al mijn TM44's naar versie 1.23 gezet, dat ging vlekkeloos en DinamoConfig zegt dat alles correct is, dus master/slave en clock op alle 3 de TM44.
Het rare is, ik heb 1 TM44 en als ik die wil updaten naar versie 1.24 dan geeft de bootloader software een foutmelding.
Druk ik dan op de reset toets van de RM-U en kijk ik via DinamoConfig dan geeft ie wel aan dat er versie 1.24 aanwezig is.
Ik ga nog wel even stoeien en zal een screenshot maken van de "error" .

@Leon
Ik heb vanmorgen wat screenshots gemaakt van de huidige status met versie 1.23. Daarna heb ik per TM44 geprobeerd te updaten naar V1.24. De eerste TM met adres 0.0 gaf een foutmelding (plaatje volgt), de update op mijn 2e TM44 met adres 1.0 verliep vlekkeloos, en je raad het al, mijn 3e TM44 met adres 2.0 gaf ook een foutmelding (plaatje volgt). Na dit heb ik 1x op de resetknop gedrukt van mijn RM-C1+, tijdje gewacht en toen DinamoConfig gestart, tot mijn verbazing zie ik alle modules op versie 1.24 staan, echter als ik dan de "MS check" doe dan zie ik dat de master/slave config wel goed is maar dat er op alle 3 mijn TM44 geen clock is.....raar (plaatje volgt). Ik heb dus nu alle TMxx weer terug gezet naar V1.23.

dinamoConfig status bij versie 1.23

Foutmelding tijdens programmeren TM op adres 0.0 & 2.0

DinamoConfig MS Check na de update naar verzie 1.24

DinamoConfig Status na de update naar versie 1.24 ondanks 2x een foutmelding bij het programmeren

Hallo Jeroen,

Dank voor het uitzoeken en proberen.

Het probleem is: Ik kan jouw situatie niet reproduceren. Ik heb 2 systemen draaien op 1.24 en die doen het beide goed. Er zijn volgens mij inmiddels ook flink wat andere hobbyisten die 1.24 ontdekt hebben en waarbij geen clock-problemen gemeld zijn. Wellicht hebben die helemaal niet gekeken naar de clock-reportage met DinamoConfig. Daarom ben ik ook benieuwd of in jouw geval alleen DinamoConfig meldt dat er een probleem is, of dat de clock er ook echt niet is en er ook niets rijdt.
Aangezien het bij mij en op diverse andere systemen correct werkt is mijn voorlopige conclusie dat het GEEN software probleem is. Daarmee is jouw probleem echter niet opgelost.

Een firmware update die foutmeldingen geeft is mislukt. Het kan zijn dat er dan een deel van de firmware geladen is en dan heb je dus twee stukken firmware door elkaar. Omdat 1.23 en 1.24 relatief weinig verschillen kan het zijn dat het dan toevallig nog enigszins werkt. Een firmware-update die met fouten eindigt moet opnieuw totdat hij foutloos is. Je kunt bij AVRootloader de bootloader zelf niet stuk maken, dus de kans dat je eindigt met een "bricked" product is nagenoeg uitgesloten.

Inderdaad gaat een firmware-update wel eens mis. Blijkbaar zitten de modules elkaar tijdens een update soms in de weg. Dat is een "bekend probleem", maar tot nu toe is het niet gelukt hiervoor een sluitende oplossing te verzinnen. Er is wel een work-around die altijd werkt (tot nu toe): Neem een voldoende lange RJ45 kabel. Trek de normale RS485 kabel uit de RM-C en steek de update kabel er in. Verwijder de RS485 kabels uit de module die je wilt updaten en steek de update kabel daarin. Formeel zou je de terminators dan aan moeten zetten op de betreffende module, maar de praktijk leert dat het in 99% van de gevallen ook goed gaat als ze uit staan. Doe de update van de module op de gebruikelijke manier en herhaal voor alle volgende. Tussendoor hoef je uiteraard niet steeds de RM-C uit transparante modus te halen. Het gaat er om dat er steeds maar één module verbonden is zodat ze elkaar niet kunnen storen tijdens de update.

Waarom de update bij 1.23 geen probleem is en bij 1.24 wel is mij niet duidelijk. Het kan net een bit-patroontje zijn dat bij 1.24 wel voor komt en bij 1.23 niet. Ik kan me ook voorstellen dat de gedownloade 1.24 file beschadigd is. Tegelijk zou ik dan verwachten dat de update helemaal niet werkt. Maar het lijkt me voor de zekerheid nuttig de file nogmaals te downloaden.

Het kan zijn dat één van de RJ45 kabels in jouw systeem niet 100% is.

Het kan zijn dat één van jouw TM44's niet 100% in orde is. De kans dat er twee niet goed zijn is zeer klein. Om te achterhalen of het een hardware fout is zou je er 2 kunnen opnemen in een systeem, de adressen aanpassen en een andere TM44 master maken.

Ik kan me niet herinneren dat het ooit is voorgekomen, maar in theorie zou het kunnen dat de RM-C in jouw systeem de clockbus kortsluit. Ik zou verwachten dat het dan ook bij 1.23 een probleem is, maar goed. Je zou een RJ45 kabel in de RM-C kunnen steken en kunnen meten of je aan de andere kant tussen pin 3 en 6 van de RJ45 (ca) 120 Ohm meet.

Ik zie dat op een van de "screenshots" het master/slave venster en het clock-quality-venster getoond worden. Dat kan volgens mij niet. Het ene venster sluit vanzelf voordat het andere wordt geopend. Als je hebt zitten knippen en plakken, best, maar dan is het geen screenshot meer. Als je het op een andere manier zover hebt gekregen ben ik benieuwd hoe.

Met hartelijke groeten, Leon

@Leon
Update:
Vandaag een nieuwe poging gedaan:
Rm-C1+ via utp kabel direct aangesloten op 1e TM44 en de update naar versie 1.24 gedaan.
Uiteindelijk alle 3 TM44 foutloos kunnen updaten, en zonder de dip-switchjes te verzetten aangaande de afsluitweerstanden. Deel 1 is gelukt
Na een reset van de RM-C via DinamoConfig gekeken en jawel alle TM44 hebben nu versie 1.24 EN de check master/slave is correct EN......op alle 3 is nu ook de CLOCK OK.
Uit dit hele verhaal is naar mijn menig wel duidelijk geworden dat updaten van een TM44 dus eigenlijk gewoon altijd direct op de RM-C dient te gebeuren (zonder de rest van de modules) want meerdere TM44 op 1 bus geeft dus problemen. ( althans bij mij dan.)

Tevens sprak ik Martin (DTS) vanmorgen even en die gaf aan dat het toch beter zou zijn als ik mijn TM44 zowel primair als ook secundair gebruikte.
Dus ik ga de adressen van mijn TM44 aanpassen naar : 0.0 - 0.1 - 1.0 Dit ter info daar het niets met mijn eigenlijke probleem te maken had.

Klopt het trouwens dat de laatste firmware versie voor de RM-C1+ 1.40B is??

We kunnen dit onderwerp denk ik nu afsluiten aangezien het nu opgelost is.

mvgr Jeroen

Hallo Jeroen,

Als AVRootloader aangeeft dat de update foutloos is verlopen, en alleen als AVRootloader dat aangeeft, is deze gelukt. Heel vaak gaat dat ook goed in een systeem waarin alle modules gewoon zijn opgenomen, alleen soms niet. En er is door mij vooralsnog geen peil op te trekken wanneer en waarom dat mis gaat. Maar de work-around werkt dan.

Of je de TM44's primary en secondary gebruikt maakt technisch niks uit. Een secondary is niet trager of sneller dan een primary. Het enige is dat een secondary niet geadresseerd wordt als de bijbehorende primary er niet is. Als je dus een modulaire baan hebt waar niet altijd alle modules aanwezig zijn kan het handig zijn om secondaries niet als enige op een module te zetten, maar alleen als daar ook de corresponderende primary zit. Als je de secondaries overslaat krijg je wel "gaten" in de bloknummers? Is dat erg? Voor de meeste software maakt dat niets uit. En sommige software probeert toch de bezetmelders van niet-bestaande secondaries op te vragen. Dat wordt door de primary afgevangen, dus ook dat gaat goed.
Alleen: als er geen reden is de secondaries over te slaan adviseren we gewoon opeenvolgend te nummeren, dus 0.0, 0.1, 1.0, 1.1, etc. Dat maakt eventuele troubleshooting eenduidiger.

De laatste RM-x is 1.40C. Daar zit slechts een minimale bugfix in, die alleen in uitzonderlijke gevallen een probleem gaf op dual-channel systemen. 1.40C stond blijkbaar nog niet op DinamoUsers. Nu wel.

In elk geval mooi dat het het nu werkt. Het was dus wel een software probleem, maar anders dan je oorspronkelijk bedoelde.

Met hartelijke groeten, Leon