HaMuKiBahner hat geschrieben:Hallo Rainer, Hallo Karl,
das Problem mit dem Nothalt konnte ich auch beobachten. Verwirrend war, dass in der Fahrstufenrückmeldanzeige dann eine solche {0} angezeigt wurde . Ich musste dann sogar die komplette Steuerung spannungslos machen um die Motoren wieder zu starten. Bezüglich der NETIO-Maske wäre es aus meiner Sicht hilfreich wenn beim betätigen der Halt-Taste der Geschwindigkeitsslider auf Null springen würde.
Gruß
Andreas
Hallo Andreas, hallo Alle,
wir kommen da (leider) an die NETIO- Grenzen - oder die der Dokumentation, weil ich nicht genug nachlesen kann. Bin im Moment mit David Eickhoff hier in einer Diskussion, was Fehler sind, was mein Mißverständnis ist.
Meiner Meinung nach hat NETIO hier einige Schwächen / Fehler, die schon öfter von Nutzern in den Foren angesprochen wurden. David wollte zum Jahresende einiges ändern.
Zu obigem Problem der Slider Rückstellung:
Hatte ich drin - Problem sind allerdings die Rückwärtsfahrten (negative Geschwindigkeit!). Ich kenne nicht die spezielle REGEX Format Notation
http://de.wikipedia.org/wiki/Regex(das ist das von David verwendete "Print" Format auf dem Screen) für die Darstellung negativer Zahlen. Hier warte ich auf seine Antwort.
Der falsche Effekt ist nämlich, dass bei der Rückmeldung der negativen Fahrgeschwindigkeit (z.B. <r156> = <-156>) der Slider nur die Zahl 156 sieht (ohne das MinusZeichen) und dann "magnetisch" auf PLUS 156 springt. In Folge wechselt die Lok die sofort wieder die Fahrtrichtung und fährt wieder vorwärts ....!
Also habe ich das wieder ausgebaut.
Ich schlage vor, wir nehmen NETIO erst einmal so wie es ist und konzentrieren uns auf unsere Projektumsetzungen. Die Smartphone Oberfläche ist ein Thema, in dem die Zeit für uns arbeitet, David wird hier ändern müssen .... und in der letzten Fassung nehmen wir Michael's ...!
David hat definitiv einen Fehler drin (bei allen Diskussionen zwischen uns beiden), der schwerwiegend ist: Man kann in NETIO ein Kommando-Ende Zeichen vereinbaren (das braucht die WLANCROC Steuerung, um zu erkennen, wann alle benötigten Kommandozeichen eines Kommandos vollständig empfangen worden sind und die Verarbeitung starten kann).
Dieses Zeichen (ich verwende <\r> - was auch landläufig als Carriage Return = Wagenrücklauf bezeichnet wird, David verwendet <\n> - was LineFeed = Zeilenvorschub heisst
http://de.wikipedia.org/wiki/Zeilenumbruch) sind immer ein einziges Byte (entweder hexadecimal 0D oder OA). Problem ist, David sendet nicht die Interpretation von <\n> oder <\r>, was die Bytes <0D> oder <0A> wäre, sondern die einzelnen Zeichen <\> und <r> oder eben <n> ... und da verlieren wir uns. Leider habe ich in der Fehlerbeschreibung auch einen Fehler gemacht ... und so haben wir am eigentlichen Problem erst einmal vorbeigeredet.
Die entsprechenden Bilder zu dem Problem (Falsch vs. Richtig) einmal hier (anhand eines 3. Steuerzeichens <\f> = FormFeed dargestellt) - muss man aber nicht verstehen!
Das eigentliche Problem passiert hier (in der .json Datei):
Unzulässigerweise verdoppelt NETIO den Backslash <\> zu <\\>, so dass die Ziffernfolge nicht als Steuerzeichen sondern als Buchstabenfolge auf dem Smartphone interpretiert wird ...! Editiert man per Hand in der .json Datei ein "\" weg, dann kommt das richtige Zeichen - siehe Screenshot zuvor.
LG vom Karl