Hallo zusammen.

Ich hatte von Anfang an das Problem, dass meine DR4088-LN-CS Rückmeldungen nach einem Neustart im TC9 nur noch teilweise oder überhaupt nicht mehr da sind und dass ggf. Loconet nicht funktioniert. Ich muss dann bis zu drei Mal den Stecker des DR5097-Loconet-Hub ziehen und wieder einstecken, bis es geht.

Ich kenne den Artikel über LNEnableInterrogateUhlenbrock und auch den Hilfetext im TC, aber mein Uhlenbrock ist ja eine schwarze Z21. Ich habe das nie zum Fliegen gebracht, weiß auch nicht, wie ich Fehleranalyse betreiben könnte und weiß nicht, ob das bei mir funktionieren sollte oder nicht. Auch manuelles Senden des Schaltvorgangs an die Adresse 1017 über eine Taste im Gleisbild statt des Startmakros funktioniert nicht.

Hat jemand dieses Problem mit diesen Komponenten gehabt und gelöst? Was genau musste dazu gemacht werden? Wie könnte ich analysieren, warum das nicht funktioniert? Bisher kann ich ja nur in den Wald rufen, aber nicht erkennen, wo das versandet.

Vielen Dank für weitere Hinweise zu diesem Thema.

Schönes neues Jahr!

Möglicherweise besteht hier noch ein weiteres Problem:

Wenn nach dem Einschalten oder der Rückkehr vom Edit-Modus oder nach einem POM-Programmierschritt oder nach einer Programmiergleis-Programmierung TC keine Belegtmeldungen erkennt - was nicht immer der Fall ist, muss ich bis zu drei Mal den Loconet-s´Stecker ziehen, bis das wieder geht. Dann geht es wieder unbegrenzt lange.

Jedes Mal zeigt TC dann einen größeren Teil der Belegtmeldungen wieder an während in manchen Blöcken TC zwar weiß, was dort steht, aber die Belegtmeldung ist weg. Es sind aber nie alle. werden die gespeicherten Belegungen zu schnell gesendet und TC kann nicht folgen? Ist das Netzwerk - nicht WLAN - oder TC zu langsam? TC wird ja alle Meldungen nicht nur übernehmen, sondern vermutlich alle Bahnwärter prüfen für jede dieser Meldungen.

Hallo A-Zett,

Ich habe zwar keine Gerätschaften von dieser Firma, sondern 'nur' von Blücher und Uhlenbrock. Und natürlich noch loco-buffer.

Ich kann Dir zwar jetzt keine Lösungsmöglichkeiten anbieten, sondern nur Gedanken, die mir so gekommen sind.

Bei den Komponenten von Blücher und Uhlenbrock kenne ich diese Probleme zwar auch, aber nur so lange, wie man Murks bei der Verdrahtung und der Programmierung gemacht hatte.

Im Endeffekt haben wir alle Probleme beseitigen können.

Der Loconet Bus ist zwar einfach und sicher, er hat aber auch ein paar Einschränkungen und Eigenheiten, die man kennen muss.

Dazu muss man im groben wissen, wie der LocoNet Bus funktioniert.
Ein jeder Teilnehmer sendet seine Informationen immer ins gesamte Netz, nicht nur zur Zentrale. Alle Teilnehmer können senden als auch empfangen. Diese Informationspakete müssen nun hintereinander gesendet werden. Und da ist dann wohl auch der Flaschenhals zu suchen, wenn nun mehrere Teilnehmer mit Strom versorgt werden und dann anfangen ihre Infos zu senden. Ein Teilnehmer sendet nur dann, wenn kein anderer Teilnehmer sendet. Ein Teilnehmer versucht es aber auch nur eine gewisse Zeit, seine Infos los zu werden. Ist dieses Zeitfenster vorbei, sind die Infos verloren.

