Hallo allerseits,

die Bedienungsanleitung des L.net converters behauptet vollmundig, dass "Lok- und Weichenkommandos von der ECoS selbstverständlich umgesetzt werden".
In einem Selbstversuch war ich aber nicht in der Lage die Kombination aus Ecos 2 (Software 4.2.4), L.net converter und Uhlenbrockk MARCo-Empfänger (Artikel-Nr. 68510) zum Laufen zu bringen. Weder wurden die Voreingestellten Kommandos umgesetzt, noch war ich in der Lage den MARCo-Empfänger zu programmieren. Wenn ich die entsprechende Artikel-Nr. und Modul-Nr. auf der Ecos eingebe, geht der MARCo-Empfänger in den Programmiermodus (LED blinkt), auf der Ecos steht aber weiterhin "Kein Modul erkannt".

Hat jemand hier schon erfolgreich einen MARCo-Empfänger an einem L.net converter zum Laufen gebracht?

Gruß, Enrico

Hallo Enrico,

schau einmal hier: viewtopic.php?p=1922325#p1922325

Im genannten Beitrag hatte ich bereits erwähnt, dass Lissy und Marco mit der Ecos nicht funktionieren. So steht's in der Anleitung zum L.net Converter.
L.net und LocoNet sind hier leider nicht 100% kompatibel.

Hallo Hans,

den Abschnitt in der Anleitung des L.net converters habe ich gelesen. Der Text in Anführungszeichen in meinem ersten Posting ist tatsächlich ein Zítat aus diesem Abschnitt.
Der ganze Absatz lautet wie folgt:
"Adress-Rückmelder (z.B. Uhlenbrock Marco® oder Lissy® werden derzeit nicht vollständig unterstützt: Während die Lok- und Weichenkommandos von der ECoS selbstverständlich umgesetzt werden, kann die Adressrückmeldung nicht von der ECoS erkannt werden. Aufgrund der hardwareseitigen Realisierung dieser Geräte empfehlen wir deren Einsatz nicht."

Das es nicht 100% funktioniert ist mir also bewusst. Bei mir funktioniert es aber 0% und das ist definitiv weniger als die Anleitung verspricht.

Gruß, Enrico

Hallo,

Zitat

---

"Adress-Rückmelder (z.B. Uhlenbrock Marco® oder Lissy® werden derzeit nicht vollständig unterstützt: Während die Lok- und Weichenkommandos von der ECoS selbstverständlich umgesetzt werden, kann die Adressrückmeldung nicht von der ECoS erkannt werden. Aufgrund der hardwareseitigen Realisierung dieser Geräte empfehlen wir deren Einsatz nicht."

Das es nicht 100% funktioniert ist mir also bewusst. Bei mir funktioniert es aber 0% und das ist definitiv weniger als die Anleitung verspricht.

---

Ich habe leider keinen L-Net Konverter.

Werden denn ganz normale LocoNet Belegtmeldungen wie vom 63340 korrekt an die ECoS weitergegeben?

MfG

vik

Hallo vik,

ich habe leider nur den einen MARCo-Empfänger zum ausprobieren bestellt.

Gruß, Enrico

Hi zusammen,

Ratet mal, warum das Ding auch „nur“ L-Net Anschluss heißt.


Richtig, weil es eben kein LocoNet ist, und auch nicht vom Rechteinhaber (Digitrax) lizensiert ist.



Viele Grüße, Michael

Moin,
ich habe mal den ESU L.net converter für die Implementierung einen Loconet-zertifizierten Funkhandreglers untersucht.
Dabei habe ich festgestellt, dass beim Lokfahren die Funktionen über F12 (also ab F13) nicht brauchbar anwendbar sind (hier weist die ESU-Implementierung Fehler auf). Das Schalten von Weichen ging, Programmieren ging weder via PoM noch über das Programmiergleis.
Rückmeldung habe ich nicht untersucht, weil der Funkhandregler nicht rückmeldet.

Insgesamt sollte man bei diesem Bauteil der Bezeichnung "L.net converter" Glauben schenken, weil L.net ist nicht LocoNet (tut vielleicht in geringen Umfang so als ob).

