[Gast]

Hallo Michael,

so wie du es beschrieben hast stimmt es noch nicht ganz.

Zitat von 99651

---

4) Koppelung der Detektoren mit der dahinter stehenden "Intelligenz". Das ist bei Tams im Moment der Railcom Bus, bei Lenz die Displayanzeigen, Zimo und ESU deren jeweiliges Bussystem.

---

Der RailCom-Bus ist auch von Lenz. Bei Tams gibt es nur den RC-Link.

Ich hoffe nun die lezte Klarheit beseitigt zu haben.

viele Grüße
Frank

[nobby]

Frank, was soll das jetzt wieder ?

Hier geht es nicht darum was von wem ist, und vor allem ist es eine absolute Frechheit, das Du schon wieder versuchst jemanden klein zu reden !
Erst vor einigen Tagen hat sich Herr Tams in einem anderen Beitrag entsprechend darüber beschwert.

Hier kannst Du selber lesen, das Tams mindestens seit 9/2008 einen RailCom Bus hat (Seite2, ganz links):
http://www.tams-online.de/htmls/produkte...D-1_2008_DE.PDF
und dafür kann man nun auch schon über 1 Jahr die Ware KAUFEN, was bei Lenz bis heute nicht der Fall ist.

Was soll das überhaupt bedeuten ?

Zitat

---

Bei Tams gibt es nur den RC-Link.

---

Nur der RC Link reicht wohl nicht um einen Bus Betrieb zu nutzen, bei Tams gibt es auch noch den RCD1, RCA1, RCA24. Alle diese Produkte sind dazu da um die Lokadressen und CV Daten anzuzeigen.
ALLE diese Produkte kann man kaufen, und gibt es nicht nur auf Papier, wie von Lenz. Was den angeht, wird es vor dem 1. Quartal 2010 nichts mit Bus-System zu kaufen geben.

So denn, nun habe ich auch mal Werbung für eine Firma gemacht, so wie bei Dir jedes zweite Wort Lenz ist, ob Du nun danach gefragt wirst, oder nicht.

Gruß

[Gast]

Hallo Nobby,

Zitat

---

Frank, was soll das jetzt wieder ?

---

Ich wollte nur korrigieren das der RailCom-Bus von Lenz ist, und der RC-Link von Tams. Das war hier vertauscht worden.

Zitat

---

Erst vor einigen Tagen hat sich Herr Tams in einem anderen Beitrag entsprechend darüber beschwert.

---

Ist mir bekannt, dazu habe ich mich ja an gleicher Stelle bereits geäussert.

Zitat

---

So denn, nun habe ich auch mal Werbung für eine Firma gemacht, so wie bei Dir jedes zweite Wort Lenz ist, ob Du nun danach gefragt wirst, oder nicht.

---

Naja, damit kenn ich mich halt ganz gut aus, und schreibe hier halt meist ungefragtes. Ich sehe das hier eher als einen Meinungsaustauschs- als ein herstellerabhängiges Supportforum an.

Das Lenz in RailCom-Fragen immer wieder auftaucht, liegt zum einen daran, das sie RailCom entwickelt und die ersten RailCom-Geräte herausgegbracht haben. zu anderen, dass ich weiss, was für eine mögliches Potential sowie welche hohe Erwartungshaltung bereits hinter dem Begriff "RailCom" stecken, und ich deswegen befürchte, das eine zu schnelle Vermarktung mit inhaltsarmen Produkten den noch wackeligen Standard ernsthaft ruckeln lassen könnte. Letztendlich hängt auch die gesamte herstellerübergreifende Entwicklung von RailCom von dessen Image und Akzeptanz ab.

Viele Grüße
Frank

[99651]

Hallo,
ich habe noch mal nachgeschaut wie den der Bus von Tams nun genannt wird. Er nennt ihn RC-Bus, denn RC-Link ist ja nur das PC Interface. Damit können wir die Bezeichnung RailCom-Bus den hoffentlich auch bald erscheinenden Produkten von Lenz zuordnen.

