Modelbaanbouw voor de liefhebber > Modelbaan planning en bouw

probleem bezetmelding met terugmelddecoder DR4088LN-cs van Digikeijs icm. DR5000

(1/4) > >>

antoni-a:


Onderstaande tekst is geenszins bedoeld om negatieve beoordelingen te ventileren. De informatie welke ik heb samengevat geeft weer tegen welk probleem ik ben opgelopen bij mijn modelbaan. Door het hier op dit h0-Modelspoor-forum te vermelden kunnen andere modelspoor hobbyisten die soortgelijke problemen ondervinden - maar de oorzaak ergens anders zoeken - misschien worden geholpen.
probleem bezetmelding met terugmelddecoder DR4088LN-cs van Digikeijs icm. DR5000
In dit hoofdstuk breng ik mijn ervaring met de bezetmelding met de DR4088LN-cs, en een hardnekkig probleem met die bezetmelding, onder de aandacht.
Voluit heet de terugmelddecoder: DR40888LN-CS LocoNet terugmeldmodule met 16 geïntegreerde bezetmelders voor twee rail systeem met LocoNet aansluiting.
Op diverse fora heb ik in het verleden berichten gezien waarin wordt gesproken over een probleem met deze terugmeldmodule. Klaarblijkelijk zijn er problemen die voortkomen uit verkeerde (te dunne) bedrading, spookmeldingen, verkeerd programmeren, enz.

Maar het probleem dat ik ervaar heeft niets van doen daarmee. Op De Geuldalbaan wordt voor de bedrading van de bezetmelding 0,5 mm² gebruikt, de bedrading van de bezetmelders is gescheiden van alle andere bedrading en alle niet-gedetecteerde railstukken worden voorzien van spanning via een diodeschakeling.

aard van het probleem met de DR4088LN-cs
Op De Geuldalbaan zijn alleen DR4088LN-cs terugmeldmodules gebruikt, dus uitsluitend de Loconet uitvoering. De keten van DR4088LN is aangesloten op de DR5000 via de Loconet-T aansluiting. De Terugmeldmonitor van de DR5000 geeft aan waar een verbruiker zich bevindt door middel van een vinkje.   
 


Per toeval ontdekte ik dat bij het opstarten van de DR5000 er af en toe een vinkje ontbreekt in de terugmeldmonitor, terwijl er op dat moment wel een verbruiker op de terugmelder staat. Bij ongeveer 1 op de 20 pogingen treedt de fout op.
Eerst dacht ik dat misschien vervuilde rails of vuile wielen de oorzaak zouden kunnen zijn. Dat bleek niet het geval. Verder onderzoek heeft uitgewezen dat de fout optreedt ongeacht de bezetmelder, en dus onafhankelijk is van de terugmeldmodule. Het kan dus op eender welke plek op de baan optreden. Het probleem is ook onafhankelijk van de betreffende loc. Verder blijkt dat wanneer de ‘gemiste’ loc/trein op de volgende bezetmelder komt, de terugmeldmonitor weer correct alles weergeeft, en vanaf dan blijft ook alles correct weergegeven. De fout manifesteert zich uitsluitend bij het opstarten van de baan.

een analyse
Op het moment dat ik het bezetmeldprobleem opmerkte waren er vijf DR4088LN-cs modules aangesloten volgens onderstaand schema. De vraag was of er wellicht een of meerdere defecte modules tussen zaten? Of dat er een defecte Loconet-kabel was gebruikt?
Eerst heb ik de Loconet-kabels uitgewisseld. Dat blijkt niet van invloed. De kabels zijn goed.