Mir ist bislang keine korrekte Lösung bekannt, um Loconet an / mit der ECoS zu betreiben.

Ich bitte auch zu bedenken, dass Uhlenbrock kein "korrektes" LocoNet (wie der Hersteller Digitrax) verwendet sondern die eine oder andere herstellerspezifische Abänderung eingebaut hat (sieht man schön im Vergleich IB1 und IB2). Daher wäre bei Uhlenbrockprodukten ihrerseits zu prüfen, wie weit sie mit einem loconet-zertifizierten Gerät (oder einem von Digitrax) zusammenarbeiten (können).

Schöne Grüße
Johannes

Hallo Johannes,

Zitat

---

Ich bitte auch zu bedenken, dass Uhlenbrock kein "korrektes" LocoNet (wie der Hersteller Digitrax) verwendet

---

es sind wohl Implementierungen, die über die LocoNet® Personal Use Edition 1.0 (SPECIFICATION: Digitrax Inc ...)
http://www.digitrax.com/static/apps/cms/...onaledition.pdf
hinaus gehen, aber woran kann man erkennen, dass das inkorrekt ist?
[quote=Pirat-Kapitan]
sondern die eine oder andere herstellerspezifische Abänderung eingebaut hat (sieht man schön im Vergleich IB1 und IB2).
[/quote]
Kannst Du an Beispielen erläutern, was Du genau meinst? Hört sich so an, als wäre die IB1 noch weitgehend spezifikationskonform, die IB2 aber nicht mehr - oder umgekehrt.

MfG

vik

Zitat

---

Hallo Johannes,

Zitat

---

Ich bitte auch zu bedenken, dass Uhlenbrock kein "korrektes" LocoNet (wie der Hersteller Digitrax) verwendet

---

es sind wohl Implementierungen, die über die LocoNet® Personal Use Edition 1.0 (SPECIFICATION: Digitrax Inc ...)
http://www.digitrax.com/static/apps/cms/...onaledition.pdf
hinaus gehen, aber woran kann man erkennen, dass das inkorrekt ist?
[quote=Pirat-Kapitan]
sondern die eine oder andere herstellerspezifische Abänderung eingebaut hat (sieht man schön im Vergleich IB1 und IB2).

---

Kannst Du an Beispielen erläutern, was Du genau meinst? Hört sich so an, als wäre die IB1 noch weitgehend spezifikationskonform, die IB2 aber nicht mehr - oder umgekehrt.

MfG

vik
[/quote]

Hallo,

genau das interessiert mich auch. Uhlenbrock war (und ist?) leider in D die einzige Firma, die konsequent genug war, Digitrax Lizenzgebühren zu zahlen. Auch zweifel ich an, dass die so hoch sind, dass die anderen Firmen meinen, durch Reengineering das Procedere umgehen zu können. Wohin das dann führt, sieht man am L.Net-Converter mal wieder deutlich. Der Kunde zahlt die Zeche (so oder so).

Im Zusammenspiel zwischen der Ecos und diesem Converter funktionieren div. LocoNet-Handregler gut, aber UBs Marco eben nicht.

@Enrico:
Marco detektiert über die RailCom Erkennung/Rückmeldung in seinen Bereich befindliche Lok- und Funktionsdecoder und übernimmt dann ihm zugeordnete Aufgaben zum Schalten etc.. Da lt. Bedienungsanleitung des L.Net-Converters aber RailCom abgeschaltet werden muß, kann das folglich auch nicht funktionieren. Da hast du dir zum Testen leider die falsche Kombination ausgesucht.

Hallo Hans,

Zitat

---

Marco detektiert über die RailCom Erkennung/Rückmeldung in seinen Bereich befindliche Lok- und Funktionsdecoder und übernimmt dann ihm zugeordnete Aufgaben zum Schalten etc.. Da lt. Bedienungsanleitung des L.Net-Converters aber RailCom abgeschaltet werden muß, kann das folglich auch nicht funktionieren. Da hast du dir zum Testen leider die falsche Kombination ausgesucht.

---