So und jetzt streitet ihr beiden euch doch bitte nicht. Auch wenn man manche Äußerungen vielleicht als provokativ interpretieren kann, man muss doch nicht gleich Beisreflex artig drauf anspringen.

In diesem Sinne, allen ein schönes Wochenenden.
Michael

[Muenchner Kindl]

Hallo Busfahrer

Ich vermute mal, dass der Begriff "RailCom Bus" geschuetzt ist, einen offiziellen Namen fuer den Datenweg bei Tams kann ich ausser in einem persoenlichen Beitrag nicht finden. Ich nenne ihn RS485-Bus und bleibe auch dabei.

Frank,

Zitat

---

Der RailCom-Bus ist auch von Lenz. Bei Tams gibt es nur den RC-Link.

---

Diese Aussage hilft den Fragenden sicher weiter aber im Gegensatz zum RailCom Bus kann man den nur-RC-Link bereits kaufen und einsetzen

Zitat

---

das eine zu schnelle Vermarktung mit inhaltsarmen Produkten den noch wackeligen Standard ernsthaft ruckeln lassen könnte

---

Achso, da ist natuerlich gar keine Vermarktung oder das Ankuendigen von Produkten schon besser. Jeder Hersteller, der etwas auf RailCom haelt hat bald ein kompletteres System im Portfolio als der Erfinder selbst, ob das nun ESU, Zimo oder auch Tams ist.
Ich will nicht auf Lenz herumhauen, sehe es bitte als Kritik. Gerade als Erfinder sollte er RailCom mehr praesentieren als auf einer Ankuendigungsseite nach dem dritten Minilink der Seite. Das Baby "RailCom" wird derzeit von anderen ausgetragen.

[Gast]

Hallo Thomas,

Zitat von Muenchner Kindl

---

Frank,
....
Diese Aussage hilft den Fragenden sicher weiter aber im Gegensatz zum RailCom Bus kann man den nur-RC-Link bereits kaufen und einsetzen

Oder sich an einen fragwürdigen RC-Standard binden .
.

---

jetzt nimm mir das bitte nicht übel, aber vielleicht verstehst Du meine Erwähnungen der tw. noch in Konstruktion befindlichen Alternativen dann besser:

Das was ich in der RC-Talk Protokollbeschreibung als ungesichertes Protokoll ist für mich als Mobahner und als Informatiker und Spezialist für formale Sprachen so ziemlich das fragwürdigste, was ich je in einem Delta-Meldenden System gesehen habe. Man würde sowas im professionellen Bereich allenfalls als eiliger Datenlogger für Diagnosezwecke einsetzen.

Entschuldige meine harten Worte, aber sie erklären den Grund warum ich so oft die ausstehende Alternative erwähne. Das mindert auch nicht Deine Leistung , dieses zu implementieren.

Zitat

---

Ich will nicht auf Lenz herumhauen, sehe es bitte als Kritik. Gerade als Erfinder sollte er RailCom mehr praesentieren als auf einer Ankuendigungsseite nach dem dritten Minilink der Seite. Das Baby "RailCom" wird derzeit von anderen ausgetragen.

---

Zu Lenz : Mittlerweile sind ausnahmlos alle aktuellen Digital-Plus-Babies bei den Digital-Plus-Zentralen , Digital-Plus-Lokdecoder und Digital-Plus-Booster RailCom Fähig. Das zeigt ein kontinuierliche durchgängige Weiterentwicklung des Babies bidirektionales DCC = RailCom, mit jährlichen Neuerungen wie auch zielgerichteter Produktpflege.

Gerade der RailCom-Bus ausreichend lange gestillt wird , lässt mich auf ein gesundes kräftiges Kind hoffen.

Trotzdem Grüße
Frank

[Muenchner Kindl]

Mahlzeit,

da das eigentliche Thema ja mehr oder weniger geklaert ist koennen wir gerne da weitermachen, ich schliesse aber auch nicht aus, alle nicht zur Frage gehoerenden Beitraege abzutrennen.

Zitat

---