Vervolgens heb ik alle terugmeldmodules losgekoppeld op de eerste (A) na. De fout treedt dan niet op! Daarna heb ik de tweede terugmeldmodule (B) weer aangesloten op de eerste. Dat blijkt ook goed te gaan. Zo heb ik ook weer terugmeldmodule (C) en terugmeldmodule (D) weer aangesloten, alles zonder problemen.
Zodra ik terugmeldmodule (E) aansluit treedt de fout weer op. Ik dacht dus een defecte terugmeldmodule te hebben gevonden. Maar … als ik module (E) verwissel met module (A) krijg ik dezelfde uitslag.
Met andere woorden: zodra er vijf DR4088LN-cs terugmeldmodules in de keten zijn opgenomen kan de fout optreden. Zelfs als module nummer vijf uitsluitend via de Loconet-kabel is verbonden met de voorgaande module (dus zonder voeding en zonder bedrading naar de bezetmelders). Dit is wat ik constateer bij De Geuldalbaan, misschien hebben anderen er geen last van.

Ik heb de volgende tabel opgesteld om een en ander inzichtelijk te maken.
 


verder naar een oplossing
Is deze fout erg? Het hoeft geen probleem te zijn bij een gering aantal treinen op de baan welke overal in het zicht zijn. Er kan dan worden ingegrepen. Maar zodra het grootste gedeelte van de sporen verdekt is en er veel verkeer is op de baan, zal het tot ongelukken leiden bij geautomatiseerd treinverkeer simpelweg omdat de besturingssoftware niet ‘weet’ waar alle treinen zich bevinden.
Voor mijn modelbaan is deze fout zeker een probleem.

Ik heb met Digikeijs uitvoerig over het probleem gecommuniceerd, waarna een aantal controles zijn uitgevoerd. Digikeijs heeft ook een eigen centrale ter beschikking gesteld om te achterhalen of het probleem in mijn DR5000 zou kunnen liggen, maar ook bij de eigen centrale treedt de fout op.

In september 2021 heb ik bericht ontvangen van Digikeijs dat men het probleem heeft kunnen reproduceren. Dat is goed nieuws in die zin dat het niet aan mijn baan ligt, maar dat er een fout in het systeem zit. Een aantal voorgestelde testen (waaronder een aanpassing in de software) heb ik uitgevoerd, maar helaas heeft dat nog niet tot de oplossing gevoerd (november 2021).

antoni-a:
vervolg

Een volgende stap in december 2021 is een aanpassing in de hardware. Digikeijs heeft een DR5000 centrale, een DR5033 booster en aantal DR4088LN modules aangepast. Volgens een testreeks worden de aangepaste onderdelen geïmplementeerd teneinde de fout in de bezetmelding te achterhalen.

Eerst zijn de 'oude' instelbare voedingen van Digikeijs vervangen door de nieuwe 18V voedingen (voor h0) en is de 'oude' standaard centrale vervangen door de aangepaste DR5000 centrale. Deze aanpassingen blijken het probleem niet op te lossen.

Vervolgens zijn de DR4088LN vervangen door de aangepaste DR4088LN modules in combinatie met de 'oude' standaard DR5000 centrale. Ook deze configuratie lost het bezetmeldingsprobleem niet op.

antoni-a:
vervolg

Mijn bevindingen van de vorige testreeks heb ik doorgestuurd naar Digikeijs. In een daarop volgende eerste reactie heb ik het volgende advies gekregen:


--- Citaat ---UIt onze ervaring en dat geven we altijd mee aan onze klanten, is 0.5 op langere lengtes echt te dun.

Draaddiktes en lengtes
max. 15 cm 0,5 mm² AWG20
max. 1 m 0,75 mm² AWG18
max. 3 m 1,5 mm² AWG15
max. 6 m 2,5 mm² AWG13
max. 10 m 4 mm² AWG10-11
 
--- Einde van citaat ---

Dit betreft een advies voor de diameters van de draad tussen de terugmeldmodule (o.a. DR4088LN-cs) en de spoorstaaf! Het gaat hier niet over een voeding(ring)leiding.
Iedereen mag iets vinden van dit advies. Uiteraard dient het vermogensverlies in de draad binnen de perken te blijven, en dan is een grotere koperdiameter altijd beter dan een kleinere. Maar naar mijn mening is dit advies volstrekt overdreven.

