THEMA: Lange Adresse progr. bei Viessmann 5240

Hallo Udo,
CVs können IMMER nur Werte bis maximal 255 annehmen. Ansonsten wirst du hier geholfen:
https://www.1001-digital.de/pages/programmierung/kleine-helferlein.php

Viele Grüße
Carsten

Hallo Carsten,

erst mal Danke für die Info von Dir.
Ich habe aber auch geschrieben dass ich in CV17 überhaupt keinen Wert schreiben kann. Ich bekomme immer auf meiner Ecos die Meldung "Fehler".
Aber ich versuche es trotzdem einmal.

Gruß vom Härtsfeld
Udo

Hallo Udo,
ok.. Ich hatte das so verstanden, dass du damit einfach keinen Effekt erzielst.

Hat die Ecos denn keine Funktion um eine Adresse direkt zu programmieren (und sich um lange / kurze Adressen selber zu kümmern)? Würde mich wundern bei dem teuren Ding.

Viele Grüße
Carsten

Hallo Carsten,

doch, hat sie so bin ich ja mit dem anderen vorgegangen da hat es ja funktioniert.
Ich habe es nochmals versucht CV18 den Wert 47 geschrieben und ist übernommen worden. In CV17 den Wert 193 wieder die Meldung "Fehler".
Was mich wundert laut Anleitung soll im CV17 der Wert 192 stehen wenn ich aber CV17 auslese ist da 0 drin kann das sein.
Auch ein Reset hat hier nicht weiter geholfen.

Gruß Udo

Hallo ihr

Ich habe versucht, die Adresse auf 601 einzustellen und bin bei Adresse 0 gelandet. Dummerweise läßt sich der Decoder auf Adresse 0 nicht ansprechen. Jetzt steh ich da und weiß nicht weiter.

Viele Grüße
Bernhard

Hallo Udo,
hm, sehr eigenartig. Vielleicht hat der Decoder ne Macke? Wenn er auf ner kurzen Adresse funktioniert, würd ichs erstmal damit umgehen.

Hallo Bernhard,
gib ihm doch einfach ne andere Adresse? Fang erstmal mit ner kurzen an, also setz CV 1 z.B. auf 3 und CV 29 auf 2. Dann sollte das Ding zumindest weder laufen. Wenn du Adresse 601 willst musst du CV 17 auf 194 und CV 18 auf 89 setzen. Dazu noch CV 29 auf 34, damit er die lange Adresse verwendet.

Viele Grüße
Carsten

Was heisst hier "nicht anspechen"? Bist du vielleicht im PoM Modus? Programmieren im Service Mode (also auf dem Programmiergleis) ändert alle Decoder, unabhängig von der Adresse. PoM würde auch deine Probleme mit CV17/18 erklären.

Zwar ist der Viessmann nicht das gelbste vom Ei, doch läuft er bei mir mit Adresse lang 2050.

Gruß,
Harald.

Hallo und Guten morgen zusammen,

also alle meine Versuche in CV17 einen Wert ein zutragen waren bisher erfolglos. Dieser CV17 nimmt einfach keinen Wert an es bleibt immer der Wert 0 stehen, egal ob PoM oder auf dem Programmiergleis.
Ich werde, so wie das aussieht, den Decoder durch einen anderen ersetzten damit ich das Problem mit der langen Adresse lösen kann.
Habe nämlich so meine Fahrzeuge eingrordnet. Dampfer haben alle 100er Nummern Diesel 200er und Triebwgen eben 300erund dass will ich aus so weiter behalten.
Oder weiß noch jemand einen Tipp?

Gruß vom Härtsfeld
Udo

Also nach einem Reset solltest du CV17=192 auslesen, sonst hat der Decoder eine Macke. Auch ist es eigenatig dass du CV18 schreiben und lesen kannst, CV17 aber nicht. Es kann ja sein dass die Speicherzelle wo der CV17 abgelegt werden sollte einen Schuss hat.

Gruß,
Harald.

Hallo,

CV17 darf nicht 0 sein. Hat die Ecos eine Methode zur Programmierung langer Adressen? Wenn ja, würde ich die zuerst probieren.
Wenn CV17 weiterhin 0 bleibt, ist vermutlich etwas mit dem Decoder nicht in Ordnung.

Grüße, Peter W.

Hallo,

@Peter:
Ich habe es über die Ecos, Windigipet und mit dem CV-Programmiermodus der Ecos, wo man Einzel-CV bearbeiten kann, versucht alles bisher erfolglos. Kann die CV17 auslesen Wert=0 aber CV17 nicht schreiben - Meldung Ecos "Fehler". Auch im Windigipet-Programmer ist das gleiche CV17 lesen=0, schreiben=Fehler
Alle anderen CV kann ich lesen und schreiben, egal mit wecher Methode.