Das was ich in der RC-Talk Protokollbeschreibung als ungesichertes Protokoll ist für mich als Mobahner und als Informatiker und Spezialist für formale Sprachen so ziemlich das fragwürdigste, was ich je in einem Delta-Meldenden System gesehen habe. Man würde sowas im professionellen Bereich allenfalls als eiliger Datenlogger für Diagnosezwecke einsetzen.

---

Was fehlt denn Deiner Meinung nach in dem fragwuerdigen RC-Talk-Protokoll? Was vermisst Du und was haette besser sein koennen? Was ist an einem "eiligen Datenlogger fuer Diagnosezwecke" so schlecht und was unterscheidet ihn von einem professionellen System?

Zitat

---

Mittlerweile sind ausnahmlos alle aktuellen Digital-Plus-Babies bei den Digital-Plus-Zentralen , Digital-Plus-Lokdecoder und Digital-Plus-Booster RailCom Fähig.

---

Das ist aber schoen, vor allem fuer den preiswerten Lenz Siver freut mich das. Allerdings sind die Mitbewerber, von ESU ueber Tams bis Zimo, laengst so weit, meist gar weiter.

Zitat

---

Gerade der RailCom-Bus ausreichend lange gestillt wird Wink , lässt mich auf ein gesundes kräftiges Kind hoffen

---

Bis dahin ist das bereits geborene Kind fast erwachsen und hat seine Kinderkrankheiten hinter sich

[Gast]

Zitat von Muenchner Kindl

---

Mahlzeit,

Was fehlt denn Deiner Meinung nach in dem fragwuerdigen RC-Talk-Protokoll? Was vermisst Du und was haette besser sein koennen? Was ist an einem "eiligen Datenlogger fuer Diagnosezwecke" so schlecht und was unterscheidet ihn von einem professionellen System?

---

Ok ein Punkt zur Mittagsstund:

a) RC-Talk hat ein Terminalsymbol FF am Schluss. In der der Moba muss man nun fast davon ausgehen, das ein Verwender leist bis 'FF' (Carriage-Return ) . Kommt nun FF in den Daten vor, erhält er dabei Datensalat. und er hat kein beginnendes Terminalsymbol zum Wideraufsetzen. Erst wenn man das erkannt hat (vorsicht es adressiert Hobbyisten), wird man wohl aus der Satzkennung auf die Länge schliessen müssen (korrekt wäre eine expilizite Längenangabe), was wiederum aufwendigeres Programmieren erfordert, und das FF zum reinen Ballast werden lässt.

Desweiteren lässt ein nur implizite Längenangabe über die Satzkennung prinzipiell keine Abwärtskompabilität zu neuen Device-Release zu, das die Satzlängen neuer Sätze für den alten Client unbekannt sind.

b) Es ist leine Checksumme implementiert. Sollte ein Bit kippen, verursacht das bereits ein Falschmeldung. Beim RS232 und 485 implemetiert man immer eine Checksumme , damit eine gekipptes Bit (bei íner MoBa-typischen-Verkablung - Hubert köpft mich gleich - nicht auszuschliessen) allenfalls Dataloss verursacht, aber keine Fehlfunktion auslöst.

c) Es gibt kein sicherndens Software-Protokoll und keinen Abfolge-Context drumrum. Für Paketwiederholungen z.B. im Fehlfall oder Verbindungsstörung oder Überlast eine Komponente, hat man normalerweise auch aif Softwareebene Regeln, Übertragungsfehler zu erkennen und zuhandhaben. gerade in Zeitalter schnell wechselnder Rechnerbauarten
ud Multi-Threading hat sich das als notwendig erwiesen, da mit einem einfachen RTS/CTS kaum noch den oft Treiber-Fehler genannten Phänomen beizukommen, das unter Multithrading (das nutzen fast alle Betriebssysteme mittlerweile) änderung der Reihenfolge von Ereignissen (wie CTS/RTS Nachrichten) beizukommen. Unter aktuellem MS .Net hast du z.B. zu jedem COM-Port eine Thread-Pool, der quasie wahrlos bei jeder Pegeländerung Threads abfeuert, die aber nichr mehr in der beabsichtigen Reigenfolge in der Anwendungsebene ankommen.
Man kann praktisch nur alle Daten-Inhalte aus dem Base-Stream des Beriebssystems lesen, und dabei ist das ein Software-Handshake das Qualitätskriterium, das das Schnittstellengeschehen für die Appikation erst sicher handhabbar macht, indem es spezielle Steuermeldungen (z.B. Rückmeldung über das Eintreffen von Befehlen, oder fehlerhafte Übetragungen, Empfangsbereitschaft, etc.) in den Daten-Kontext mitaufnimmt. Diese Software-Prtokoll im Lenz-System war das Merkmal, das die Lenz-User beim Rechnerwechsel unter PC-Prgrammen vor dem Un-Bill (hier nenne ich keine Namen) von "Treiberproblemen" bisher bewahrte.

