STM32F4 und "Reaktionszeit" per Ethernet

Kein F4 sondern ein F107/STE100 mit LWIP mit 100 Mbit/s Ethernet:

X:\>ping n64

Pinging n64.local [192.168.1.64] with 32 bytes of data:
Reply from 192.168.1.64: bytes=32 time<1ms TTL=255
Reply from 192.168.1.64: bytes=32 time<1ms TTL=255
Reply from 192.168.1.64: bytes=32 time<1ms TTL=255
Reply from 192.168.1.64: bytes=32 time<1ms TTL=255

Ping statistics for 192.168.1.64:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

ICMP ist zwar kein TCP, aber auffaellig grosse Zeiten kann ich nicht
erkennen...

TCP garantiert kein Zeitverhalten.

@./.
Klingt gut. Danke. LWIP ist auch einer meiner möglichen Stacks. Außerdem 
schaue ich mir noch uIP an. Aber wenn ich an die Zukunft denke, möchte 
ich mich wegen IPV6 nicht mit Contiki beschäftigen müssen, um den TCP/IP 
Stack rauszuziehen ;-)

@PIP
Ist mir klar. Aber da ich voraussichtlich der einzige auf dem 
"Bus"(SubNetz) sein werde, hoffe ich, dass ich im Schnitt keine Probleme 
bekomme. Bei meiner Anwendung habe ich keine Probleme, wenn mal ein 
Paket "später" ankommt, aber "im Schnitt" sollte die Reaktion 
ausreichend flott sein.

Gibt es eine Regelschleife, oder warum kannst Du nicht ein paar hundert 
Kommandos auf einmal übertragen, die dann sequentiell ausgeführt werden?

Ich MUSS nicht mehrere Kommandos auf einmal übertragen. Ich hab nicht 
mehr.
Ich hab insgesamt 12-15 Achsen und noch einige "Logikfunktionen".
Ein kompletter Ablauf dauert minimal 1sec. D.h. 15x Kommando "Fahr 
irgendwo hin" und 15x eine Rückantwort "Bin am Ziel". Dazwischen 
vielleicht noch 20-30 andere Kommandos. Also nicht wirklich viel 
Traffic, aber eine Latenz von z.B. 10ms macht mich schon mal 60% 
langsamer :-)

Sequentiell: Beim Losfahren weiß ich noch nicht genau wo meine 
Zielposition ist. D.h. die Zielposition wird erst On-The-Fly geändert.

Danke für den Tipp. Werde ich mir anschauen, wenn ich meinen eigene 
Firmware am laufen haben. Bin nur bei Antwortzeiten von 40ms etwas 
erschrocken vom Demoboard etwas erschrocken.

Ich habe TCP und UDP auf einem LPC1769 genutzt, das reagiert 
pfeilschnell, <1 ms, beim STM wird das ähnlich sein. Der Ethernet Teil 
ist ja im Prozessor und die ankommenden Daten landen per DMA direkt im 
µC Speicher und müssen nicht über externe Schnittstellen oder hin- und 
herkopiert werden.
Beim TCP gibt es den 'Nagle Algorithmus', der macht sich bei kleinen 
Datenpaketen bemerkbar. In uiP ist das aber nicht implementiert, lwIP 
vermutlich auch nicht. Problematischer ist da eher die Gegenseite, da 
muss man beim Socket aufmachen die Option TCP_NODELAY setzen.
UDP ist auch eine Alternative, da sollte aber ein Telegrammzähler zur 
Überwachung und eventuell ein Resend Mechanismus rein. Bei 
Punkt-zu-Punkt im LAN ist das sehr zuverlässig, Verluste gibt es nur 
wenn es zu schnell geht und ein Teilnehmer keine Datenpuffer mehr hat.

Pepe schrieb:
> Bin nur bei Antwortzeiten von 40ms etwas
> erschrocken vom Demoboard etwas erschrocken.

läuft da eventuell ein RTOS oder eine Warteschleife das die Daten in 
diesem langsamen Zyklus verarbeitet werden?

@Jojo
Kann schon sein. Kann ich aber nicht sagen.
Hab das Ganze ( Board mit Demo-Firmware ) von einem Kollegen übernommen.
Der hat mit diesem Thema Mitte 2014 angefangen und nicht wirklich was 
dokumentiert. Und jetzt ist er nicht mehr in der Firma...

Ich schalte das Ding ein, probiere etwas rum und erhalte Antwortzeiten 
jenseits von Gut und Böse. Da ich gar nichts nachvollziehen kann, werde 
ich erst genaueres wissen, wenn ich meinen eigenen TCP/IP Stack am 
laufen habe.

na ja, wenn die Quellen noch vorhanden sind könnte man mal pauschal nach 
'wait' oder 'delay' suchen, für 40 ms Reaktion muss man den µC schon 
recht kräftig bremsen (wenn der nicht noch mit anderen Interrupts oder 
Aufgaben zugeballert wird).