Dafür haben ( normalerweise ) die Rückmelder eine sogenannte Startupzeit, soll heißen, erst nach dieser Zeit fangen sie an, ihre Infos zu senden. Uhlenbrock hat nur eine Startupzeit, beim Blücher kann man sogar für jede Aktion eine Startupzeit einstellen, z.B. nachdem das Modul mit Strom versorgt wurde, wenn der Bus Strom hat, wenn eine entsprechende Aufforderung ( = SIC = Interrogate ) kommt.
Auch die Magnetartikeladresse ( meist ist die 1017 voreingestellt ), die eine Aufforderung auslöst, kann eingestellt werden.

Ich habe mir mal die BA Deiner Module angesehen und dahingehend nichts gefunden.
Ich befürchte, die können das alles nicht und das könnte dann wohl das Verhalten bei Dir erklären.

Was kann man da nun tun ?
Meine Gedanken würden dahin gehen, daß man testet, mit wie vielen Modulen es funktioniert und man dann entsprechende Gruppen bildet, die der Reihe nach zugeschaltet werden.

MfG Oliver

Vielen Dank Oliver. Habe ich da ein Missverständnis? Ich dachte bisher, die Zentrale speichert den aufgelaufenen Belegzustand und sie ist es, die aufgefordert wird, ihn erneut zu senden.

Wenn die DR4088 auf 1017 überhaupt reagieren und nicht alle durchkommen, würden sie dann den Stand der Z21 nicht verschlechtern.

Ob die Z21 reagieren kann und ob sie reagiert, kann ich nicht sagen. Die Hilfe von TC bezieht sich ja wohl auf Uhlenbrock und die Z21 muss ja als eine Uhlenbrock-Zentrale eingerichtet werden, da TC Z21 als eigenen Typ von Zentrale nicht kennt.

Oliver, Du scheinst Recht zu haben.

Wenn ich weiter hinten in einer vom Hub abgehenden Kette den Stecker ziehe und wieder einstecke und nicht den Stecker zwischen Zentrale und Hub werden alle Meldungen hinter dieser Stelle aufgefrischt. Es sind also zu viele.

Die Frage, ob die Zentrale sie nicht alle kennen und auf 1017 hin übertragen müsste, ist davon unberührt. Die Tatsache, dass ohne Auffrischen überhaupt keine Meldungen mehr im TC ankommen auch nicht.

Das läuft ja darauf hinaus, die Ketten am Hub so zu verkürzen, dass eine Kette vollständig aktivierbar ist und dann mit den Messplatinen oder aufgetrennten LN-Kabeln Unterbrechungsstellen für jede Kette zu schaffen, die über Relais automatisiert im Startmakro aus und wieder zugeschaltet werden.

Ich habe eine solche Lösung noch nie irgendwo gelesen. Sowas scheint keiner zu machen. Muss das echt so laufen???

Hallo A-Zett,

#Habe ich da ein Missverständnis? Ich dachte bisher, die Zentrale speichert den aufgelaufenen Belegzustand und sie ist es, die aufgefordert wird, ihn erneut zu senden.
×Mag sein, daß Zentralen, die eine Anzeigemöglichkeit haben, was speichern. Aber die Befehle wie SIC und MA1017 gehen direkt an die Rückmeldemodule.

#Wenn die DR4088 auf 1017 überhaupt reagieren und nicht alle durchkommen, würden sie dann den Stand der Z21 nicht verschlechtern.
×Kann aber auch gut sein,daß das Ergebnis gleich schlecht bleibt.

#Ob die Z21 reagieren kann und ob sie reagiert, kann ich nicht sagen.
×Wenn damit SIC und MA1017 gemeint sind, dann glaube ich eher nicht.

