Hallo zusammen,

... muß was loswerden und weiss nicht, ob es wirklich jemanden interessiert:javascript:emoticon('')

die ECoS kennt als Statusabfrage-Ergebnis den Zustand "SHUTDOWN".
Wen ich die CS v2.03 herunterfahre, liefert die CS als Status "STOP" an die Software. Ein anschließender Statusrequest liefert dann nichts mehr, wen die CS "heruntergefahren zu sein" anzeigt, ist auch keine Netzwerkkommunikation mehr möglich.

Eigentlich schade, dass die CS an die Software den "SHUTDOWN"" nicht meldet (ist es ein Bug oder ein Feature?).

---------------------------------------------------------------------------

Was mir sonst noch aufgefallen ist. Gilt nur für mfx-Loks:
man nehme eine mfx-Lok mit id=1002 als Beispiel, 127 Fahrstufen:

die Lok steht, der Befehl
get(1002, speedstep)

liefert als Antwort
>REPLY get (1002, speedstep) >
1002 speedstep[0]
>END 0 (OK) >


setzt man dann die Lok auf Fahrstufe 1, fährt sie ganz langsam an,
und kontrolliert man gleichzeitig das Ergebnis:
set(1002, speedstep[1])
get(1002, speedstep)

>REPLY set (1002, speedstep[1]) >
>END 0 (OK) >
>REPLY get (1002, speedstep) >
1002 speedstep[1]
>END 0 (OK) >


soweit so gut, sendet man dann erneut den Befehl für Fahrstufe 1, stoppt die Lok,
weil dann Fahrstufe=1 als Nothalt der Lok interpretiert wird:
set(1002, speedstep[1])
get(1002, speedstep)

>REPLY set (1002, speedstep[1]) >
>END 0 (OK) >
>REPLY get (1002, speedstep) >
1002 speedstep[0]
>END 0 (OK) >


Es empfiehlt sich also nach dem Senden von Fahrstufenbefehlen deren Wirksamkeit zu kontrollieren, damit die Fahrstufenanzeige am Computer den gleichen Wert anzeigt wie an der CS.

Bei der Verwendung des Befehls
set(1002, speed[1])
get(1002, speed)

ist das Ergebnis leider etwas anders: am CS-Monitor wird zwar
Fahrstufe "1" angezeigt, dem Computerprogramm wird aber "2" mitgeteilt:

>REPLY set (1002, speed[1]) >
>END 0 (OK) >
>REPLY get (1002, speed) >
1002 speed[2]
>END 0 (OK) >


Der Parameter "speedstep" arbeitet also zuverlässiger als "speed".
Wohl weil "speed" ja auch als Km/h interpretiert werden kann.
Auch hier wieder führt das wiederholte Senden von
"set(1002, speed[1])"
zu einem Wechsel zwischen langsamster Fahrstufe und (Not-)Halt.

Es ist eine Besonderheit beim Programmieren der Lokgeschwindigkeit für
mfx-Loks. Loks mit 14 Fahrstufen werden beim wiederholten Setzen
von Fahrstufe "1" auch wirklich auf Fahrstufe "1" gehalten.


So, genug gejammert.
Ciao
Diego

Hallo,

Welche Arten Notstop gibt`s bei mfx?

Bei DCC gibt`s global und local stop commands.

Global geht über eine Broadcast-Adresse 0000000, local über die Lokadresse und Fahrstufe 1, also lokselektiv.

Wenn der Decoder bei Fahrstufe 1 anfährt und bei erneutem Senden
der Fahrstufe 1 wieder bremst, hat man vermutlich bei DCC abgekupfert, den local Stop (CS-seitig im stand alone Betrieb) nicht implementiert und der Decoder reagiert nicht richtig auf das Signal (dürfte die Lok gar nicht erst in Bewegung setzen).

Also sowohl nicht implementiertes (stand alone) feature (CS) als auch bug (mfx-Decoder).

Wenn Du nun "speed" anstatt "speedstep" eingibst, ist das konsistent mit der Anzeige und dem Soll-Verhalten des Decoders (Benutzeroberfläche und Anwender-Wahrnehmung) einerseits, andererseits bezieht sich die Rückmeldung auf das tatsächlich am Gleis vorhandene Signal.

Gruss,
Manfred

Danke Manfred für die Tipps,

habe da noch was bei der CS gefunden:

Der Befehl
queryObjects(11, addr, name1, name2, name3, protocol, addrext)

liefert als protocol "MOT" (Parameter "state", "mode", "symbol" und "duration" liefern nichts, führen aber auch nicht zu einer Fehlermeldung):