Quellcode? Schön wär's. Ich hab' gar nichts. :-(

Wie schon gesagt: Ich muss da nochmal bei Null anfangen. Aber wenigstens 
ist mir jetzt klar, dass meine Vorstellungen funktionieren müssten.

Pepe schrieb:

> Bin gerade am überlegen, ob ich eine bestehende Maschinensteuerung nicht
> mehr über die bisherigen PCIe Controller etc. sondern nur noch über
> Ethernet (100MB). Alles Eigenentwicklung, keine SPS o.Ä.

OK, soweit klar und auch ein durchaus verständlicher Wunsch.

> Ich könnte mir vorstellen für die Befehlsübertragung TCP Pakete mit
> ASCII Zeichen zu verwenden.

Dazu besteht zwar kein direkter Zwang, erleichtert aber sicher das 
Debuggen, warum also nicht?

> Wenn ich
> die "Reaktionszeit" vernachlässige reichen mir die 115Kb einer RS232
> aus.

Das allerdings ist eine ziemlich bescheuerte Aussage, zumindest ist sie 
bescheuert formuliert. Was du vermutlich sagen wolltest: Die 
Kanal-Grundlast(netto) beträgt ca. 115kb/s. Das ist ein wichtiger Wert.

> Aber ich benötige möglichst eine schnelle Reaktionszeit, weil es darum,
> dass die Maschine möglichst schnell wieder fährt.

Tja, dann mußt du erstmal definieren, was genau du mit "Reaktionszeit" 
meinst. Vermutlich ist die gemeint, die sich sinngemäß darstellen läßt 
mit der Formulierung:
"Maschinenhardware erkennt eine bestimmte Situation->übermittelt diese 
Tatsache über den langsamen Kanal->Steuerung kalkuliert ihr nächstes 
Maschinenkommando als Reaktion auf den Eingang des Signals->verschickt 
dieses Kommando über den langsamen Kanal->Maschinenhardware analysiert 
das Kommando und startet dessen Abarbeitung"

Wie man leicht erkennen kann, setzt sich die Reaktionszeit (grob) aus 
fünf Komponenten zusammen, wobei die Kanaleigenschaften zweimal 
eingehen, die Bearbeitungsageschwindigkeit der Maschinenhardware (bzw. 
des lokalen Prozessors dort) ebenfalls zwei mal, der Master-Rechner 
hingegegen nur ein mal.

> Wir setzen diverse STM32's ein und würde deshalb bei denen bleiben
> wollen.

Jo mei... Wie oben herausgearbeitet, geht gerade das eigentlich nur 
einfach in die Kalkulation der Reaktionszeit ein. Vermutlich hätte es 
auch irgendein 8Bitter genauso getan, aber egal, wenn die STM32-Lösung 
fertig ist, wäre es definitiv Unsinn, auf irgendwas anderes umzusteigen.

Da muß dann wohl nur noch die Software so optimiert werden, wie man das 
bei den knappen Resourcen von vorherein getan hätte, nämlich so, daß sie 
die "Reaktionszeit" (zzgl. der wahrscheinlich viel größeren Laufzeiten 
der mechanischen Abläufe) sinnvoll nutzt, um beim Eintritt des nächsten 
Ereignisses das nächste Kommando idealerweise für jede denkbare Variante 
von Zustandsänderung schon fix und fertig berechnet zum Versand 
vorliegen zu haben, so das bei Eingang des Ereignisses nur noch 
ausgewählt und versandt werden muß.

Wie schon gesagt: das ist der Idealfall, fast niemals ist es nötig oder 
wünschenswert, den in seiner reinsten Form umzusetzen. Einige 
Maschinensignale wird man vor allen anderen behandeln müssen (Not-AUS 
z.B. sowie alle Signale, die dazu beitragen).

In aller Regel wird es für eine Maschinensteuerung genügen, jeweils den 
worst case (bezüglich des Rechenzeitbedarfs auf dem Steuerrechner) 
vorherzuberechnen, max. noch die teuerste Alternative.

> Bevor ich mich jetzt hinsetze und einen TCP/IP-Stack implementiere,
> wollte ich wissen welche Reaktionszeiten ich in etwa in der Realität zu
> erwarten haben?

Das fragst du uns? Nur du kannst das wissen! Wir wissen fast nix vom 
System...

@c-hater
Ich finde es immer wieder amüsant, wie unterschiedlich die Sichtweise 
der verschiedenen Forenteilnehmer ist. Danke für die detaillierte 
Aufbereitung und Zerlegung meiner Aufgabenstellung. Ich frage mich jetzt 
wirklich wie ich die letzten 30 Jahre davon leben konnte, Maschinen zu 
bauen...