Wenn RC ernsthaft zur Steuerung eingesetzt wird (z.B. Anfahren der Lok , deren Adresse als letztes zum Signalfeld X gemeldet wurde), ist die Beachtung solcher Dinge meinesarchtens unumgänglich. Bei einem Tacho ohne weitere Auswertung in einer Datenpumpe +/- 2% wäre es egal.

Viele Grüße
Frank

[Muenchner Kindl]

Hi,

Zitat

---

Kommt nun FF in den Daten vor, erhält er dabei Datensalat

---

Das wuerde fuer jedes andere Zeichen auch gelten. Wir haben uns entschieden, eine Endekennung zu verwenden, die Wahl fiel auf FF weil es keine Kombination gibt, bei der auf ein FF noch etwas folgen wuerde (Ausnahme: Wenn der Oszillator des Prozessors nicht kallibriert wurde endet die Diagnoseabfrage mit FF FF, ebenso wenn eine CV den Wert 255 beinhaltet).

Zitat

---

b) Es ist leine Checksumme implementiert. Sollte ein Bit kippen, verursacht das bereits ein Falschmeldung.

---

Bekomme ich aus dem Decoder eine Checksumme? Da waere es noetiger und genau da ist keine vorgesehen, denn wenn ein Bit kippt, dann eher da und genau hier habe ich in der Software des RC-Link effiziente Routinen eingebaut.
Fuer die angeschlossene Software besteht jederzeit die Moeglichkeit, gesendete Daten erneut abzufragen. Wenn also der Programmierer der Steuerungssoftware auf Nummer Sicher gehen will laesst er sich jedes empfangene Datagramm nochmal bestaetigen.

Zitat

---

Es gibt kein sicherndens Software-Protokoll und keinen Abfolge-Context drumrum. Für Paketwiederholungen z.B. im Fehlfall oder Verbindungsstörung oder Überlast eine Komponente, hat man normalerweise auch aif Softwareebene Regeln, Übertragungsfehler zu erkennen und zuhandhaben. gerade in Zeitalter schnell wechselnder Rechnerbauarten

---

Ich bin gespannt, ob Lenz (und andere) das alles beruecksichtigen, und wenn, was das dann kosten wird
Der RC-Link soll Lokadressen, CV und vielleicht irgendwann mehr aus dem auf einer Spielzeugeisenbahn befindlichen Datenbus auslesen, aufbereiten und weiterreichen und nicht die Brennstaebe eines Kernkraftwerks regeln.

Das Protokoll ist bewusst einfach gehalten, damit es fuer die Softwareautoren einfach zu implementieren ist. Im Prinzip kann jeder Hobbyprogrammierer ein Softwaretableau, eine Programmierhilfe usw. dazu schreiben. Die Anforderungen sind gering, die Daten kommen vorgekaut ueber die Schnittstelle.

[Gast]

Hallo Thomas,

Antwort kriegst Du als PN.

Viele Grüße
Frank

[Muenchner Kindl]

Das Thema habe ich von hier abgetrennt.

[Gast]

Hi auch,

als doch als öffentlich wenn’s denn von Interesse ist. Wenn’s zu problematisch ist, nimms bitte in Deine PN:

Zitat