>REPLY queryObjects(11, addr, name1, name2, name3, protocol, state, mode, symbol, duration, addrext)>
20000 addr[1] name1["Gleis 1"] name2["Ost"] name3["Tunnel"] protocol[MOT] addrext[1g, 1r]
20001 addr[2] name1["Gleis 2"] name2["Ost"] name3["Tunnel"] protocol[MOT] addrext[2g, 2r]
20002 addr[25] name1["Gleis 1"] name2["West"] name3["Tunnel"] protocol[MOT] addrext[25g, 25r]
20003 addr[26] name1["Gleis 2"] name2["West"] name3["Tunnel"] protocol[MOT] addrext[26g, 26r]
>END 0 (OK)>

wohingegen der Befehl
get(20003, duration, mode, protocol, symbol, state)

>REPLY get(20003, duration, mode, protocol, symbol, state)>
20003 duration[250]
20003 mode[SWITCH]
20003 protocol[MM]
20003 symbol[1]
20003 state[1]
>END 0 (OK)>

als Protocol "MM" liefert, was wohl das selbe meint, aber eigentlich den gleichen Text wie oben liefern sollte. Wahrscheinlich ist der Fehler aber in "queryObjects" zu suchen, da eigentlich "queryObjects(11, protocol)" nicht dokumentiert ist.


Andere "undokumentierte" Parameter (z.B. "type") habe ich z.Zt. nicht gefunden.

Ciao
Diego

Hallo Diego,

genau diese Punkte sind wahrscheinlich der Grund, dass Märklin das Protokoll (noch) nicht freigegeben hat.

Auch die Protokoll-Dokumentation der ECoS hat die Version 0.1, d. h. das Protokoll ist noch eine Baustelle... Es steht ja auch drin, dass noch nicht alles implementiert ist. Ich staune ja etwas, dass angesichts dieser Tatsache die professionellen Software-Anbieter von PC-Steuerungen die ECoS schon eingebunden haben (na ja, immerhin ist schon dokumentiert, was drin ist).

Welche Version die IP-Schnittstelle der CS hat, ist unklar, da hier überhaupt noch keine Dokumentation vorliegt.

Vieles scheint gleich mit der ECoS - warum auch nicht? -, aber die Besonderheiten sind möglicherweise noch nicht korrekt umgesetzt. Wegen der fehlenden Dokumentation weiß man allerdings nicht, ob das gewollt ist oder ein Fehler.

Die Sache mit dem "Speedstep" ist ja so ein Beispiel: Soll es bei mfx-Loks gleich sein mit DCC oder ist es ein Bug, welcher sich nur durch eine Codeanpassung des DCC-Softwaremoduls für mfx eingeschlichen hat.

Endgültig werden wir es erst wissen, wenn Märklin das Protokoll offiziell dokumentiert und freigibt. Angesichts der beobachteten Ungereimtheiten (ob es Fehler sind, wissen wir nicht) denke ich, dass wir noch ein Update der CS abwarten müssen.

Interessant wäre ja, ob auch bei der ECoS die unterschiedliche Benennung des Motorola-Formats von Magnetartikeln auftritt - dann hätten wir den ersten Fehler des ECoS-Protokolls entdeckt (allerdings bei einem undokumentierten Parameter...)

Hallo Udo,

da stimme ich Dir voll zu. Ich denke auch, dass im Laufe der Zeit das meiste an "Ungereimtheiten" durch die nächsten zwei Updates lösen lassen. Die Interface-Beschreibung ist dabei das kleinere Problem, so viele Aufgaben soll die CS ja nicht übernehmen.

Ich denke, dass die hier in anderen Threads beschriebenen Änderungswünsche der Benutzeroberfläche den Hersteller mehr auf Trab halten werden.

Zum Wesentlichen: mittlerweile ist klar, dass die am Event-Manager festgestellten "Probleme" wohl auf "Eingabefehler" zurück zuführen sind. Bei Absturz der CS bleiben in der CS die View-Anforderungen aktiv und beim nächsten Hochfahren der Software kriegt diese unangefordert Nachrichten von dem Event-Manager.

Ich habe also meine Software auf solche "unerwarteten" Meldungen dahingehend vorbereitet, dass bestimmte Reaktionen auf eingehende Events nicht mehrfach abgearbeitet werden. Ist schon lästig, wenn der Event-Manager 7-mal hintereinander das gleiche berichtet.

Wenn die Software beendet wird, müssen alle View-Anforderungen bei der CS "released" (furchtbares neudeutsch) werden. Vielleicht spendiert man der CS ja mal einen Befehl wie "release(all)".

Ciao
Diego

Hallo Diego,
welche Software verwendest DU?

Gruß aus Dortmund
Werner

Hallo Werner,

zufällig bin ich gerade online und kann sofort anworten.

Die hier im Thread beschriebene CS-Kommunikation erfolgte mit SimpleDigitalLocomotive (gibt es z.Zt. nur für MacOS-X). Gezippt ca. 9 MB groß, was als Größe wohl auch für eine WinXP-Variante gelten müßte, die es aber wohl nie geben wird.

Siehst Du hier:
viewtopic.php?t=12317,-suche-eine-gescheite-macsoftware-zum-meine-modelbahn-steuern.html
(5. Post von oben)

