Databus Posted by Wouter Roos on 2017-05-01 19:44 Op de eerste en de laatste TM44 moet de afsluitweerstand worden geactiveerd, tenzij op deze TM44's ook een OC32 aangesloten is. moet in dat geval de bus worden afgesloten op de OC32 van de eerste en van de laatste TM44? Wouter
Databus Posted by Wouter Roos on 2017-05-01 19:44 Op de eerste en de laatste TM44 moet de afsluitweerstand worden geactiveerd, tenzij op deze TM44's ook een OC32 aangesloten is. moet in dat geval de bus worden afgesloten op de OC32 van de eerste en van de laatste TM44? Wouter
Posted by Frans Staal on 2017-05-02 14:21 Hallo Wouter, je hebt het eigenlijk over 2 bussen: de data bus en de clock bus. De clock bus zit alleen op de TM44's. Die sluit je dus af op de laatste TM44 (switch 8). Als je geen OC32 aan de laatste TM44 aansluit, sluit je ook de data daar af (switch 7), maar als je wel een OC hebt, dan sluit je hem alleen af op de OC. Groet Frans
Posted by Wouter Roos on 2017-05-02 19:14 Frans, Mijn eigenlijke vraag betrof de eerste TM44 met een daarop aangesloten OC32. Moet de databus ook in dit geval gesloten worden op de OC? Wouter
Posted by Hans B on 2018-01-21 13:05 Deze info stelt mij voor een raadsel: het suggereert dat de laatsteTM44 altijd afgesloten moet worden, ook als er nog een unit na de laatste TM44 op de RS485 bus zit ?? Ik heb problemen met de TM44 overgangen: als loc met de stroomafname wielen op 2 naast elkaar liggende blokken staat (op 2 verschillende TM's), dan krijgt de loc 'een duw in de rug' van 1/2 seconde. Dit bij PMW waarde 2; bij PMW warde 8 is dit euvel er niet. Kan het aan de afsluitingen liggen ?? Ik heb 13xTM44's + 7x OC32NG en (toevallig) zitten op het einde van de bus een OC32NG (RM-C zit halverwege de bus, dus ik ga vanuit de RM-C 2 kanten op; wel in RM-C de afsluitweerstanden afgekoppeld). Ik heb bij alle TM44's de beide afsluitweerstanden dipswitches op uit gezet en alleen bij de beide OC32NG's op de beide uiteinden de jumpers voor de afsluitweerstanden gezet. Ik dacht dat ik zo netjes de bus afsluit. Of moet het toch anders en moet 1 van de dipswitches op de laatste TM4 toch op aan staan ??? Gr Hans
Posted by Leon van Perlo on 2018-01-21 13:41 Hallo Hans, Ja het is ook lastig als men het onderliggende relatief eenvoudige basisprincipe niet begrijpt. Maar gelukkig geldt dat voor jou niet, want jouw post lezende zitten jouw afsluitingen goed. Met de /NG is het ook weer iets simpeler geworden. Jouw probleem komt waarschijnlijk omdat je niet alle TM's identiek hebt ingesteld of omdat je je master/slave niet goed hebt staan. Voor dat laatste zit in DinamoConfig een testmogelijkheid. Mvg Leon
Posted by Hans B on 2018-01-21 14:48 Beste Leon, Bedankt voor je snelle reactie. Ik ben al en tijdje aan het zoeken naar de oorzaak van de 'push bij TM overgang'. Ik heb met DinamoConfig de master/slave gecheckt en dat staat goed: TM met nr 0.0 = master en rest = slave. Dinamo Config geeft ook de melding dat het OK is. De TM4 met adres 0.0 zit wel 'ergens' in de RS485 bus (niet direct naast de RM-C), mar volgens mij maakt dat niets uit. De TM's hebben allemaal dezelfde software versie (1.20) en zijn volgens Dinamo Config 'actief'.. Voor zover ik weet staan de TM's allemaal hetzelfde ingesteld; wat zou er verschillend kunnen zijn ?? Geeft het (vreemde) verschijnsel dat het euvel wel bij TMW waarde 2 optreedt en niet bij 8 (bij TMW 4 klein beetje) nog een indicatie van waar de oorzaak kan liggen? Ik heb met DinamoUserCC geëxperimenteerd bij een TM44 overgang door bij een stoomloc met tender de tender van de rails te lichten en de stroomafnemende wielen van de loc over de blokovergang te schuiven: zodra de stroomafnemende wielen aan beide kanten van de blokscheiding staan (en dus op beide TM's 'staan') gaat de tender harder lopen (+ licht iets feller) en zodra bij verder doorschuiven de loc weer op 1 TM staat , is het weer normaal. Het verschijnsel doet zic op vele (alle ??) blokovergangen voor waar er ook TM44 wisseling is; bij blokovergang met dezelfde TM is er niets aan de hand. Hopelijk verduidelijkt deze toelichting ?? Gr Hans
Posted by Hans B on 2018-01-21 14:54 NB: ik dacht eerst dat het zou komen omdat de loc gevoed wordt vanuit 2 TM44's, dus eventuele spanningsverliezen gehalveerd zouden worden. Ik heb echter 3-4x zwaardere bedrading gebruikt dan in de handleiding staat (zowel voedingsdraden als blok + melder aansluitingen) en de aansluitdraden naar de rails zijn ook kort 0,5-1,5 meter) en voeding van 150watt is ook zwaar genoeg. Nu het verschijnsel niet optreedt bij TMW waarde 8, kan het m.i. ook bijna niet aan 'verminderd spanningsverlies' liggen. Gr Hans
Posted by Hans B on 2018-01-21 18:18 Het is opgelost !! Een treinvriend heeft mij uurtje terug een specifieke RM-U handleiding gestuurd waar op blz. 9 H.2.2.4 'optimalisatie van de USB verbinding' vermeld staat. Daarin staat dat je de bij de betreffende com-poort de receive + transmit bytes waarde terug moet brengen naar 64 bytes (stond op ruim 4000, terwijl 64 de laagste in te stellen waarde is, dus dat scheelt nog al !!) en de timer naar 2 msec (stond ook vel hoger). Ik vind het vreemd dat dit niet in de 'gewone' Dinamo handleiding staat bij het RM-U hoofdstuk. Je verwacht niet dat je ook nog een afzonderlijke RM-U handleiding moet lezen, terwijl dit zoals nu blijkt toch essentiële informatie is. NB: Ik blijf het trouwens wel gek vinden dat het verschijnsel bij PMW waarde 2 wel op trad en bij waarde 8 niet. Ik had wat meer 'gekke kuren' waarvan ik aannam dat het aan iTrain lag, maar wellicht lag het ook aan deze instellingen en is dit nu ook verleden tijd. Gr Hans
Posted by Leon van Perlo on 2018-01-21 20:12 Hallo Hans, Fijn dat het is opgelost. Maar het heeft niks te maken met de instellingen van de USB poort. Verder zijn de instellingen die je noemt niet relevant meer en het is dus geen "essentiele informatie". De pakketgrootte zou nog enige verbetering voor de netto snelheid kunnen hebben, maar de 2ms timeout is bij de RM-C niet van toepassing omdat die USB interface anders werkt. Daarom staat het ook niet meer in de nieuwste handleidingen. Mvg, Leon
Posted by Hans B on 2018-01-21 21:19 Beste Leon, Maar waarom werkt het nu dan na het veranderen van de COM poort instellingen plotseling wel goed ?? Ik heb verder níets veranderd !! Dan moet dat toch (dé) invloed hebben gehad? Gr Hans
Posted by Leon van Perlo on 2018-01-21 21:23 De enige manier om daar achter te komen is de instellingen weer terugzetten, dan weet je het. Mvg, Leon
Posted by Hans B on 2018-01-22 18:45 Beste Leon, het is mij een volkomen raadsel. De COM poort settings teruggezet op standaard computer settings en het ‘dubbele TM push effect’ komt NIET terug ????!!!!!! Voor alle zekerheid treinen stop gezet en gecheckt of de originele settings inderdaad actief waren en of PMW nog op 2 stond: was het geval. Ik had het op de oude testbaan ook al (nog met jou tijdens EuroRail in Utrecht erover gehad) en de afgelopen maand op de uitgebreidere baan niet 1x dat het euvel er níet was. En gisteren was het plots weg. Het enige dat ik gisteren (vlak voor wijzigen COM poort settings) óók gedaan heb is PMW van 2 naar 8 gezet (bij PMW 8 was euvel weg). Na het op advies van treinvriend wijzigen van de COM poort instellingen PMW teruggezet naar 2. Voor de rest NIETS gewijzigd. Je zou bijna denken dat het wijzigen van de PMW waardes het euvel opgelost heeft; erg jammer dat ik voordat ik de COM poort gewijzigd heb, niet eerst PMW weer op 2 gezet heb om te zien of euvel terug zou komen. Mijn treinvriend dacht dat wellicht de TM's op verschillende PMW waarden hadden gestaan en dat het door ze allemaal op 8 te zetten en toen weer op 2, hetzelfde zijn geworden. Dat betwijfel ik: alle TM’s worden standaard met PMW 2 afgeleverd en ik heb dacht ik (weet ik echter niet 100% zeker) de waardes ook gecontroleerd toen ik master/slave, licht intensiteit + off-set voor het licht ingesteld heb met Dinamo Config. Ik had het euvel met de testbaan ook al en daar weet ik 100% zeker dat beide TM’s op PMW2 stonden. Wellicht was het toch (maar onverklaarbaar) iets met de stabiliteit van de PMW waardes ?? Ik bedacht ook nog dat voor activeren van de nieuwe COM poort instellingen ik de RM-C af moest koppelen en opnieuw erin. Dat zal toch niet iets teweeg hebben gebracht ???? Inmiddels paar keer opnieuw opgestart en het is nog steeds OK. Ik hoop dat jij er een verklaring voor hebt, anders vrees ik dat het altijd een raadsel zal blijven wat de oorzaak was en waarom het nu verdwenen is. NB: ik had trouwens wel gelijk weer iets instabiels in de rijroutes (wat ik ook eerder had gehad maar wat ik bij de veranderde COM poort settings níet had), dus ik ga de COM poort wel weer op lagere waardes zetten. Wat zou een optimale waarde zijn ?? Gr Hans
Posted by Leon van Perlo on 2018-01-22 22:47 Hallo Hans, Mij verbaast het niet. De USB instellingen zijn hier niet de oorzaak van. Ik kan je dat vertellen, maar dat helpt niet, dat moet je zelf ontdekken. Ik weet vrij zeker dat je instellingen van de TM-H's onderling niet gelijk waren. Dan krijg je typisch dit gedrag. Andere mogelijkheid is dat je TM44's niet synchroon lopen. Aannemende dat je ze met RJ45 kabeltjes hebt aangesloten is de kans op een bedradingsfout klein, dus daarom sluit ik dat voor het gemak maar uit. Ik weet niet hoe jij de parameters van je TM44's aanpast, maar het best kun je als module "All TM44" kiezen. Dan weet je ook zeker dat de betreffende instelling op al je modules wordt toegepast. En let op het vinkje "permanent". Uiteraard kun je nog steeds uitproberen of het verschil in PWMM dit gedrag veroorzaakt. Zet de ene op 2 en de andere op 8 en kijk wat er gebeurt. Is dat wat je eerder gezien hebt dan weet je ook dat weer. De optimale instellingen van de RM-C USB zijn gewoon standaard. De USB zelf is zo snel dat het aantal bytes simpel gezegd geen bal uit maakt en de timeout geldt niet voor de USB chip op de RM-C. Die wordt hardwarematig geflushed. Mvg, Leon
Posted by Hans B on 2018-01-22 23:19 Hallo Leon, Bedankt voor je uitleg. De 13 TM44's zijn (samen met de 7 OC32NG's) met behulp van de RS485 bus aangesloten via kant en klare kabeltjes (die heten blijkbaar RJ45). Zoals eerder gemeld met RM-C in 'het midden' (jumpers gewijzigd in RM-C conform handleiding) en de 2 OC32NG's op beide uiteinden met afsluitweerstanden actief. Bij instellen van de TM44's met Dinamo Config gebruik ik inderdaad de 'TM44 all' met vinkje 'permanent' en controleer ik meestal 2 of 3 TM's individueel door de setting op te vragen om te zien of het 'groene vakje' dan klopt met de ingestelde 'all setting'. Ondanks dat het euvel nu verdwenen is, wil ik graag snappen wat er nu loos was, dus zal inderdaad eens kijken wat er gebeurd met verschillende PMW waardes (hoewel ik eigenlijk niet kan voorstellen dat ze verschillend hebben gestaan). Laat ik weten. NB: wat het geheel wel vreemd maakt, is dat ik exact hetzelfde verschijnsel op de testbaan had met maar 2x TM44 + 1c OC32NG en toen stonden de beide TM's 100% zeker identiek ingesteld. De standaard COM poort settings laat dan inderdaad maar zo gezien je advies. Gr Hans
Posted by Leon van Perlo on 2018-01-23 00:39 Wat je bij 13 TM44's en 7 OC32's nog zou kunnen doen is de RM-C optie "S1 38k4" (permanent) aanzetten (DinamoConfig tabblad RM-U/UCCI). Mvg, Leon
Posted by Hans B on 2018-01-23 09:00 OK Leon, ga ik straks ook uittesten. Om er van te leren: wat doet de S1 38k4 optie ? (in de RM-C handleiding 1.0 staat er niets over) Gr Hans
Posted by Leon van Perlo on 2018-01-23 09:39 Hans, Het verdubbelt de bitrate op de RS485 bus, Vroeger, toen TTL nog gangbaar was, had dat nut. Nu tegenwoordig 99,5% RS485 gebruikt kan dat eigenlijk wel standaard aan staan. Het heeft vooral (enige) invloed op de snelheid waarmee feedbacks terugkomen. Voor commando's maakt het niet zo bar veel uit, tenzij het er heel veel zijn. Mvg, Leon
Posted by Hans B on 2018-01-23 09:55 OK Leon, bedankt. Ik heb net geprobeerd dat vinkje aan te zetten, maar dat werkt niet. Dat wil zeggen: het vinkje kan ik aanzetten (met permanent vinkje aan en op 'RMU config' gedrukt), maar bij afsluiten en opnieuw opstarten DinamoConfig is het vinkje weer weg. Er is niet zoals bij de TM settings een 'set ....' knop, dat zou het indrukken van de RMU config knop moeten zijn (doe ik ook ná vinkje zetten) maar het valt weer weg. Ik heb het ook nog geprobeerd met het vinkje 'stop' uitgezet (je weet maar nooit), maar dat helpt ook niet, dus ik doe blijkbaar iets niet goed waardoor het weer wegvalt ?? NB: net nog paar keer geprobeerd; ook systeem opnieuw opstarten daarna (dan pas nieuwe setting actief volgens handleiding) maar vinkje blijft wegvallen. NB: net in de DinamoConfig handleiding ook gelezen wat de S1 38k4 doet (sorry: ik had het eerst alleen in de RM-C handleiding gezocht. Wellicht daar verwijzing naar Config handleiding maken ?? Er staat wel verwijzing over configureren, maar niet dat daar ook die andere settings worden uitgelegd) Gr Hans
Posted by Leon van Perlo on 2018-01-23 11:18 Beste Hans, Uiteraard moeten de handleidingen alles bevatten dat relevant is. Tevens moeten de handleidingen simpel zijn en maximaal 10 pagina's. Tot slot leest niemand ze. Dus wat er in een handleiding staat is een keuze. Soms laten we bewust dingen weg die niet meer relevant zijn, of slechts in zeer uitzonderlijke gevallen. Die 38k4 is ook voor jou niet cruciaal. Ik vraag me zelfs af of het in de praktijk iets uit maakt. Daarom staat het er niet meer in. En als je het hebt aangezet werkt het. Je kunt de waarde nog niet teruglezen. Mvg, Leon
Posted by Hans B on 2018-01-23 12:07 Beste Leon bedankt en duidelijk. Inderdaad kan een te uitgebreide handleiding afschrikwekkend werken (ik zelf ben wellicht uitzondering: ik heb alle Dinamo + iTrain handleidingen diverse keren gelezen en elke keer vergeet je toch weer iets en dan bij weer nalezen valt je iets op waar je eerder (te) weinig aandacht aan hebt geschonken). Dat na aanzetten S1 38k4 vinkje het weer verdwijnt, maar de instelling wél actief is, is wel verwarrend.(Ik had niet begrepen dat dit bedoeld wordt met: "De actieve instellingen worden niet opgehaald en niet onthouden door het programma.") Straks verder met experimenteren PMW settings. Gr Hans
