Hallo. 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.Ä. Ich könnte mir vorstellen für die Befehlsübertragung TCP Pakete mit ASCII Zeichen zu verwenden. Ich habe keine großen Datenmengen. Wenn ich die "Reaktionszeit" vernachlässige reichen mir die 115Kb einer RS232 aus. (Wenn ein Kommando abgesetzt wurde, passiert einige 10ms nichts bis z.B. eine Fahrt beendet wurde.) Aber ich benötige möglichst eine schnelle Reaktionszeit, weil es darum, dass die Maschine möglichst schnell wieder fährt. Wir setzen diverse STM32's ein und würde deshalb bei denen bleiben wollen. Ich habe schon einige Tests auf meinem MCBSTM32F400 gefahren, aber da komme ich auf Reaktionszeit die wesentlich zu langsam sind. Gut bei der Test-Firmware ist auch ein WebServer im Hintergrund. Also parsen etc. Dies würde ja bei einer einfachen Paketstruktur (wenige ASCII Zeichen) wesentlich schneller werden. 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? Danke schon mal.
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...
@./. 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.
Pepe schrieb: > Ich habe schon einige Tests auf meinem MCBSTM32F400 gefahren, aber da > komme ich auf Reaktionszeit die wesentlich zu langsam sind. Gut bei der > Test-Firmware ist auch ein WebServer im Hintergrund. Also parsen etc. Wenn das TCP war: Dort gibt es ein bekanntes Problem mit ACKs auf µC Implementationen. Das würde sich (gegen moderne Betriebssysteme) mit Roundtrip Zeiten um 500ms bemerkbar machen. Teste mal mit UDP/ICMP. Bei Ping z.B. kann man Paketgrößen angeben.
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.