#Die Hilfe von TC bezieht sich ja wohl auf Uhlenbrock und die Z21 muss ja als eine Uhlenbrock-Zentrale eingerichtet werden, da TC Z21 als eigenen Typ von Zentrale nicht kennt.
×??? Ich hatte schon mal eine z21 und eine Z21 bei TC eingerichtet. Ich meine mich zu erinnern, daß die auch als z/Z21 eingerichtet werden und nur, wenn man bei der Z21 Loconet benötigt, muss als zusätzliches Digitalsystem Loconet eingerichtet werden.
Loconet und Intellibox sind zwar die gleiche Datensprache, aber bei LN werden die Rückmelder im Eingabereiter in 16er Gruppen eingetragen und bei IB als fortlaufende Nummer.

#Die Frage, ob die Zentrale sie nicht alle kennen und auf 1017 hin übertragen müsste, ist davon unberührt.
×S.o.

#Die Tatsache, dass ohne Auffrischen überhaupt keine Meldungen mehr im TC ankommen auch nicht.
×Zumindest Steuergeräte funktionieren erst, wenn sie sich bei der Zentrale "angemeldet" haben und z.B. eine Slotabfrage gemacht haben, ohne die sie keinen Zugriff auf eine Lok hätten.
Rückmelder fragen keine Slots ab, aber ob sie sich in irgendeiner Art anmelden - auch wenn es nur eine Art von Anwesenheitsbestätigung ist - weiß ich jetzt aber auch nicht. Den der das definitiv weiß, habe ich im letzten Jahr genau einmal getroffen. Jemanden, der das vielleicht weiß, treffe ich warscheinlich erst in 2 Wochen. Aber das ist ja jetzt nicht unbedingt entscheidungsrelevant.

#Das läuft ja darauf hinaus, die Ketten am Hub so zu verkürzen, dass eine Kette vollständig aktivierbar ist und dann mit den Messplatinen oder aufgetrennten LN-Kabeln Unterbrechungsstellen für jede Kette zu schaffen, die über Relais automatisiert im Startmakro aus und wieder zugeschaltet werden.
×Ich würde da dann aber die Plusseite unterbrechen, damit die Loconet Datenpakete nicht mit durchs Messgerät bzw. den Relaiskontakt müssen.
Auch würde ich monostabile Relais nehmen, die dann über eine 'Selbsthaltung' angezogen bleiben. Die fallen dann nach Ausschalten des Stroms von alleine ab und sind nach dem Einschalten dann ja immer noch aus, um erst nachdem alles hochgefahren ist, durch ein Makro peu a peu eingeschaltet zu werden.

#Ich habe eine solche Lösung noch nie irgendwo gelesen. Sowas scheint keiner zu machen. Muss das echt so laufen???
×Ich kann jetzt nur vermuten, daß dieses Problem noch nicht so oft aufgetreten ist. Zum einen werden nicht viele so große Anlagen haben, so daß so viele LocoNet Rückmelder zusammen kommen. Und andere hingegen werden das vielleicht schweigend hinnehmen und irgendwie damit leben.

Und dann ist es ja auch noch so, daß die LocoNet Rückmeldemodule genau dieses Herstellers einen weiteren S88 Eingang haben, und daß wenn weitere S88 Rückmelder dahinter hängen, dieses Problem vielleicht erst gar nicht auftritt, da ja dann vielleicht für alle Rückmelder in dieser Reihe nur eine Datenpaket zurück geschickt werden muss. Und dann wird es ja wohl kaum Datenpaketkollisionen geben.

MfG Oliver

Jetzt habe ich zum ersten Mal verstanden, warum man das mit den S88 überhaupt macht. Deswegen habe ich das nämlich nicht gemacht.

Monostabile Relais funktionieren nur beim Einschalten. Das muss der Startmakro aber auch machen

• Nach einem Kurzschluss oder Not-Aus
• Nach der Rückkehr aus dem Edit-Mode
• Nach einer Programmierung (Programmiergleis und POM)

Hallo A-Zett,

Zitat von a-zett im Beitrag #7

---

Jetzt habe ich zum ersten Mal verstanden, warum man das mit den S88 überhaupt macht. Deswegen habe ich das nämlich nicht gemacht.

---

Zitat von a-zett im Beitrag #7