Da würde ich widerspechen. In der BA des L.net converters steht:
"Viele für das LocoNet™ entworfene Rückmeldebausteine funktionieren nicht mehr richtig, wenn RailCom® aktiviert ist: Die erforderliche Austastlücke im Gleissignal verwirrt diese Bausteine, was zu falschen oder „Geister“-Rückmeldungen führen kann. Sie müssen sich dann entscheiden, entweder die Rückmelder zu ersetzen (z.B. durch ESU ECoSDetectoren) oder RailCom® abzuschalten."


RailCom ist demnach kein grundsätzliches Problem für den Converter, sondern nur für viele Loconet-Rückmelder. Da dürfte der Marco-Empfänger aber kaum dazu zählen.

Gruß, Enrico

Hallo Enrico,

Zitat

---

In der BA des L.net converters steht:
"Viele für das LocoNet™ entworfene Rückmeldebausteine funktionieren nicht mehr richtig, wenn RailCom® aktiviert ist: Die erforderliche Austastlücke im Gleissignal verwirrt diese Bausteine, was zu falschen oder „Geister“-Rückmeldungen führen kann. Sie müssen sich dann entscheiden, entweder die Rückmelder zu ersetzen (z.B. durch ESU ECoSDetectoren) oder RailCom® abzuschalten."


RailCom ist demnach kein grundsätzliches Problem für den Converter, sondern nur für viele Loconet-Rückmelder. Da dürfte der Marco-Empfänger aber kaum dazu zählen.

---

Das klingt verwirrend, aber nicht wirklich überzeugend. Natürlich ist es für ESU immer gut, wenn man Rückmelder von ESU kauft.

Welchen Einfluss könnte die knapp eine halbe Millisekunde lange Lücke im Gleis auf das LocoNet-Signal haben?

MfG

vik

Zitat

---

Welchen Einfluss könnte die knapp eine halbe Millisekunde lange Lücke im Gleis auf das LocoNet-Signal haben?

---

Ich vermute die Stromfühler in den Rückmeldern haben ein Problem mit der über "längere Zeit" abgesenkten Spannung im Gleis, nicht das Loconet. Andererseits braucht das Loconet gemäß der BA auch eine Masseverbindung zur Schiene, damit die Rückmeldung winwandfrei funktioniert (unabhängig von RailCom). Das ist auch nicht wirklich nachvollziehbar.

Gruß, Enrico

Hallo Enrico,

da magst du mir widersprechen, aber überzeugen kannst du mich damit nicht. Ich beziehe mich mal auf das ESU Handbuch zum Converter. Da steht auf Seite 3:

"3.3. Rückmelder
LocoNet™ Rückmeldemodule zur Gleisbesetztmeldung können
weiterbenutzt werden. In der ECoS verwenden Sie die Kontakte
beliebig zum Auslösen von Fahrwegen oder Pendelzügen.
Adress-Rückmelder (z.B. Uhlenbrock Marco® oder Lissy® wer-
den derzeit nicht vollständig unterstützt: Während die Lok- und
Weichenkommandos von der ECoS selbstverständlich umgesetzt
werden, kann die Adressrückmeldung nicht von der ECoS erkannt
werden. Aufgrund der hardwareseitigen Realisierung dieser Gerä-
te empfehlen wir deren Einsatz nicht."

Insbesondere erwähnt sind hier eben Marco und Lissy von UB, die nicht vollständig unterstützt werden. Auch rät ESU ausdrücklich von deren Einsatz ab. Auf Seite 4 kommt dann der von dir zitierte Passus und auf Seite 5 schließlich noch folgender Hinweis zu UB:

"Sollen LocoNet™ Rückmelder von Uhlenbrock® zum Einsatz
kommen, muss eine Verbindung vom Masseanschluss g) des
L.Net converters zur Gleismasse (ECoS Gleisausgang „0“, vgl.
ECoS Handbuch Kapitel 8.3.1. bzw. 8.3.2) hergestellt werden."

Ob du das jetzt wahr haben willst oder auch nicht, überlasse ich gerne dir. Im Zweifel solltest du dich dann vielleicht direkt an ESU wenden. Mehr kann ich zum Thema ESU nicht beitragen. Da bin ich raus, denn meine Konfiguration besteht aus IB2, Marco und LocoNet, und die vertragen sich sehr gut.