Als we kijken naar de praktische uitvoerbaarheid is er ten eerste een probleem bij de modules zelf. Het is al moeilijk om een 0,5mm² met een adereindhuls in de klemschroefblokjes te bevestigen, laat staan grotere diameters. Ten tweede de bevestiging aan de spoorstaaf. Uiteraard kan een grotere diameter worden opgesplitst in meerdere kleine diameters, maar zijn we dan niet weer terug bij af?

Als de fout in de bezetmelding zou ontstaan door te kleine koperdiameters dan moet de fout terugkerend zijn in gelijke situaties. En dat is niet het geval. De door mij geconstateerde fout treedt af en toe op. Althans totdat ik de aangepaste modules toepaste, daarover later meer.

Onderstaande schermafdruk geeft een foutieve melding weer (afbeelding is gelijk aan bovenstaande). De door de DR5000 gemeten stroom door de gebruiker (BR50) is op het tijdstip van de melding 174mA.


De weerstand van een koperen draad met een diameter van 0,503mm² is per 100 meter 3,49Ω (https://www.circuitsonline.net/artikelen/view/27/2). Het vermogensverlies over de draad wordt berekend met Pv=I²*R.
Uitgaande van een afstand - tussen terugmeldmodule en spoorstaaf - van 4 meter bedraagt het vermogensverlies: 0,174² * (4/100) * 3,49 = 0,0042W. Dat dit vermogensverlies zou leiden tot de fout in de bezetmelding lijkt erg onwaarschijnlijk. Hierbij is de afstand van 4 meter een voorbeeld. In de praktijk is de fout ook opgetreden bij een draadlengte van 2 meter.

Volgend op het advies van de diameter voor de bedrading, stelde Digikeijs voor om alle oude standaard modules te vervangen door de aangepaste modules en betaversie 1.6.2 te installeren. Dat heb ik dan ook gedaan. Zowel voeding, centrale, booster en terugmeldmodules zijn vervangen. Het resultaat is een veelvoud van vreemde meldingen op de terugmeldmonitor. De aansturing van de locs is evenwel correct.
Met slechts twee locs op de baan 'ziet' de terugmeldmonitor opeens vier gebruikers. Een bezetmeldmodule geeft plotseling een bezetmelding (terecht) met het adres van een andere module.

Mijn verslag van een aantal testen staat hier: https://www.geuldalbaan.nl/modelbaan-nieuws#voorbeeld-test-DR4088LN-cs

Vooralsnog is de conclusie dat met de aangepaste modules het oorspronkelijke probleem niet wordt opgelost. Voor de duidelijkheid: het oorspronkelijke probleem is dat na de opstart soms (af en toe) een vinkje in de terugmeldmonitor ontbreekt als er vijf DR4088LN-cs in de keten zijn opgenomen, een fout die wordt opgeheven zodra de loc het volgende blok binnenrijdt.

Actuele ontwikkelingen bij De Geuldalbaan: https://www.geuldalbaan.nl/modelbaan-nieuws

Michel Bikkel:
Geeft zo niet veel vertrouwen dat er 1 zit bij Digikeijs die er verstand van heeft.
Inmiddels ben ik voor een groot deel over op Rosoft, ook goed betaalbaar en tot nu toe geen rare zaken.

antoni-a:
Mies,

Mijn insteek bij de aanschaf van Digikeijs was dat ik een product wilde waarbij ik alle onderdelen van één producent kon betrekken, zodat alles op elkaar afgestemd zou zijn. En, dat bij een eventuele hulpvraag ik geen maanden op een reactie moest wachten. Dat is dan ook wel gelukt.

Zelf ben ik niet thuis in de IT-materie. Maar met dit advies voor de diameters van een draadje kan ik me voorstellen dat er toch wel vraagtekens gezet mogen worden. Met deze toestand van proberen, controleren en rapporteren, ben ik nu ongeveer een jaar bezig. En ja, dan komt onvermijdelijk het moment waarop ik me afvraag: kan ik hiermee vooruit?

Navigatie

[0] Berichtenindex

[#] Volgende pagina

Naar de volledige versie