Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
Arne, hast du es schon mal probiert, die if-Anweisung weg zu lassen und daraus einen Interrupt zu machen?
Gruß
Lukas
Gruß
Lukas
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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:
Noch eine kleine Anmerkung zu DNS:
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.Max Senft hat geschrieben:Du meinst wohl DNS (Domain Name Service). Namensauflösung geht auch in einem Netz ohne DHCP (also nur mit statischen Adressen).Daniel Rüscher aka Merlin hat geschrieben:... Hostnamenauflösung klappt nur mit DHCP. ...
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
-
- Beiträge: 1050
- Registriert: 30.10.2009 11:40:27
- Aktuelle Projekte: Zusi boykottieren, gelegentlich mal gesperrt sein
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
Könnte man nicht eine eigene, clientseitige PZB-Logik implementieren, die nicht auf Zusi als "Blinkgeber" angewiesen ist?F. Schn. hat geschrieben: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...
Wäre aber vermutlich Einiges an Aufwand.
- Daniel Rüscher aka Merlin
- Beiträge: 2294
- Registriert: 23.01.2003 02:25:50
- Aktuelle Projekte: Aktuell keine
- Wohnort: Traunreut
- Kontaktdaten:
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
Hmm wäre es nicht möglich mit dem Paket einen Timer zu starten?
Oder einen passenden Kondensator mit Diode zur Glättung
Oder einen passenden Kondensator mit Diode zur Glättung
How to waste bits in a My SQL Database?
Like this.....
Like this.....
- Arne aus dem Norden
- Beiträge: 721
- Registriert: 25.12.2011 14:28:21
- Aktuelle Projekte: Fahrpult VT628/VS928 - Versuch eines Nachbaus
- Wohnort: Str.Km "6,8" der Kiel-Schönberger Eisenbahn (DB-Str. 9107)
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
Moin in die Runde,
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?
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...
EDIT: Tippfehler
für mein Verständnis über einen Interrupt wäre das eher kontraproduktiv.lukmilei hat geschrieben:Arne, hast du es schon mal probiert, die if-Anweisung weg zu lassen und daraus einen Interrupt zu machen?
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?
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.F. Schn. hat geschrieben: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...
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...
Meinst du das?Daniel Rüscher aka Merlin hat geschrieben:Hmm wäre es nicht möglich mit dem Paket einen Timer zu starten
Kennt hier jemand zufällig die genaue Frequenz des Wechselblinkens?Dude hat geschrieben: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...
EDIT: Tippfehler
Zuletzt geändert von Arne aus dem Norden am 16.02.2014 13:32:43, insgesamt 1-mal geändert.
Mein Baubericht von der echten Bahn zum Schönberger Strand:
https://www.facebook.com/Hein-Sch%C3%B6 ... 601976323/
https://www.facebook.com/Hein-Sch%C3%B6 ... 601976323/
- Oliver Lamm
- Beiträge: 3102
- Registriert: 04.01.2002 15:02:17
- Aktuelle Projekte: Aachen - Neuss für Zusi3
- Wohnort: Essen
- Kontaktdaten:
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
Hi,Kennt hier jemand zufällig die genaue Frequenz des Wechselblinkens?
nicht genau, experimentell habe ich ein usleep(500000) bei mir drin. Das sieht soweit ok aus.
Oli
Oliver Lamm
mail(AT)oliverlamm(DOT)de
mail(AT)oliverlamm(DOT)de
- Carsten Hölscher
- Administrator
- Beiträge: 33442
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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
Die Zusi 3-Werte sollte es ganz gut treffen, kann gerne nachschauen, was ich da angesetzt habe.
Carsten
- SgtMcExodus
- Beiträge: 220
- Registriert: 27.03.2012 17:56:48
- Aktuelle Projekte: Studium
- Wohnort: Berlin
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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
Jakob
-
- Beiträge: 1050
- Registriert: 30.10.2009 11:40:27
- Aktuelle Projekte: Zusi boykottieren, gelegentlich mal gesperrt sein
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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
- Beiträge: 721
- Registriert: 25.12.2011 14:28:21
- Aktuelle Projekte: Fahrpult VT628/VS928 - Versuch eines Nachbaus
- Wohnort: Str.Km "6,8" der Kiel-Schönberger Eisenbahn (DB-Str. 9107)
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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...
Der hörbare Takt "klebte" unregelmäßig. Ich hatte dann die Hoffnung, das es mit der Ethernetgeschichte besser geht...
Mein Baubericht von der echten Bahn zum Schönberger Strand:
https://www.facebook.com/Hein-Sch%C3%B6 ... 601976323/
https://www.facebook.com/Hein-Sch%C3%B6 ... 601976323/
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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
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
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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
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
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
(http://forum.zusi.de/viewtopic.php?p=237800#p237800" target="_blank)
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.
Hallo,Sparky-CH hat geschrieben: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?
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.
Zuletzt geändert von F. Schn. am 25.08.2014 18:31:30, insgesamt 2-mal geändert.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
-
- Beiträge: 1050
- Registriert: 30.10.2009 11:40:27
- Aktuelle Projekte: Zusi boykottieren, gelegentlich mal gesperrt sein
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
Blöde Frage - warum ist die kompilierbefehl.txt kein Batch-File?
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
Ä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.
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.
Diese Signatur möchte folgendes bekannter machen: ZusiWiki · ZusiSK: Streckenprojekte · YouTube: Objektbau für Zusi · euirc: Zusi-Chat
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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:
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
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;
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
- Administrator
- Beiträge: 33442
- Registriert: 04.07.2002 00:14:42
- Wohnort: Braunschweig
- Kontaktdaten:
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
Code: Alles auswählen
singlewert != 0
Wahr -> LED an, falsch -> LED aus
Carsten
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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:
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
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;
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
- Beiträge: 721
- Registriert: 25.12.2011 14:28:21
- Aktuelle Projekte: Fahrpult VT628/VS928 - Versuch eines Nachbaus
- Wohnort: Str.Km "6,8" der Kiel-Schönberger Eisenbahn (DB-Str. 9107)
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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
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
Mein Baubericht von der echten Bahn zum Schönberger Strand:
https://www.facebook.com/Hein-Sch%C3%B6 ... 601976323/
https://www.facebook.com/Hein-Sch%C3%B6 ... 601976323/
Re: Der Ardunio und direkte Ausgaben vom ZusiServer über TCP
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
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