Sorry Hans, aber ich kann deiner Argumentation nicht folgen. Zumindest verstehe ich nicht, was du im Bezug auf das Thema dieses Threads sagen möchtest. Die meisten dieser Passagen habe ich hier im Thread selbst bereits gepostet. Keine davon besagt, dass der L.net converter grundsätzlich inkompatibel zu RailCom ist und in einer wird explizit behauptet, dass die ECoS mit dem L-net converter "selbstverständlich" fähig ist Kommandos von MARCo weiterzuleiten. Es geht hier nicht darum ob L.net identisch oder voll kompatibel zu Loconet ist. Niemand hat das behauptet und niemand erwartet das. Es geht hier nur um ESU's Behauptung, MARCo würde mit dem L.net converter weitgehend funktionieren. Meine Erfahrung widerspricht dieser Behauptung. Nun wird ESU diese Behauptung aber nicht völlig aus der Luft gegriffen haben. Dafür ist die sie viel zu spezifisch. Die Frage ist, warum funktioniert es bei mir nicht.

Gruß, Enrico

Hallo Michael,
[quote="Michael Knop" post_id=1945748 time=1551169233 user_id=102]
Ratet mal, warum das Ding auch „nur“ L-Net Anschluss heißt.

Richtig, weil es eben kein LocoNet ist, und auch nicht vom Rechteinhaber (Digitrax) lizensiert ist.
[/quote]
ist das eine Vermutung oder eine gesicherte Information?

Grüße
Stephan

Zitat

---

es sind wohl Implementierungen, die über die LocoNet® Personal Use Edition 1.0 (SPECIFICATION: Digitrax Inc ...)
http://www.digitrax.com/static/apps/cms/...onaledition.pdf
hinaus gehen, aber woran kann man erkennen, dass das inkorrekt ist?

---

Es gibt eine 'Professional Edition' mit zusätzlichen Befehlen. Uhlenbrock hat die sicher implementiert.
Für Marco sind, soweit ich weiß, eigene Befehle definiert worden. Die kann natürlich niemand andere kennen, da nicht dokomentiert.
Genauso hat Digikeijs für die zusätzlichen Railcom-Infos eigene Befehle implementiert.
Ob die das dürfen wäre interessant.

Grüße
Stephan

Der Name LcocNet ist eine eingetragene Marke (mutmaßlich von Digitrax) und Teile davon sind von einem US-Patent geschützt [siehe hier], aber wohl nicht alles. Solange du dein Produkt nicht ohne (sicherlich kostenpflichtige) Genehmigung von Digitrax "LocoNet" nennst und die geschützten Teile nicht verwendest, darfst du damit tun und lassen was du möchtest.
Darüber hinaus enthalten z.B. Schnittstellen-Standards häufig sogar eine gesonderte Sektion für proprietäre Inhalte.

BTW: Es gibt sogar eine Arduino-Bibliothek für LocoNet.

Gruß, Enrico

Hallo zusammen.

Zitat

---

Dabei habe ich festgestellt, dass beim Lokfahren die Funktionen über F12 (also ab F13) nicht brauchbar anwendbar sind (hier weist die ESU-Implementierung Fehler auf). Das Schalten von Weichen ging, Programmieren ging weder via PoM noch über das Programmiergleis.

---

wenn man in JMRI hineinschaut findet man, dass es ab F13 verschiedene Lösungen gibt. Von daher würde ich es nicht als Fehler beschreiben, sondern aus Auslegung eines nicht vorhandenen Standards. Ältere Digitrax Fahrpulte steuern gerne höhere Funktionen über DCC-Direkt Programmierung, was erlaubt ist, aber im FREMO-Betrieb irgendwie Grütze ist.
Wenn man bedenkt, aus welcher Zeit die DCC- und somit die LocoNet-Definitionen stammen, ist es klar, dass es da keine Normung für die hohen Funktionen gibt. Es wird immer über die NDA-Version des LN spekuliert. Ein NDA-Halter hat mir glaubhaft versichert, dass da nichts relevantes drin enthalten ist. Und leider wird die LN-PDE nicht fortgeschrieben im Gegensatz zum DCC.

Die ECOS und Programmieren über Intefaces scheinen wohl Paralleluniversen zu sein.
Ciao
Knut