Ciao
Diego

hallo,

ich habe manchmal das gefühl das bei der cs und ecos softwareentwickler am werk sind die ihr handwerk noch nicht so richtig verstehen... im grunde ist programmieren immer erst dann erfolgreich wenn der unterbau perfekt dasteht.. wenn der steht dann kann man das UI gut erstellen.. hier scheint es aber aufgrund der meldungen eher umgekehrt zu sein.. vorne hui hinten pfui... sonst wären solen eventmanagerprobleme nicht so vorhanden...

oder sehe ich das zu kritisch?

Hallo MacBee,

naja, ganz so streng und dramatisch sehe ich das nicht mehr. Bin froh das ich die CS ansprechen kann/darf!
Bei der ECoS gibt es ja mittlerweile das Update 1.0.6, womit bei der ECoS das Problem behoben ist. Für die CS warten alle (geduldig ?) auf das entsprechende Update.

Mittlerweile kann ich mich auf die Meldungen von der CS nur in dem Rahmen verlassen, wie er bei der v0.1-Interface-Beschreibung von ESU EXPRESSIS-VERBIS so drin steht. Manchmal kommen eben ein paar Meldungen mehr als gedacht.

Z.B. ganz frisch auf den Tisch:
delete-Befehl:
- Befehl-Reply (so wie es in v0.1 drin steht)
- Id-event "id deleted" (kommt selten, egal ob view-request angefordert war oder nicht)
- MSG LIST_CHANGED
liefert maximal drei Ergebnisse. Nur die erste Meldung ist in der Beschreibung auch dokumentiert. Ist ja gut gemeint. Man muss sich aber als Softwareentwickler dann doch irgendwann entscheiden, auf welchen feedback man warten will bzw. was man getrost ignorieren kann.

Vieleicht wird das ja mal einheitlicher.
Perfekt? Bei Programmen? Wann gab es denn das schon mal?
Murphy's law: ein Programm das perfekt ist, ist veraltet!

In diesem Sinne,
keep on coding...

Diego

Hallo,

seit einigen Wochen beschäftige ich mich auch ein wenig mit befehle an die CS schicken.

Bisher habe ich noch keinen Befehl gefunden, welcher mir verrät, ob eine mfx-Lok auf dem Gleis steht. Ich vermute mal, dass es hierfür auch noch keinen Befehl gibt: Mann wird ja auch nicht hierüber Informiert, wenn mann als Viewer registriert ist.

Gruß, Michael

Zitat von Michael Z.

---

Bisher habe ich noch keinen Befehl gefunden, welcher mir verrät, ob eine mfx-Lok auf dem Gleis steht.

---

Hi Michael,

bin mir jetzt nicht sicher (kommt schon selten vor, dass ich eine neue mfx-Lok habe zum Anmelden): es ändert sich die interne datenbank. Wenn Du also ein view angemeldet hast für die LokListe, dann sollte ein Event kommen, sobald die mfx-Lok in der Datenbank der CS1 eingetragen wird.

Habe noch einen jungfräulichen mfx-Decoder hier rumliegen und das dann mal übermorgen ausprobieren und berichten.

Ciao
Diego

Hallo,

Zitat von DiegoGarcia

---

Hi Michael,

bin mir jetzt nicht sicher (kommt schon selten vor, dass ich eine neue mfx-Lok habe zum Anmelden): es ändert sich die interne datenbank. Wenn Du also ein view angemeldet hast für die LokListe, dann sollte ein Event kommen, sobald die mfx-Lok in der Datenbank der CS1 eingetragen wird.

---

Ich habe da was anderes gemeint: Und zwar ob eine mfx-Lok auf dem Gleis steht oder nicht wenn sie schon angemeldet ist. Also eine Möglichkeit, abzufragen, ob das mfx-Symbol (welches auf dem Display der CS zu sehen ist) invertiert ist oder nicht. War das verständlicher?

Gruß, Michael

Okay, Michael, jetzt weiss ich, was Du meinst. Nach meiner Erfahrung gibt es keine Abfragemöglichkeit des Präsenzstatus einer mfx-Lok.

Evtl. gibt es sowas inoffiziell, d.h. nur Märklin und ESU wissen das. In der aktuellen Interface-Syntaxbeschreibung ist nichts mfx-spezielles gelistet. Evtl. wird das mit dem v3.0 Update ja besser.

Deshalb ja auch die Berichte hier, damit wir etwas mehr über die mfx-Syntax-Specials der CS1 austauschen können.

Ciao
Diego

Das haben wir in der Vergangenheit hier im Forum schon mal beschrieben.

Also Michael: da hat ESU noch einiges zu tun bis Januar 2009.

Ciao
Diego

Hallo,

Zitat von DiegoGarcia

---

Also Michael: da hat ESU noch einiges zu tun bis Januar 2009.

---

Das denke ich doch auch.

Vielen Dank für's ausprobieren.

Gruß, Michael