---

Monostabile Relais funktionieren nur beim Einschalten. Das muss der Startmakro aber auch machen

• Nach einem Kurzschluss oder Not-Aus
• Nach der Rückkehr aus dem Edit-Mode
• Nach einer Programmierung (Programmiergleis und POM)

---

Hallo,

ich gehöre zu denen, die das Problem auch betrifft, aber bislang (noch) nichts unternommen haben.

Ich habe eine YaMoRC-Zentrale (ex digikeijs DR5000) und inzwischen am LocoNet 5 Booster, 8 Rückmelde-Module DR4088LN-OPTO und 2 Module DR4088LN-CS (je 16 Kanäle) und ein Kehrschleifenmodul DR5013, dass ebenfalls über LocoNet Belegtmeldungen abgibt. Ohne das genauer geprüft zu haben, habe ich nicht das Gefühl, dass ganze Module nach dem Einschalten nicht senden, sondern beliebig Kanäle zwischendurch ausfallen. Dem werde ich aber nochmal nachgehen.

Was mich wundert ist, dass noch kein LocoNet-Spezialist sich der Sache angenommen hat. Es gibt doch eigentlich nur die Möglichkeit, dass im Protokoll eine Schwachstelle vorliegt und nicht alle Meldungen gesendet oder dass die Zentralen überlastet sind und eingehende Meldungen zwischendurch ignorieren. Für beides müsste es aber doch technische Lösungen geben....

Lasst uns das Thema ein bisschen weiter köcheln!

Viele Grüße

Wolfgang

Hi,

Ich wuerde beim Design eines computergesteuerten digitalen Modellbahnbetriebes darauf achten dass die Kombination Modellbahnzentrale und Bussystem zwischen Zentrale und schaltenden oder rueckmeldenden Modulen vom Hersteller der Steuerungssoftware offiziell unterstuetzt ist.
TC schreibt auf seiner Webseite https://www.freiwald.com/forum/viewtopic.php?t=6264

…Falls in unserer Dokumentation nicht ausdrücklich anderes angegeben ist, darf die Digitalzentrale eines Herstellers nur mit Interfaces desselben Herstellers an den Computer angeschlossen werden.
Die einzigen Ausnahmen hiervon sind:
Digitrax LocoNet darf auch mit dem LocoBuffer-Interface an den PC angeschlossen werden. Im LocoNet dürfen auch Geräte betrieben werden, die nicht von Digitrax stammen, sofern diese Geräte sich vollständig an den von Digitrax festgelegten LocoNet-Standard halten.

Im vorliegenden Fall werden die Loconet basierenden Rueckmelder offensichtlich nicht ueber einen Locobuffer an den TC-PC angeschlossen. Sind die DRxxxx Module 100% Digitrax kompatibel ?

…

Zitat von ohawd im Beitrag #9

---

Was mich wundert ist, dass noch kein LocoNet-Spezialist sich der Sache angenommen hat.

---

Zitat von ohawd im Beitrag #9

---

Es gibt doch eigentlich nur die Möglichkeit, dass im Protokoll eine Schwachstelle vorliegt und nicht alle Meldungen gesendet oder dass die Zentralen überlastet sind und eingehende Meldungen zwischendurch ignorieren.
Für beides müsste es aber doch technische Lösungen geben....

---

Zitat von ohawd im Beitrag #9

---

Lasst uns das Thema ein bisschen weiter köcheln!

---

Zitat von brettsh im Beitrag #10

---

Hi,
Im vorliegenden Fall werden die Loconet basierenden Rueckmelder offensichtlich nicht ueber einen Locobuffer an den TC-PC angeschlossen. Sind die DRxxxx Module 100% Digitrax kompatibel ?
…

---

Hallo Karst,

22 neue Module zu kaufen ist keine Option. Ich habe nicht im Lotto gewonnen.

