Arduino mit Ethernetshield und Zusi TCP-Server, geht das?

[Arne aus dem Norden]

Moin,

ich bin ja leider aus dem Tal der (fast) ahnungslosen und zum ersten Mal im Leben überhaupt erst wegen Zusi vor zwei Jahren mit .NET und Arduinos konfrontiert gewesen.
Nun gibt es ja -dankenswerterweise- hier im Forum schon eine (zumindest für die Ausgabe) größtenteils auch gut laufende Lösung für den Arduino die auch die meisten hier ja ans laufen bekommen (Zusi <-> Zusi TCP Server <-> .NET Client <-> Arduino).

Ich frage mich in meiner Unwissenheit trotzdem seit längerem, ob man auf die .NET-Geschichte nicht auch verzichten könnte.
Für den Arduino gibt es ja inzwischen spottbillige Ethernetshields (http://www.ebay.de/itm/Ethernet-Schild- ... 1198196897 und es scheint recht einfach, damit einen Webserver zu basteln: http://projects.lb-home.de/2013/01/eine ... erstellen/

Könnte man damit den Arduino direkt mit dem Zusi-TCP-Server verbinden?
Wenn möglich: hat das schonmal jemand gemacht und würde hier ggf. Beispielcode veröffentlichen?

Viele Grüße, Arne

[Andreas Karg]

Ich bin kein Arduino-Experte, aber auf Basis des Webserver-Textes würde ich sagen, dass sowas ziemlich sicher gehen müsste. Das Z2-Protokoll ist im Grunde recht simpel. Problematisch könnte sein, dass Zusi viele Daten (sinnlos) als Fließkommazahlen überträgt. Die 8-Bit-Atmels haben Hardwareunterstützung weder für Fließkommatypen an sich, noch für Datentypen > 8 Bit (Ausnahme: in Einzelfällen gibts Operationen mit 16 Bit). Folglich müssen entsprechende Operationen in Software durchgeführt werden. Das macht zwar der Compiler automatisch für dich, aber es ist zieeeeemllllliiiiiiiccchhhh laaaaaaaannggggsaaaaaaaam. Vielleicht reicht der Rechendampf des Arduino aber aus, müsste man mal ausprobieren.

[Arne aus dem Norden]

Ich bin kein Arduino-Experte, aber auf Basis des Webserver-Textes würde ich sagen, dass sowas ziemlich sicher gehen müsste.

Hi Andreas,

ich hatte ja gehofft, das du oder nonesense sich zum Thema melden würden.
EdwindDB hat in seinem E10 Pult ja glaub ich auch schon eine Ethernet-Verbindungsvariante laufen, aber ich weiß nicht mehr ob er mit Arduino-Prozessoren arbeitet.
Da ich den Arduino für die optimale Basis halte und Zusi 3 eh einen Server und TCP-in beinhalten wird, würde das ganze doch eigentlich jetzt und für die Zukunft Sinn ergeben...

Hättest du Lust, dir da mal ein paar Gedanken zu machen? Hast du einen Arduino? Wenn die Shields um die 10 Euro liegen kann ich dir ansonsten auch eins zukommen lassen, bestellen würde ich ja eh um mich auch an das Thema ranzutasten...
Nur hab ich halt bislang nullkommgarkeine Ahnung vom dem, was der Server da so treibt...

Gruß, Arne

[Andreas Karg]

Arduino hab' ich keinen - und schon chronisch zu viele Projekte. Jucken tät's mich ja schon, aber ich kenn' mich. :/

[nonesense]

ich hatte ja gehofft, das du oder nonesense sich zum Thema melden würden.

Ich habe selber kein Ethernetshield.
Zur Zeit bin ich mit vielen anderen privaten Projekten ausgelastet. Da steht z.B. ein Umzug an.
Irgend wann werde ich mich auch mal wieder zum Thema zurückmelden.

Gruß
Jens

[Arne aus dem Norden]

OK,

es scheint dann ja zumindest keine bereits existierenden Lösungen in dieser Richtung von anderen hier zu geben.
Projekte hab ich selber auch zu viele, allerdings wäre eine direkte TCP-Lösung ja auch erst mit Zusi3 richtig interessant (wegen Eingaben). Deswegen spielt Zeit jetzt auch keine so große Rolle.

Ich hab mir auf jedenfall heute ein Shield aus eBay für 9 Euro irgendwas bestellt, wird eh wohl zwei bis vier Wochen dauern bis das aus China da ist.
Die auf smartcoder.net nicht mehr auffindbaren Zusi-TCP-Server Tools/Protokolle habe ich zum Glück teilweise auf http://zusitoolset.berlios.de/ noch finden können. Vielleicht check ich das ja doch noch und krieg auch alleine irgendwas zum laufen. Ich werde hier berichten...

Gruß, Arne

[F. Schn.]

Prinzipiell kann man eigentlich alle Platformen, die irgendwie das TCP-Protokoll unterstützen, mit dem TCP-Server verbinden.

Problematisch könnte sein, dass Zusi viele Daten (sinnlos) als Fließkommazahlen überträgt. ...

Die meisten dieser "Sinnlosen" Zahlen sind in der Praxis Wahrheitswerte (bool), die kann man bei Bedarf auch frühzeitig zu bools umwandeln. Für andere Werte, wie z.B. die Geschwindigkeit, halte ich floats durchaus für Sinnvoll. Zusi weiß ja nicht, wie groß der Wertebereich deines Tachos ist und mit welcher Genauigkeit das Tool arbeiten möchte.

Bietet der Audorino denn eine Möglichkeit, die IP und den Port dynamisch einzustellen, oder muss man die dann "fest" einprogrammieren?

[Arne aus dem Norden]

Bietet der Audorino denn eine Möglichkeit, die IP und den Port dynamisch einzustellen, oder muss man die dann "fest" einprogrammieren?

Dazu konnte ich das hier auf die schnelle finden:
http://books.google.de/books?id=CSei8-a ... ip&f=false

Ich hoffe, der Link geht...

[Andreas Karg]

Die meisten dieser "Sinnlosen" Zahlen sind in der Praxis Wahrheitswerte (bool), die kann man bei Bedarf auch frühzeitig zu bools umwandeln

Bools als Float sind tatsächlich noch das kleinste Problem, das geht sogar mit einem einfachen Binärvergleich, weil laut IEEE 754 eine Float-0 einer Binär-0 entspricht.

Ich wollte eigentlich auf zweierlei hinaus:
1. Int als Float: Das müsste diverse Schalter betreffen, wie z.B. Fahrschalter, FbV, etc. Hier sollte man für eine sinnvolle Verarbeitung nach (u)int8_t casten.
2. Echte Fließkommazahlen: Zur Ansteuerung von Instrumenten o.Ä. muss man seine Fließkommawerte in einen sinnvollen Wertebereich bringen. Für eine klassische Lookup-Tabelle wäre das z.B. eine Fließkomma-Multiplikation zur Skalierung, evtl. eine Addition zum Zentrieren und dann eine Konvertierung nach Ganzzahl, wobei man die Addition vermutlich schon im Integerbereich machen kann.


Hier stehen ein paar Zahlen zu Fließkommamultiplikationen. Wir sprechen hier offenbar von ~2000 Taktzyklen pro Multiplikation. Bei 1 MHz entspricht das 2ms, bei 4 MHz 0,5ms und bei 16 MHz 0,125ms.

Zusi schickt etwa alle 100ms neue Daten. Im schlimmsten Fall müssen alle echten Single-Werte empfangen und verarbeitet werden - das sind, wenn man die Schalter mal mitzählt, 38 Stück. Wenn der Arduino mit 16 MHz läuft, komme ich dazu auf 4,75ms pro komplettem Datensatz nur für die Skalierung. Das sollte eigentlich genug Zeit übrig lassen für die Weiterverarbeitung. Müsste man mal sehen.

[Oliver Lamm]

Hi,

ich habe zwar keine Erfahrung mit dem Arduino, aber ich hatte das schon auf einem 8bit Atmel Mega644 laufen ... das sollte der Arduino locker können.
Aktuell läuft bei mir ein omap3530, aber das ist schon Luxus.

Oli

[ImmoBirnbaum]

Hallo Arne,

das sollte wohl hinhauen. Ich verwende auch einen 8-bit ATMEGA von Atmel (AT90CAN128) mit dem ENC28J60 als Ethernet-Anbindung.

Ich habe mich hier in der Vergangenheit mehrfach an Diskussionen beteiligt über die - ich sage das jetzt mal direkt - hirnamputierte Design-Entscheidung, 32-bit-Floats als Universaldatentyp zu verwenden und darüber, dass bei der Entscheidung zugunsten von TCP anstelle von UDP "ausgewachsenen" Systemen der Vorzug über Embedded-Anwendungen gegeben wurde. Da diese Diskussionen letztenendes nichts bewirkt haben, habe ich also eine minimale TCP-Socket-Schnittstelle für den kleinen 8-bitter selbst implementiert. Dieser Teil könnte mit einem Arduino wohl wegfallen, da der Controller auf dem Ethernet-Shield das TCP-Protokoll in Hardware umsetzt.

Für die Daten von Leuchtmeldern und einfachen Status-Flags gilt wie bereits erwähnt: hier kann man den Floating Point-Datentyp einfach ignorieren und einen Binärvergleich auf Null / ungleich Null machen, das ist Performance-mäßig OK. Schalterstellungen müssen in der Tat umgecastet werden. Eine Hand voll Werte (Geschwindigkeit, Zugkraft etc.) werden auch bei mir durch die FPU-Emulation gejagt. Ich optimiere dann nach Empfang eines Datenpakets vom TCP-Server sämtliche Werte auf ihren minimalen Datentyp runter, bevor die Daten auf den CAN-Bus rausgehen, so dass letztendlich fast alle Daten (die 1 oder 2 Strings, die es zu empfangen gibt, habe ich nicht angefordert) in 9 CAN-Telegramme und somit 72 Bytes reinpassen. Das dafür zu verarbeitende TCP-Paket ist um ein vielfaches größer.

Fazit:
- läuft.
- auf dem Arduino sogar noch mit etwas weniger Aufwand wg. der TCP-Fähigkeit des Ethernet-Controllers.

Für die Zukunft liegt aber auch schon ein Raspberry Pi auf meinem Schreibtisch, der momentan noch auf eine Anbindung an den CAN-Bus wartet...

[Arne aus dem Norden]

Für die Daten von Leuchtmeldern und einfachen Status-Flags gilt wie bereits erwähnt: hier kann man den Floating Point-Datentyp einfach ignorieren und einen Binärvergleich auf Null / ungleich Null machen, das ist Performance-mäßig OK.

Fazit:
- läuft.
- auf dem Arduino sogar noch mit etwas weniger Aufwand wg. der TCP-Fähigkeit des Ethernet-Controllers.

Hi,

danke auch dir für die Rückmeldung. Es scheint ja wirklich Sinn zu machen, diese Richtung weiter zu verfolgen. Mit der Doku des Servers dürfte der Verbindungsaufbau und ggf. Abfrage der LM dann vielleicht sogar von mir hinzukriegen sein. Ich schätze allerdings, bei komplexeren Umwandlungen von Datentypen werde ich mich fürchterlich durch Unwissenheit blamieren

Für die Zukunft liegt aber auch schon ein Raspberry Pi auf meinem Schreibtisch, der momentan noch auf eine Anbindung an den CAN-Bus wartet...

Von den I/O her betrachtet ist der Raspberry Pi aber doch für ein Fahrpult eigentlich keine Alternative zum z.B. Arduino Mega 2560, oder?

[Stephan/Taschi]

Der Raspberry Pi kann aber eine zusätzliche Abstraktionsebene zwischen dem Arduino und dem TCP-Server bieten.

[Arne aus dem Norden]

Der Raspberry Pi kann aber eine zusätzliche Abstraktionsebene zwischen dem Arduino und dem TCP-Server bieten.

OK, aber dann haben wir ja wieder was ähnliches wie jetzt mit dem .NET Client, der vom Server zum USB-Port des Arduino kommuniziert wenn ich das richtig sehe. Sogar mehr, weil eine Hard- und Softwarekomponente dazwischen.

Mein Hintergedanke ist eher, ob man das nicht alles sogar vereinfachen könnte. Man stelle sich vor, es würde hier ein Script zum Download für z.B. den Arduino Mega geben. Ich weiß, jeder baut mehr oder weniger ein anderes Pult. Aber vielleicht die ersten PINs standardmäßig mit fest definierten Ausgaben.
Script auf den Mega laden, Shield draufstecken, mit Ethernetkabel verbinden und man hat am Arduino PIN 1 bis 6 z.B. Leuchtmelder PZB, PIN 7 für Tacho 0-5V, PIN 8, 9, 10 für Servos der drei Manometer usw. usw.
Grundfunktionalität halt, so wie jetzt schon im vorhandenen .NET Script. Die 54 I/O des Mega mit PWM und Analogeingängen sollten das doch in jedem Fall abdecken.
Ausbaubar nach belieben, aber man müßte nur noch an einem Script herumschrauben und für Zusi 3 mit TCP-In eigentlich ohnehin ein unverzichtbarer Weg direkt über Ethernet...

Aber vielleicht gibt es hier ja auch garkeinen Bedarf, weil die meisten viel fitter sind im Programmieren als ich und sich sowieso ihre eigene Ideallösung problemlos stricken können oder die Wünsche eh zu individuell sind

Oder es wäre mit einem Script auf dem Arduino alleine eben doch nicht zu leisten...

[Stephan/Taschi]

Nützt aber z. B. mir nix, weil ich keinen Mega, sondern einen Uno verwende und mich daher mit Shiftregistern rumschlagen muss.

[Arne aus dem Norden]

Nützt aber z. B. mir nix, weil ich keinen Mega, sondern einen Uno verwende und mich daher mit Shiftregistern rumschlagen muss.

Dafür gibt es aber eigentlich überhaupt keinen Grund. Z.b. ein Saintsmart Arduino Clone (100% kompatibel) kostet ungefähr die Hälfte von einem originalen Uno mit ein paar Portexpander-ICs... Siehe Screenshot von eBay im Anhang.
Wenn man Glück hat, bekommt man einen Saintsmart Mega und ein Ethernet-Shield mit W5100 für zusammen gut 25 Euro.
Und wenn die PINs des Mega doch nicht reichen sollten, kann der ganze UNO über I2C noch als Portexpander laufen. Das wäre -selbst bei meinen geringen Kenntnissen- auch noch einfacher umzusetzen als Schieberegister zu stricken...

[F. Schn.]

Im schlimmsten Fall müssen alle echten Single-Werte empfangen und verarbeitet werden - das sind, wenn man die Schalter mal mitzählt, 38 Stück.

Okay... Ich muss zugeben, ich hatte mit westentlich weniger echten Fließkommazahlen gerechnet. Aber ich habe noch mal nachgeschaut und laut deinem Dokument sind es tatsächlich nur 53 bools, davon 5 im Dokument als "bool as Int" gekennzeichnet, aber 38 echte Single-Werte. (Beides zuzüglich der beiden Hybridwerte Zugart M und U, die lediglich im PZ80-Modus Single-Werte sind.) Hinzu kommt noch der Schalter für die Fahrtrichtung (sowie das PZB-System, die Bremsstellungen und die Türen, die du jedoch als Int markiert hast.)

die 1 oder 2 Strings, die es zu empfangen gibt, habe ich nicht angefordert

Fünf, die ich jedoch alle für Fahrpulte ungeeignet halte.

Ich habe mich hier in der Vergangenheit mehrfach an Diskussionen beteiligt über die - ich sage das jetzt mal direkt - hirnamputierte Design-Entscheidung, 32-bit-Floats als Universaldatentyp zu verwenden

Also für die Bools sehe ich das ja ein, aber in den restlichen Datentypen gibt es aus meiner Sicht nur den Fahrschalter, die Fahrstufe und die drei Uhrzeiten, die man in einen Ganzzahldatentyp packen könnte. Für die anderen Typen sind aus meiner Sicht durchaus Kommadatentypen angebracht.

zugunsten von TCP anstelle von UDP

Bei UDP muss man allerdings den zu erwartenden Datenverlust durch eine geeignete Verhaltensweise von Zusi wieder ausgleichen...

@Stephan: Stuttgart 21

[Carsten Hölscher]

Mal so als Hintergrundinfo zu den float-Werten: Entstanden ist die Schnittstelle mal als Einzelwunsch eines Fahrpultbauers nach dem Motto "soll bei Zusi möglichst wenig Arbeit verursachen". Darum ist Zusi auch nur Client und der Server ne eigene Software. Und da wurden die Daten in einem float-array gesammelt und fertig war's...

Carsten

[F. Schn.]

Hat sich dafür aber als erstaunlich robust und langatmig erwiesen.

Steht die TCP-Schnittstelle von Zusi 3 eigentlich schon?

[Carsten Hölscher]

Es gibt eine, aber ich möchte mir noch die Möglichkeit offen halten, ein paar Sachen zu verbessern, darum wird's noch nicht veröffentlicht.

Carsten