Der Ardunio und direkte Ausgaben vom ZusiServer über TCP

[lukmilei]

Arne, hast du es schon mal probiert, die if-Anweisung weg zu lassen und daraus einen Interrupt zu machen?

Gruß
Lukas

[F. Schn.]

So wie ich das verstehe liegt das unregelmäßige Blinken nicht an einer Zeitintensiven Bearbeitung der Anweisungen durch das Programm, sondern einfach daran, dass Zusi 2 die Daten in ungleichmäßigen Abständen sendet. Dann kann das Programm natürlich nicht mehr viel machen...


Noch eine kleine Anmerkung zu DNS:

... Hostnamenauflösung klappt nur mit DHCP. ...

Du meinst wohl DNS (Domain Name Service). Namensauflösung geht auch in einem Netz ohne DHCP (also nur mit statischen Adressen).

Jein. Windows benötigt für DNS einen geeigneten DNS-Server. Bei DHCP wird dieser über DHCP ermittelt, hat man den Computer manuell konfiguriert muss man ihn manuell einstellen. Schlägt aber DHCP fehl, fehlt natürlich der DNS-Eintrag und die Namensauflösung wird nicht klappen. Desshalb wird es auch bei IPv6 in gewissem Ausmaß DHCP geben. IP-Verbindungen klappen in diesem Fall aber dennoch, sofern die Standardwerte geeignet gewählt sind. Da ich das Problem aber schon lange nicht mehr hatte, ist mir die 169er-Ip inzwischen wieder entfallen.

[Stephan/Taschi]

So wie ich das verstehe liegt das unregelmäßige Blinken nicht an einer Zeitintensiven Bearbeitung der Anweisungen durch das Programm, sondern einfach daran, dass Zusi 2 die Daten in ungleichmäßigen Abständen sendet. Dann kann das Programm natürlich nicht mehr viel machen...

Könnte man nicht eine eigene, clientseitige PZB-Logik implementieren, die nicht auf Zusi als "Blinkgeber" angewiesen ist?

Wäre aber vermutlich Einiges an Aufwand.

[Daniel Rüscher aka Merlin]

Hmm wäre es nicht möglich mit dem Paket einen Timer zu starten?
Oder einen passenden Kondensator mit Diode zur Glättung

[Arne aus dem Norden]

Moin in die Runde,

Arne, hast du es schon mal probiert, die if-Anweisung weg zu lassen und daraus einen Interrupt zu machen?

für mein Verständnis über einen Interrupt wäre das eher kontraproduktiv.
Erstens: was passiert in dem Moment mit anderen, kontinuierlich eintreffenden Daten wie Geschwindigkeit oder Leitungsdruck?
Zweitens: wenn es so ist wie ich glaube -das das Problem bereits vor der eigentlichen Verarbeitung der Daten im Script auftritt- was würde es dann nützen?

So wie ich das verstehe liegt das unregelmäßige Blinken nicht an einer Zeitintensiven Bearbeitung der Anweisungen durch das Programm, sondern einfach daran, dass Zusi 2 die Daten in ungleichmäßigen Abständen sendet. Dann kann das Programm natürlich nicht mehr viel machen...

Die Ausgabe auf dem Arduino scheint mir schon in jedem Fall insgesamt etwas verzögert gegenüber der Anzeige auf dem Bildschirm. Ob das nun am Arduino selber, dem Sketch, oder daran das auch der Server nur in gewissen Abständen Signale liefert (waren es 400ms?) liegt weiß ich nicht wirklich.
Wäre ja auch eigentlich nicht so schlimm.
Aber gegen ein Problem mit dem Effekt des unsauberen Blinkens durch die Bearbeitungszeit des Sketches oder der Ethernetübertragung an sich spricht für mich, das dieser bei mir auch mit dem anderen Sketch über USB aufgetreten ist. Und der ist ja wirklich minimal im Umfang...

In dunkler Erinnerung habe ich jedenfalls, das es -wenn man alle Daten protokollieren läßt, die vom Server beim Arduino ankommen- für einen einzelnen LM irgendwie so aussieht:
3x "0,00"
3x "1,00"
3x "0,00"
3x "1,00"
4x "0,00"
3x "1,00"
usw.
Interessanterweise gibt es anscheinend aber auch User, die keinen Arduino verwenden und das Problem bei Ausgabe mit dem Blinken nicht haben. Jedenfalls glaube ich das unter "Ausgänge" mal gelesen zu haben...

Hmm wäre es nicht möglich mit dem Paket einen Timer zu starten

