Digikeijs DR5000 Centrale, vragen en antwoorden

[TBBW]

Volgende,

Ik kwam in het dr5088rc manual de volgende schemas tegen:

In beide tekeningen heb ik een rode pijl bij de isolater van de “plus/rood”
Gezet. De isolatie in de tek. met de booster kan ik bevatten.
Twee verschillende power sources.
Echter de isolatie in de tek. met de twee 5088, zie ik niet.
Vraag is DEZE isolatie een MUST, om een foutloze operatie te garanderen?


Grtzz

[Karst Drenth]

Ja.

[TBBW]

Dank voor je antwoord, kun je een tipje ban de sluier oplichten waarom?

Grtzz

[henk]

Interessant. Is er ook een reden waarom de tweede pool van de versterker ook via de Digidetect wordt aangesloten Karst? Of is dat een optie die niet strikt noodzakelijk is?

[Bert_Apd]

Hallo,

Ik ben Karst dan wel niet, maar de reden daarvan is dat iedere DR5088RC de RailCom-afhandeling van en naar zijn "eigen baangedeelte" doet, zowel via de detectiegedeeltes als ook via de globale detector. Dit kan alleen maar functioneren wanneer de baangedeeltes onderling volledig gescheiden zijn.

Ter illustratie hier nogmaals de aansluitschema's met daarin in het paarse rechthoek aangegeven de "eigen baangedeeltes" per DR5088RC. De aansluitingen in de paarse rechthoeken zijn per DR5088RC volledig identiek, ongeacht of de voeding van de centrale of een booster/versterker komt.


     


     


Groeten,
Bert

[Karst Drenth]

Ha

Ik ben dan wel Karst maar had het niet beter kunnen verwoorden als dat Bert dat gedaan heeft


Kleine aanvulling: "...Dit kan alleen maar functioneren wanneer de baangedeeltes onderling volledig gescheiden zijn...." zou moeten zijn: "...Dit kan alleen maar goed en betrouwbaar functioneren wanneer de baangedeeltes onderling volledig gescheiden zijn...."

Waarom ? Ook dat heeft Bert al uitgelegd.

Voor de geinteresseerde Nerds alhier, een wat diepere uitleg:

Het "meten" van RailCom data gebeurt doordat de centrale/booster tijdens de z.g. "Cut Out" haar "J" en "K" aansluitingen intern kortsluit.
Eventueel aanwezige lok-/functie- decoders krijgen dan gelegenheid een stroompje in die kortgesloten "lus" te pompen. Dit piepkleine stroompje wordt door een RailCom detector "gezien" en verwerkt tot relevante data. Nu kun je ook zien waarom "alle" stroom door de DR5088 moet, zowel "heen" als "terug".  Een RailCom detector moet namelijk in de gesloten lus tussen lok-/functie- decoder en de centrale zitten.  Zou je nu werken met een "doorgaande K", dan kan het stroompje vanuit de decoder over meerdere detectoren verdeeld worden. Al naar gelang de weerstand die het op zijn pad vindt, kan het dus voorkomen, dat de "K" stroom niet meer langs de DR5088RC komt die het via 1 van zijn "J" uitgangen heeft uitgestuurd.

Overigens praten we hier over heeeeeel kleine signaaltjes: In de detector wordt het stroompje vanuit de decoder omgevormd tot een meetspanningkje van maar 18mV ( 0.018 V ) :O

Grtzz,
Karst

[TBBW]

Duidelijk verhaal, fijn dat jullie even de moeite hebben genomen om het te omschrijven!

Grtzz,

Gerwin

[erikkral]

Ik heb een vraag over het via LAN aansluiten van de DR5000 voor zowel Rocrail als JMRI.
Voor Rocrail heb ik het werkend door het protocol in te stellen op Loconet over TCP/IP Binary.
Nu wil ik ook aan de slag gaan met JMRI. JMRI geeft aan dat het protocol ingesteld moet worden op LocoNet over TCP/IP LBServer.
Dat zijn dus twee verschillende protocollen.

Is er een manier om Rocrail en JMRI werkend te krijgen met hetzelfde protocol via het LAN?
USB is geen handige optie voor mij.

Overigens loop ik weer vast met het beheerprogramma van de DR5000. Lukt me weer niet om het protocol aan te passen, ook al heb ik opnieuw het IP-adres (192.168.33.51) ingevoerd.

Deze centrale verdient echt betere software 

Groet,

Erik

[Karst Drenth]

Nee,

Deze software EN centrale verdienen een beter ingericht netwerk/PC/laptop...

10 tegen 1 dat óf je Antivirus óf je Firewall er voor zorgen dat de centrale niet door de software gevonden kan worden...


Oh... en met de huidige hardware is hetniet mogelijk meer dan 1 protokol tegelijk over LAN/WiFi te gebruiken.

[erikkral]

Hi Karst,

Dank voor je antwoord. Het beheerprogramma werkt weer nadat ik een netwerkconnectie had aangemaakt in de virtuele machine waarin de beheersoftware staat.
Doet voor mij echter niets af dat dit onduidelijk werkt en voor verbetering vatbaar is. Het is een beetje raar dat er op de machine waar de beheersoftware op draait een netwerkconnectie moet hebben om het beheerprogramma via USB te bedienen.
Enfin, die connectie is dus nodig maar er wordt ten tweede daar niets over gemeld in de handleiding en de beheersoftware merkt ook niet op dat er geen connectie aanwezig is.

Dat de hardware maar een protocol tegelijk kan afhandelen is prima, maar is het in JMRI en in Rocrail zo te configureren dat dit tegelijkertijd kan werken? Ik heb het internet afgezocht naar om JMRI en Rocrail via Loconet over TCP/IP Binary of allebei via Loconet over TCP/IP LBServer te laten werken. Tot dusver niets gevonden. Ben benieuwd naar hoe anderen dit doen.

[Karst Drenth]

ajb

Ja, het is raar, geef ik toe. Heeft alles te maken met de gebruikte WiFi/LAN module. De firmware daarvan kan niet aangepast worden, dwz alleen door de (chinese) fabrikant... en helaas is de configuratie niet "binnendoor" te bereiken ( zodat je via alleen USB kunt configureren. )

Of dit nog steeds in de handleiding staat weet ik niet (ik kan bij Digikeijs niet meer op de download-site komen  ) maar in mei 2019 stond dit er nog:



en de beheerssoftware meldt zich "luidkeels" met een "Ping" om aan te geven, dat het zoeken de is...


Je andere vraag: Ik denk het niet. JMRI ondersteund geen Binary, Rocrail geen LBSERVER (meer) ....


Grtzz,

Karst

[TBBW]

...... kan niet meer op de digikeijs site komen?

Maar Karst, jij bent toch digikeijs.
Of heb ik iets gemist.

Grtzzz

Gerwin

[Karst Drenth]

Maar Karst, jij bent toch digikeijs.

Nee Gerwin, dat ben ik niet en ook nooit geweest

Digikeijs heeft mijn ontwerpen geproduceerd en verkocht. 

Wel heb ik sinds september 2019 mijn samenwerking/medewerking met/aan Digikeijs beeindigd.


Groet,

Karst

[ruudns]

@Karst: Houd dat in dat er voor de DR5000 en andere géén firmware updates meer komen?

[Karst Drenth]

Ruud,

Dat kan en mag ik je op dit moment niet vertellen.