@Harald: Genau das ist meine Vermutung dass der Decoder eine Macke hat. Desshalb werde ich ihn ausbauen und einen anderen einbauen.

Gruß vom Härtsfeld
Udo

Hallo,

ich habe schon eine ganze Reihe dieser und seinem Pendant 5241 verbaut.
Und leider ist das ein generelles Problem dieses Decoders, daß er lange Adressen so nicht annimmt.

Das ist ein genereller Fehler in der Firmware des Decoders, nicht eine Macke nur in deinem einen Decoder.

Ich habe folgendes rausgefunden:
Wenn in CV 18 irgendein Wert geschrieben wird, dann kann danach die CV17 beschreiben werden. Allerdings nur einmalig, vor einem erneuten Schreiben muß zuerst wieder CV 18 beschreiben werden.

Ich behelfe mir daher so, daß ich zuerst etwas in CV 18 schreibe, und dann die Lange Adresse über die Intellibox schreiben lasse.

Da ich die Adresse aber im allgemeinen nur einmal einstelle, kann ich damit leben und verbaue die Dinger auch weiter, da sie meinen Ansprüchen genügen.

Gruß
ChristaN

Danke für den Tip. Die Beschänkung ist ja einfach - beschränkt. Dann hab ich wohl Glück gehabt dass meine Zentrale das in der Reihenfolge macht. Steht ja wohl nirgendwo im Standard in welcher Reihenfolge die Zentrale CV17, CV18 und CV29 ändern sollte wenn man eine lange Adresse einrichtet.

Das erklärt aber trotzdem nicht wo CV17=0 herkommt (auch nach Reset?).

Nach anfäglichen positiven Eindrücken von den neuen Viessmanndecodern hab ich die vor allem wegen der sehr problematischen Motorsteuerung kleiner Dreipoler wieder mit "nö, war wohl nix" auf die "wird nicht mehr angeschafft" Liste gelegt. Wenn dann auch noch die Firmware Zicken macht ist das nur eine Bestätigung.

Gruß,
Harald.

Hallo,

so ich habe ihm jetzt gedroht: wenn er keine lange Adresse an nimmst kommt er in die Tonne und siehe da, er hat zwar nach ein paar mal mit Fehler reagiert, auf einmal hat er alls angenommen.
Also so bin ich nun vorgegangen.
Erst mal CV1 auf 3
dann CV18 auf 47
danach war plötzlich im CV17 der Wert 192 drin den auf 193 geändert und das war es dann
Klar CV29 entsprechend noch eigestellt.
Jetzt habe ich meine Adresse 303 dem Decoder bei gebracht.
Solche Decoder kommen mir nicht mehr ins Haus.
Was ich auch noch heraus gefunden habe immer wenn ich mehr als vier CV´s geändert habe hatte ich die Fehlermeldung auf meiner Ecos. Nach dem ich z.B. die CV2, CV3, CV4 und CV5 zu Spaß geändert habe konnte ich in CV29 wieder nichts mehr ändern wieder der Fehler. Es als ich die Lok von der Ecos abgemeldet habe und wieder an konnte ich wieder CV ändern. Ist schon seltsam.
Aber jetzt läuft er wie ich es habe will und mache mit dem keine Experimente mehr.

Gruß vom Härtsfeld
Udo

Moin zusammen und Frohes Neues!


Da hat wohl jemand versucht, das Programmieren gepaarter CVs umzusetzen und einen ziemlichen Bock geschossen. Irgendwie hatte ich mich bei dem Thema schon gewundert, dass mir da was bekannt vorkam, hatte die Infos aber nicht gleich bei der Hand.

Folgendes: In der NMRA RP-9.2.1 gibt es eine Fußnote zu gepaarten CVs, ich zitiere mal:


Übrigens wurde das entsprechende Kapitel, das in RP-9.2.2 dann die Details beschreiben sollte stumpfdumm vergessen. Sprich es existiert einfach nicht.

Ich mache es in meinem UADE Decoder so, dass ich bei Schreibzugriffen auf CV17 den Wert erstmal in einer privaten Variablen zwischenspeichere, d. h. CV17 ändert den Wert nach außen hin erstmal NICHT, sondern der Decoder reagiert noch auf die alte Adresse und würde auch den alten Wert auslesen. Natürlich liefert mein Decoder - anders als der hier genannte Viessmann 5240 - beim Zwischenspeichern des Wertes den erforderlichen Acknowledge Impuls.