---

Zitat

---

Kommt nun FF in den Daten vor, erhält er dabei Datensalat

---

Das wuerde fuer jedes andere Zeichen auch gelten. Wir haben uns entschieden, eine Endekennung zu verwenden, die Wahl fiel auf FF weil es keine Kombination gibt, bei der auf ein FF noch etwas folgen wuerde (Ausnahme: Wenn der Oszillator des Prozessors nicht kallibriert wurde endet die Diagnoseabfrage mit FF FF, ebenso wenn eine CV den Wert 255 beinhaltet).

---

Naja, wie willst Du das bei einem update-fähigen System im vorhinein Wissen, das niemals im Paket ein FF vorkommen darf? Z.B. wo der Zimo-Tacho und generelle alle RailCom-Daten eine 255 zulassen?

Die uralte Methode Binärdaten zu übertragen ist einfach die Länge mitzugeben. Die Terminalsymbole wie ‚FF’ erleichtern allensfalls das Wiederaufsetzen bei oder das Eintauchen in einen laufenden Datenstrom, sind aber letztendlich nicht die eigentlichen
„Begrenzer“, das man deren anderweitiges Vorkommen im binären Datenstrom sogut wie nie auschliessen kann.

Zitat

---

Zitat

---

b) Es ist keine Checksumme implementiert. Sollte ein Bit kippen, verursacht das bereits ein Falschmeldung.

---

Bekomme ich aus dem Decoder eine Checksumme?

---

Nein, aber ersatzweise zigfache Wiederholungen.

RailCom, S88 oder Sx z.B. werden erst dadurch sicher, das sie viele Male wiederholt dasselbe senden. Hingegen hast es aber beim Interface mit einem Delta-Melder zu tun, wo Du ein widersprüchliches Bit im prinzipiell einmaligen Datenwort sich nicht selbst korrigiert. RailCom und Sx haben auch beide fehlererkennde Prüfsummen .

Hätten übliche Delta-Systeme (Information wird einmal übertragen) in der Moba keine Checksumme, keines würde zumutbar zu verwenden sein, weil man eine schlechte Leitung nicht erkennen könnte.

Zitat

---

Da waere es noetiger und genau da ist keine vorgesehen, denn wenn ein Bit kippt, dann eher da und genau hier habe ich in der Software des RC-Link effiziente Routinen eingebaut.
Fuer die angeschlossene Software besteht jederzeit die Moeglichkeit, gesendete Daten erneut abzufragen. Wenn also der Programmierer der Steuerungssoftware auf Nummer sicher gehen will laesst er sich jedes empfangene Datagramm nochmal bestaetigen.

---

„effiziente Routinen“. SoSo, solche Worten aus dem Munde eines Technikers sind für mich allenfalls Gewissens-Indikatoren.

Also zur Sache:

Zitat

---

„Für die angeschlossene Software besteht jederzeit die Moeglichkeit, gesendete Daten erneut abzufragen.“

---

Ist natürlich keine Lösung, woher soll das System den Wissen, das die Notwendigkeit besteht , die Daten erneut abzufragen.

Zitat

---

Ich bin gespannt, ob Lenz (und andere) das alles beruecksichtigen, und wenn, was das dann kosten wird

---