Ich hatte ja bereits die Idee diskutiert, das Loconet ab dem Hub in mehreren Schritten zuzuschalten (den Plus abschalten und per Startmakro mit Pausen zuschalten). Würde das helfen?

Zitat von a-zett im Beitrag #12

---

Zitat von brettsh im Beitrag #10

---

Hi,
Im vorliegenden Fall werden die Loconet basierenden Rueckmelder offensichtlich nicht ueber einen Locobuffer an den TC-PC angeschlossen. Sind die DRxxxx Module 100% Digitrax kompatibel ?
…

---

Hallo Helmut,

ich denke, ob Loconet Loconet ist oder nicht ganz kann fast kein Käufer beantworten. Ich jedenfalls nicht. Es steht drauf, kann stimmen oder auch nicht.

Was ist ein Loconet-Buffer-Interface? Kann man das einzeln kaufen und zwischenschalten?

---

Hallo zusammen

Zitat von Karst Drenth im Beitrag #11

---

. . . .
Ja, es gibt eine ziemliche Schwachstelle im LocoNet. Und das heisst "Kollisions-Vorbeugung". Wenn z.B. ein Melder melden möchte, muss der warten bis der Bus frei ist. Bei regem Verkehr, wie es auftritt beim Starten einer Anlage, wenn alle RM ihren Stand melden wollen, kommt es schnell zu was man im Englischen "Contention" nennt. Auf Deutsch: Es dauert so lange bis der Bus frei wird, dass ein oder mehere Module das warten aufgibt/aufgeben. ( Wie in den Specs vorgeschrieben... )

---

Zitat

---

Und dazu kommen noch zwei DR4088LN spezifische Probleme:

1. Durch eine ändereung in der Komponentenbeschaffung, sind seit etwa 2018 bestimmte Bauteile mit Spezifikationen die ausserhalb des Entwurfbereichs fallen, verbaut worden. Die Folge ist, dass unzurecht Kollisionen detectiert werden bei viele Module am Bus. Normal liegt so eine Grnze irgendwo zwischen 25 und 45. Durch diesen Petzer ist das runter zu 10-12...

2. als Folge des unzurechtes detektieren kommt die Firmware in einen Stand, der einen Bug ( von mir programmiert ) hat. Folge: Die FW des 4088LN zieht die LocoNet Signalleitung nach Masse und lässt bis Auschalten nicht mehr los...

---

Letzteres ist ja besonders schräg, da der Bus ja praktisch tot ist, wenn er gegen Masse gezogen wird.

Zitat von a-zett im Beitrag #12

---

Was ist ein Loconet-Buffer-Interface? Kann man das einzeln kaufen und zwischenschalten?

---

Hallo Oliver,

wenn ich jetzt für mich nach Lösungen suche, ergibt sich folgendes Bild:

1. Das RR-nextGeneration ist nur "halbherzig", weil z. B. keine externe Spannungsquelle.
2. Das Digitrax PR4 ist zu teuer und eigentlich "overdressed", weil es auch andere Dinge erledigen soll, als nur das LocoNet vernünftig steuern.
3. Ein Uhlenbrock USB-Loconetinterface 63130 habe ich sogar und könnte es probieren. Ich habe aber Zweifel, ob das wirklich hilft.
4. Das LN-ES/VT von Blücher scheint tatsächlich das beste Angebot gewesen zu sein. Es wird ja nicht mehr hergestellt. Andererseits ist es ja wohl nicht sehr komplex gewesen. Wirft die Frage auf, ob man die Schaltung findet und es DIY nachbauen kann?

Mit anderen Worten: eine fertige Lösung gibt es nicht. Zumindest nicht, wenn man nicht alle vorhandenen Module entsorgen will.

Was wäre ein workaround?

Da ist der Vorschlag, die RailSync-Spannung an den Rückmelder zeitversetzt einzuschalten. Geht das tatsächlich? Dies von einer Zentrale / einem PC aus zu steuern erforderte wieder einen zusätzlichen Verkabelungsaufwand. Also ein einstellbares Zeitglied in die LocoNet RailSync-Leitung einbauen - gespeist aus RailSync? Hat das schon jemand probiert?