Meinst du das?

Ansonsten hab ich auch schonmal darüber nachgedacht, das es ja noch die ID 0x6a "PZB restriktiver Modus" gibt. Ev. geht das, wenn der Wert =1 ist, die Ausgabe der blauen LM unterdrücken und ein sauberes Wechselblinken mit nem Timer des Arduino selbst erzeugen, keine Ahnung ob das hinhaut...

Kennt hier jemand zufällig die genaue Frequenz des Wechselblinkens?

EDIT: Tippfehler

[Oliver Lamm]

Kennt hier jemand zufällig die genaue Frequenz des Wechselblinkens?

Hi,

nicht genau, experimentell habe ich ein usleep(500000) bei mir drin. Das sieht soweit ok aus.

Oli

[Carsten Hölscher]

Zu beachten wäre noch die wesentlich (ca. Faktor 2) langsamere Frequenz bei I80-Hardware (LZB-Ausrüstung) gegenüber I60R-Hardware (PZB90 pur).
Die Zusi 3-Werte sollte es ganz gut treffen, kann gerne nachschauen, was ich da angesetzt habe.

Carsten

[SgtMcExodus]

Vielleicht bin ich ein Einzelfall, aber mit der .NET-Lösung habe ich keine (merkliche) Verzögerung, auch nicht wenn mehrere Instanzen gleichzeitig laufen. Da mir das Ethernetboard (noch) fehlt, kann ich diesbezüglich leider nichts testen.

Jakob

[Stephan/Taschi]

Bei meinen Basteleien kam es mir auch ziemlich gleichmäßig vor... Video unter http://www.youtube.com/watch?v=ut7gtNTTmT4" target="_blank, ab ca. 0:06.

[Arne aus dem Norden]

Es wirkte bei mir mit LEDs über USB am Anfang auch alles ganz normal. Richtig aufgefallen war es mir dort erst, nachdem ich recht laute Relais zur Ansteuerung alter Deuta Leuchtmelder verwendet hatte.
Der hörbare Takt "klebte" unregelmäßig. Ich hatte dann die Hoffnung, das es mit der Ethernetgeschichte besser geht...

[lukmilei]

Hallo,

mir ist heute etwas seltsames aufgefallen. Ich habe 2 LEDs für die Türen (auf und zu). Wenn ich einen Zug fahre, der außerhalb eines Bahnhofes beginnt, bei dem also beim Start die Türen geschlossen sind, läuft alles ganz normal. Wenn ich aber einen Zug fahre, der beim Start im Bahnhof steht und die Türen offen sind, leuchtet dauerhaft die Türen offen LED. Egal welchen Zustand die Türen während der Fahrt haben, die LED zeigt immer offen. Kann das jemand von euch mal ausprobieren und mir dann berichten, ob es bei euch auch so ist? Bei meinen Versuchen war es egal, welche Strecke und welches Fahrzeug gefahren wurde.

Viele Grüße
Lukas

[lukmilei]

Problem gelöst!
Das Zauberwort heißt TB0. Alle Züge bei denen es nicht funktioniert hat, die ich probiert hatte, hatten als Abfertigungsverfahren TB0 eingetragen. Mit dieser Einstellung scheint der Arduino, oder die Zusi Ausgabe nicht zurecht zu kommen. Nachdem ich die Einstellung auf Selbstabfertigung geändert habe, geht es wie gewünscht.

Grüße
Lukas

[F. Schn.]