Erst wenn der neue Wert für CV18 eingeschrieben wird, wird in einem Rutsch sowohl CV17 (mit dem zwischengespeicherten Wert) als auch CV18 aktualisiert.

Für mich lesen sich die Symptome für den 5240 so, als ob da jemand die Vorgabe aus der RP-9.2.1 einfach nicht verstanden oder nicht richtig umgesetzt hat. Ich vermute fast mal, dass viele Decoder-Hersteller da gar keine speziellen Maßnahmen ergreifen, alleine schon, weil das in den NMRA-Dokumenten so schlecht dokumentiert ist (Fußnote im Dokument zu den Extended Packet Formaten, wo's Niemand vermutet und dann noch mit Verweis auf das Dokument zu den CVs, wo es hingehören würde, nur wurde das Kapitel dort schlicht vergessen).

Viele Grüße,
Torsten

Du liabs Herrgöttle von Biberbach, ... wie hend die di Mucke verschisse

Ob CV17 in der Zeit bevor CV 18 beschrieben wird den alten oder den neuen Wert beim Auslesen anzeigen sollte steht dann wohl in dem nicht existenten Kapitel

Und bei Viessmann (oder dem Subcontractor) hat man scheibar "will take effect" mit "ist erst dann erlaubt" übersetzt.

Gruß,
Harald.

Hallo,

die generelle Meinung bei den Hersteller ist aber, dass eine CV *immer* den geschriebenen Wert reflektieren muss. Die Annahme des Wertes zu verzögern oder gar zu blockieren, finde ich verwerflich. Man kann nicht davon ausgehen, in welcher Reihenfolge die beiden CVs geschrieben werden.

Ob die Adresse nun unmittelbar Effect taken will, wenn nur eine der beiden CVs geschrieben wird, ist eine andere Sache.
Spätestens nach Power Off muss sie sowieso ziehen.

Grüße, Peter W.

Ja, das ist wahrscheinlich das Beste, auch bei CV17/18.


Nach der Fußnote (warum man sowas in eine Fußnote schreibt, tja was haben die da geschnupft?) ist die gedachte Reihenfolge CV17->CV18, sonst geht das ja mit dem "Commit" nicht.


Ja sonst wäre der Anwender total verwirrt wenn er die Lok nach einiger Zeit aus der Schachtel nimmt und die Adresse stimmt nicht mit den CV übereins.
Und wenn die Zentrale nach jeder Programmierung im Service mode mal kurz die Spannung ausmacht, wie ist das dann mit "Paired CV" Konzept? Da wollte jemand verhindern dass die Lok beim Umprogrammieren zwischen zwei Adressen eine andere Adresse hat, aber warum denn? Programmieren der Adresse ist doch im PoM gar nicht vorgesehen.

Gruß,
Harald.

Hallo,


Ja solche Zentralen gibt es. Das sollte sie allerdings tunlichst nicht bei der CV17-18-29 Prozedur. Aber wer weiß, wie die Typen vom Schlage "wir-sprechen-nicht-mit-anderen" das implementiert haben.

Grüße, Peter W.

Folks!
Die Normen sind leider all zu oft mit Konjunktiven geschrieben. Grundsätzlich kann man aber CV17/18 schreiben bevor man CV29 auf lange Adressen umstellt, wenn man das zur Belustigung schon unbedingt via POM machen will.
Besser ist das im Service Mode zu machen, weil hier keine Adresse zur Programmierung verwendet wird. Der Decoder kann also daher keine "falsche" Adresse haben. Auch hier CV17 und CV18 als auch CV29 müssen in beliebiger Reihenfolge beschreibbar sein.

Zum PowerUp Problem: sehr simple Implementationen warten auf ein Versorgungsspannungsloch bevor sie Änderungen übernehmen. Viele dieser Decoder stammen noch aus der Zeit vor POM. Es gibt aber auch Decoder die via POM programmiert werden können und erst nach dem Unterbrechen der Versorgung zB durch herauskippen vom Gleis beim PowerUp die Werte in Betrieb nehmen. So war's definitiv nicht geplant bei POM!

Es war einmal geplant NMRA Konformitätstests zu machen. Das scheitert einerseits an sehr überzogenen Forderungen bzgl der Testqualität und andererseits am mangelnden Personal das die Tests durchführt. Hohe Testqualität ist wohl nötig um rechtlichen Problemen bei Fehlern und der verbundenen Fingerzeigerei zu entgehen. Daher gibt's das derzeit eben nicht. Die Railcommuniuty versucht derzeit einen Prozess dafür aufzusetzen. Wir plagen uns da genau mit den zuvor genannten Problemen herum
-AH-.