Viele Grüße

Wolfgang

Zitat von brettsh im Beitrag #14

---

Aber der Locobuffer als von TC offiziell unterstuetzte Schnittstelle zum Loconet loest ja nicht das offensichtlich Grundlegende Problem dass die DRxxxx Rueckmelder sich offensichtlich nicht Loconet Protokoll konform verhalten wenn sie bei hohem traffic auf dem Loconet nicht die im Protokoll spezifizierte Mindestanzahl an retrys generieren…

---

Hallo zusammen,

Zitat von ohawd im Beitrag #16

---

1. Das RR-nextGeneration ist nur "halbherzig", weil z. B. keine externe Spannungsquelle.
2. Das Digitrax PR4 ist zu teuer und eigentlich "overdressed", weil es auch andere Dinge erledigen soll, als nur das LocoNet vernünftig steuern.
3. Ein Uhlenbrock USB-Loconetinterface 63130 habe ich sogar und könnte es probieren. Ich habe aber Zweifel, ob das wirklich hilft.
4. Das LN-ES/VT von Blücher scheint tatsächlich das beste Angebot gewesen zu sein. Es wird ja nicht mehr hergestellt. Andererseits ist es ja wohl nicht sehr komplex gewesen. Wirft die Frage auf, ob man die Schaltung findet und es DIY nachbauen kann?

---

Zitat

---

. . . der Vorschlag, die RailSync-Spannung an den Rückmelder zeitversetzt einzuschalten. Geht das tatsächlich? Dies von einer Zentrale / einem PC aus zu steuern erforderte wieder einen zusätzlichen Verkabelungsaufwand. Also ein einstellbares Zeitglied in die LocoNet RailSync-Leitung einbauen - gespeist aus RailSync? Hat das schon jemand probiert?

---

Ich wüsste nicht. Bis jetzt bestand dahingehend ja auch noch keine Notwendigkeit. Die Probleme treten ja auch nur bei den Digidingsbumsdingern auf, und das auch nur, wenn es zu viele werden.

Bei Loconet T liegt ja auch kein Railsync an und da dürfte es eigentlich unproblematisch sein die Versorgungsspannung später einzuschalten.

Und ein Zeitglied würde a-zett da auch nicht wirklich helfen, da das ja nur beim Einschalten der Busspannung wirken würde.
Und da er diese Probleme auch hat nachdem er aus dem Programmier- und Editiermodus kommt, wird er um die Relais Lösung nicht herum kommen. ( Ausser er gewinnt im Lotto. )

Zitat von a-zett im Beitrag #17

---

Ich dachte immer, die Z21 puffert den Belegtzustand. wenn es TC schon nicht tut. Wenn sie das nun eben doch nicht tut und es nun einen extra Buffer gibt, sollte doch mindestens der das tun, Das bedeutet, wer auch immer puffert, sollte doch seinen gepufferten Belegtzustand so lange bereithalten und beim Einschalten und auf 1017-Request auch bereitstellen, bis er etwas Neues empfangen hat. Also immer dann, wenn ein Modul nach zu vielen Kollisionen auf dem Bus vorzeitig aufgibt. Würde ein Puffer das nicht leisten, wüsste ich nicht, wozu ich den brauche.

---

Alles richtig Oliver bis auf den Umstand, dass die Überlastung des Ausgangs bisher folgenlos und behebbar ist und diese Threads mir erklärt haben, wie. Und dass das System nach ein bis drei Mal Stecker ziehen funktioniert hat bis zum nächsten Ausschalten/Programmieren/Editieren. Jetzt funktioniert die Handsteuerung nicht mehr, was dringend eine Lösung für ein Problem erfordert, das ich nicht hätte schaffen müssen. Das System funktioniert zum Glück immer noch. Auf noch mehr Rückmelder habe ich ja verzichtet, wie ich in der Rubrik Kleine Spuren zum Güterbahnhof Rixdorf berichtet habe. Damit es so bleibt.