(http://forum.zusi.de/viewtopic.php?p=237800#p237800" target="_blank)

Wie testet ihr jeweils den Sketch? Gibt es eine andere (schnellere) Möglichkeit Zusi-Daten an den TCP Server zu senden, als immer Zusi zu starten, Strecke laden, Fahrplan laden, Zug auswählen, zur Abfahrtszeit springen und loszufahren?

Hallo,

nachdem ich jetzt im Ramen von Andreas' TCP-DLL für .Net einen "Zusi-Mock" (oder eine Art virtuelles Zusi) gebastelt habe, möchte ich nun mal nachfragen: Was sollte das Programm denn alles können? Momentan sendet es nur Geschwindigkeit und Beschleunigung mithilfe von ein paar Sinus-Funktionen.

Aber vielleicht kann man das Programm auch noch ausbauen. Vorschläge?

F. Schn.

PS: Eigentlich kann sich mit dieser DLL-Erweiterung sogar jeder seinen eigenen Zusi-Mock basteln. Ihr müsst nur die Zusi_Datenausgabe.ZusiTcpTypeMaster-Klasse verwenden.

[Stephan/Taschi]

Blöde Frage - warum ist die kompilierbefehl.txt kein Batch-File?

[F. Schn.]

Äh, ja, die Kompilierbefeh-Dateien ändern des öfteren ihre Dateiendung von .txt in .bat und zurück.

Hintergrund: Ich führe den Befehl gerne in einer ausgewachsenen Konsole aus, weil ich ihn dann mit Strg+C beenden kann, ohne dass ich gefragt werde, ob ich den ganzen Batch-Vorgang beenden will. Außerdem kann ich den Befehl in einer echten Konsole jederzeit durch die Pfeil-Auf-Taste wiederholen.

Daher kopiere ich den Text einfach in die Zwischenablage und füge ihn in der Konsole wieder ein. Und das geht mit txt halt schneller.

[lukmilei]

Hallo zusammen,

nachdem ich bis vor kurzem immer noch mit der alten Version unterwegs war, hab ich das Arduino-Skript jetzt auf die V22 geupdatet.
Der Würfel läuft ohne Probleme, jetzt bin ich dabei die anderen LEDs zum laufen zu bringen. Deshalb die Frage, ob ich den Code so richtig verstehe:

Code: Alles auswählen

case 20:
Serial.println(singlewert);
digitalWrite(ledPZB1000, singlewert != 0);
break;

Sollte Zusi eine Änderung für den Zustand des 1000 Hz-Melders haben, gibt es erst 20 für den Melder und dann den neuen Zustand aus, richtig?
Was hat es jetzt mit dem singlewert != 0 auf sich?
Ist das eine Art Verglich, aus dem digitalWrite am Ende Low oder High interpretiert?

Viele Grüße
Lukas

[Carsten Hölscher]

Code: Alles auswählen

singlewert != 0

Das ist eine Operation, die entweder WAHR oder FALSCH liefert, je nachdem ob singlewert 0 ist (falsch) oder ungleich 0 ist.
Wahr -> LED an, falsch -> LED aus

Carsten

[lukmilei]

Danke, Carsten, für die schnelle Antwort.

Ein paar Leuchtmelder funktionieren schon wieder so, wie gewünscht. Im Moment machen mir aber die Türen Probleme. Diesen Code habe ich dafür geschrieben:

Code: Alles auswählen

 case 47:
Serial.println(singlewert);
digitalWrite(ledTuerenLinks, singlewert != 0); 
digitalWrite(ledTuerenRechts, singlewert != 0);
digitalWrite(ledTuerenVerriegelt, singlewert == 0);  
break;

Es gibt insgesamt drei LEDs für die Türen: rechte und linke Seite offen und die Grünschleife, die den Zustand des LM Türen darstellen sollen. Da Zusi im Moment ja nur Türen auf oder zu liefert, sollen rechts und links gleichzeitig leuchten, wenn die Türen freigegeben sind, wenn nicht, entsprechend die LED verriegelt. Dieser Code-Abschnitt macht jedoch überhaupt nichts. Weder Probleme beim compilieren (was ja eigentlich gut ist ), noch später im Programm (und das ist das Problem).
Im ursprünglichen Code gibt es ja unter case 86 schon etliche Abfragen für die Türen. Die liefern aber anscheinend nicht den Zustand des LM, deshalb wollte ich case 47 abfragen.

Viele Grüße
Lukas

[Arne aus dem Norden]

Hi,

die meisten Fehler werden immer noch in der Konfiguration des DATA_NEEDED Teils gemacht, meist die Änderung der Paketlänge vergessen nach Erweiterung der Abfrage.

Abgesehen davon funktionieren die Türenleuchtmelder über case 86 eigentlich gut bei mir.
Wert 1 liefert Türen offen und 7 Türen verriegelt.

Ich habe auf meinem V160 Pult einen roten LM installiert der bei Türen offen leuchtet und einen gelben für ZP9, der bei einer Geschwindigkeit größer 0 nach dem anfahren erlischt.

Gruß, Arne

[lukmilei]

Hi Arne,

es hat tatsächlich oben an der Konfiguration gelegen. Ich habe mich vertippt und dadurch den falschen Wert abgefragt
Da sich ein Pin am Ethernet-Shield spontan entschieden hat abzubrechen, hat sich das mit dem Testen leider erst mal erledigt.

Ich wollte den LM abfragen, weil dann beim Zulaufen der Türen (z.B. beim 423) auch der LM blinkt. Das ist bei case 86 nicht der Fall, oder?

Viele Grüße
Lukas