Ja, das Grundsystem beantwortet bereits die Frage, das konnte der Profi bereits an der Ring-Struktur („Token-Ring“ des Kabels sehen. Kommt ein Commando oder eine Meldung nicht oder verfälscht wieder beim Sender an, weiss dieser sofort, das es verschütt oder geändert wurde, und kann korriegierend wiederholen. Jedes RailCom-Bus-Device dürfte das können.

Zitat

---

Der RC-Link soll Lokadressen, CV und vielleicht irgendwann mehr aus dem auf einer Spielzeugeisenbahn befindlichen Datenbus auslesen, aufbereiten und weiterreichen und nicht die Brennstaebe eines Kernkraftwerks regeln.

---

Mhm, war gestern zum Dritten mal bei einem klugen Modellbahner wegen der Installation einer Drehscheibe. Vorher sagte er zu mir : Kommen Sie vorbei, wenn es heute nicht läuft schlagen wir mit dem Hammer drauf. Kluger Mann, der kein Bock hat, in der Moba seine Freizeit mit Protokoll-Fehlern zu verbringen.

Es waren unter anderen gleich zwei Protokoll-Fehler ursächlich für die eh schon schwierig genug einzurichtende Drehscheibe. Die Applikation hatte auf die sichernden Einrichtungen des Lenz-Protokolls ungenutzt missachtet, und so lief die DS erst mal nur am LH100, aber nicht in der Software. Ohne Protokollanalyse hätten wir das Ding wohl endgültig zerdeppert. Offiziell heisst es dann Sven Brandt funktioniert mal und mal nciht.

Wenn Übertragungfehler auch nur in minimaler Anzahl in der MoBa vorkommen, so liegt das Problem darin, das der Anwender das in der Regel nicht erkennen kann. Es sei denn, die Anwendung erkennt und meldet es. Er verliert den Spass und zieht falsche und evtl für ihn teure oder frustierende Schlüsse.

Deswegen ist nicht das unbedingt fehlerfreie Funktionieren aller Komponenten so wichtig und auch nicht hoch verfügbar möglich oder bezahlbar, aber um so mehr die Fehlervermeidung, Fehlerkennung und korrekte Meldung im für den Mobahner uneinsichtigen für sicher gehaltenen Datenbereich.

Genauso wie mit den vielen Schutzbausteinen und Sicherungen der Elektronik, die alle beim Regulären Betrieb nicht notwendig wären, so verhält es sich bei der Datenverarbeitung mit den Protokollsicherungen . Was ich nicht verstehe, wieso macht man das immer mal wieder, wo es doch wahrlich genug unaufgeklärte Probleme in allen möglichen Foren zu Anwender-Problemen gibt. Jedes Datenübetragungsproblem im RC-Link wird der Verwender später als „RailCom funktioniert nicht“ deuten. Er kann das nicht unterscheiden. Deshalb sollte es keine unerkannten Übertragungsfehler geben.

Viele Grüße
Frank

[Muenchner Kindl]

N'Abend,

Zitat

---

als doch als öffentlich wenn’s denn von Interesse ist.

---

ist mir auch lieber

Zitat

---

Naja, wie willst Du das bei einem update-fähigen System im vorhinein Wissen, das niemals im Paket ein FF vorkommen darf?

---

Gleiches gilt fuer alle anderen Werte.

Zitat

---

Nein, aber ersatzweise zigfache Wiederholungen.

---

Richtig, hier war die Herausforderung, diese auf einen korrekten, geprueften Satz zu begrenzen.
Gewissermassen kommt uebrigens sehr wohl eine Checksumme (welche auch beruecksichtigt wird): Bei jedem Datenbyte sind vier Bit gesetzt

Zitat

---

„effiziente Routinen“. SoSo, solche Worten aus dem Munde eines Technikers sind für mich allenfalls Gewissens-Indikatoren.

---

Was soll der Kaese? Es war viel Tueftelei, etwas zu schreiben, was evtl. Uebertragungsfehler ausschliesst. Jeder empfangene Satz wird mehrmals und in mehreren Instanzen geprueft, Gammeldaten sind nahezu ausgeschlossen, das hat nichts mit Gewissen zu tun.

Zitat

---

Hätten übliche Delta-Systeme (Information wird einmal übertragen) in der Moba keine Checksumme, keines würde zumutbar zu verwenden sein, weil man eine schlechte Leitung nicht erkennen könnte.

---

Aha, jetzt hast Du die fehlende Checksumme als Angriffsflaeche entdeckt . OK, kein Problem, die Checksumme war tatsaechlich kein Thema. Die Kommunikation zwischen RC-Link findet entweder ueber RS232 oder USB statt, das Ganze mit 19200 Baud (bevor Du an der langsamen Geschwindigkeit eine neue Angriffsflaeche findest, fuer die paar Bits reicht das bis in die Haut und macht weitere Sicherheitsmassnahmen unnoetig) ich habe hier (und dabei meine ich nicht den RailCom-Link) noch nie eine schlechte Leitung gesehen (und da habe ich schon sehr viel gesehen ).

Zitat

---

Ist natürlich keine Lösung, woher soll das System den Wissen, das die Notwendigkeit besteht , die Daten erneut abzufragen.

---

Das System koennte sich jeden empfangenen Satz bestaetigen lassen. Kommt eine Adresse von Detektor x an fordert die Software nochmals Detektor x an und verarbeitet die Daten erst bei Uebereinstimmung. Kein Aufwand.

Zitat

---

das konnte der Profi bereits an der Ring-Struktur („Token-Ring“ des Kabels sehen

---

Schoen, dass das der Profi sieht, ich sehe immer noch nur eine Ankuendigung... und das auch noch ohne Preis.
Allerdings hat die feine Ring-Struktur mit dem Protokoll zum PC ueberhaupt gar nichts zu tun, laut Ankuendigung befindet sich da ein USB-Kabel ohne Ringstruktur, das sollte auch der Nicht-Profi sehen

Zitat

---

Was ich nicht verstehe, wieso macht man das immer mal wieder, wo es doch wahrlich genug unaufgeklärte Probleme in allen möglichen Foren zu Anwender-Problemen gibt. Jedes Datenübetragungsproblem im RC-Link wird der Verwender später als „RailCom funktioniert nicht“ deuten. Er kann das nicht unterscheiden. Deshalb sollte es keine unerkannten Übertragungsfehler geben.

---

Haeltst Du den Anwender wirklich fuer so deppert?

[Muenchner Kindl]

Hallo nochmal,

zu der FF-Geschichte:

Ich habe mal eine CV mit dem Inhalt FF ausgelesen.

Uebertragen wird hier:

FE 04 FF FF

(FE ist die Kennung fuer CV, 04 der Detektor, FF der CV-Inhalt 255 und FF das Endezeichen)

Das Ergebnis:

(hier wurde CV5 vorher mit 255 beschrieben und die CV ausgelesen. Anschliessend habe ich den Wert 100 wieder eingetragen)

ohne jegliche Probleme

[Gast]

Hallo Thomas,

Dann wars der zitierte kluge Programmierer, der die Satzlänge aus der Kennung gelesen hat .

Warum dann überhaupt das FF am Ende ?

Und was passiert, wenn im nächsten Device-Release ein neuer Satz FX kommt, oder dieser Satz sich ggf. verlängert? und die Software weiss noch nicht wielang der ist ops: ?

Grüße
Frank

[Muenchner Kindl]

Hi,

Zitat

---

Warum dann überhaupt das FF am Ende ?

---

Das kann ich Dir alleine nicht beantworten. Wir haben das so gemacht, es war so gewuenscht, fertig.

Zitat

---

Und was passiert, wenn im nächsten Device-Release ein neuer Satz FX kommt, oder dieser Satz sich ggf. verlängert?

---

Die bisherigen Saetze werden wir nicht veraendern, ein nicht bekanntes (neues) Telegramm sollte eine gut programmierte Software ignorieren.
Gewiss werden Erweiterungen hier ausschliesslich in Zusammenarbeit mit den Softwareautoren durchgefuehrt-

[Gast]

Zitat von Muenchner Kindl

---

Hi,

Zitat

---

Warum dann überhaupt das FF am Ende ?

---

Das kann ich Dir alleine nicht beantworten. Wir haben das so gemacht, es war so gewuenscht, fertig.

Zitat

---

Und was passiert, wenn im nächsten Device-Release ein neuer Satz FX kommt, oder dieser Satz sich ggf. verlängert?

---

Die bisherigen Saetze werden wir nicht veraendern, ein nicht bekanntes (neues) Telegramm sollte eine gut programmierte Software ignorieren.
Gewiss werden Erweiterungen hier ausschliesslich in Zusammenarbeit mit den Softwareautoren durchgefuehrt-

---

Da bin ich mir auch sicher

Grüsse Frank