Güterbahnhof Rixdorf: Servos von Digikeijs für Z-Weichen von Weichen-Walter?

Im Thread

Platz da

hatte ich gezeigt, wie das normalerweise aussieht.

Hallo,

ich habe jetzt mal ausgiebig getestet. Wenn ich meine Booster (ich habe vier auf der Anlage) zeitversetzt einschalte, ist alles OK. Das löst aber zwei Probleme nicht:

1. Ich muss daran denken, vor dem Abschalten der Anlage die Booster auszuschalten und vor allem
2. Bei einem STOP (Abschalten) der Gleisspannung und wieder Einschalten, bleibt das Problem bestehen.

Ich suche jetzt nach einer Lösung, wie ich beides mit meiner Software (iTrain) lösen kann.

Am besten wäre aber tatsächlich eine Hardware-Lösung. An jedem Rückmeldemodul müsste am LocoNet-Eingang ein Zeitglied die Durchleitung des RailSync- Signals (12 V DC) verzögern. Ich habe dazu mal quick-and-dirty eine Schaltung gezeichnet. Wobei das Zeitglied von dieser Quelle stammt: http://www.dieelektronikerseite.de/Circu...tverzoegert.htm. Alles andere scheint mir eher trivial.



Ich bin aber als Hobby-Elektroniker nicht in der Lage, den Plan auf Tauglichkeit zu prüfen. Vor allem aber würde ich das Relais gerne durch ein MOSFET ? ersetzen. Geht das und wenn ja wie?

Spezialisten sind gefragt :-)

Viele Grüße

Wolfgang

Also das wäre eventuell eine Lösung Wolfgang

Was mir gerade einFällt, ist das man sowas vielleicht in einem Digikeijs LocoNet Hub einbauen kann. Und das sogar mehrfach.

Man neheme dann z.B. eine Buchse als "Master-Eingang" und die restlichen 7 Stück als "Slave Ausgange"

Jeder Slave Ausgang bekäme dann so eine Schaltung. Und Ja, das geht auch mit MOSFETs wenn man der Eingang dieses HUBs am LocoNet T hängt.

Wenn man an jedem Ausgang dann einen Strang von maximal 5 DR4088LN anschliesst, müsste das bestimmt klappen.

Gruss,
Karst

P.S. Wenn es Belangstellung dafür gibt, könnte ich sogar ein YaMoRC Modul/Produkt drauss machen.

Hallo a-zett,
Wenn ich 4088xx Anleitung Seite 6 richtig interpretiere kann man doch die Startup Zeit verändern, wenn sich die Module nacheinander melden wird doch Datenmenge reduziert, hat bei meinen Uhlenbrock Modulen geholfen, . Es gab im Tool bei der Einstellung der Modulanzahl unten die Möglichkeit eine Startzeit eingeben.

Mit freundlichen Grüßen
Karl

Hallo Karl, auf meiner Seite 6 steht sowas nicht. Das Wort Start kommt im Dokument nur im Zusammenhang mit Startadresse vor. Der Support hat auch nichts dergleichen erwähnt. Wo genau hast du das denn her? DR4088 hat doch auch keine CVs...

Hallo A-Zett,
Ich habe vor ca. einem Jahr einem Bekannten bei der Einrichtung derDR 5000 unterstützt, ,da konnte man mit der Software die Startverzögerung einstellen, kann ich jetzt nicht überprüfen, da ich keine DK Produkte nutze.
Herzliche Grüße Karl

Hallo zusammen,

Zitat von Karl53 im Beitrag #22

---

Wenn ich 4088xx Anleitung Seite 6 richtig interpretiere kann man doch die Startup Zeit verändern, wenn sich die Module nacheinander melden wird doch Datenmenge reduziert, hat bei meinen Uhlenbrock Modulen geholfen.

---