-> Hier kostenlos registrieren
Hallo zusammen
Ich weiss ehrlich gesagt nicht so recht, zu welchem Forum das am besten passt...
In einer Maschine haben wir eine B&R Steuerung und P3 Servor-Antriebe und einem APC 3300. Als man mich (ich komme aus der Embedded-Welt) dazu verdonnert hat, die von unseren externen Entwicklern umgesetzten Prozesse zu analysieren, hat mich beinahe der Schlag getroffen. Bevor ich den Leuten von ihrer "Leistung" berichte, möchte ich ein paar Vergleichswerte haben. Denn wie gesagt, ich kenne mich mit SPS nicht aus.
Die Zahlen und Informationen, die ich mittlerweile zusammengetragen habe:
Latenz = tin (was das auch immer sein soll) + 2 PowerLink + 1 Task + 2 PowerLink + 1 P3 + tout (auch nicht weiter bekannt)
PowerLink läuft mit 1.6ms, Task-Zeit ist 3.2ms und das P3 arbeitet mit 400us. Wenn man also die obige Kette zusammenzählt, sind das mindestens 10ms "Wartezeit", wenn eine Achse auf Position gefahren ist, und bis dann schlussendlich die nächste Achse von dieser Position "getriggert" wird.
Als ich ein paar Traces aufgezeichnet habe (ich sag nur soviel: bin ich froh, dass ich mit der Toolchain nicht arbeiten muss, denn zum State of the Art in der Embedded-Welt sind da gefühlt 30 Jahre unterschied. Aber das ist ein anderes Thema und tut nichts zur Sache) habe ich Wartezeiten zwischen solchen "Achs-auf-Achs" Aktionen im Bereich von 20-60ms gemessen (nicht einmal konstant??). Und da sind in der FSM nur 2 States (Übergangsbedingung ist das Erreichen der Position).
Da stellte sich für mich die Frage, wer da die Bremse vergessen hat zu lösen
. Über die 10ms Latenz kann man ja noch diskutieren (obwohl das schon sehr grenzwertig ist, denn eine simple TCP/IP Verbindung ohne RealtimeOS bei Millionen von Internet-Teilnehmern kann in die gleiche Region kommen), aber bei 60ms ist dann definitiv Schluss mit meinem Verständnis.
Vor allem wenn da 30ms auf der Position verharrt wird, 60ms für das kurze Verfahren benötigt werden und dann wieder 30ms gewartet wird. Über den gesammten Prozess ist die Anlage so 20-25% mit Warten "beschäftigt".
Ich sehe momentan folgende Ansätze:
- Akzeptieren, da das wohl so ist (desswegen die Frage nach Vergleichswerten)
- Die Programmierer herzitieren, sodass sie sich mit der Analyse ihrer Prozesse respektive der SPS und der kompletten Bus-Topologie, sowie den Servo-Antrieben auseinander setzen
- Die von den Programmierern geliebte FSM so umbauen, dass überall wo möglich ein ASAP Scheduling gemacht wird, respektive die Trajektorien selber rechnen und die Startpunkte selber händisch ermitteln (würde für mich nur nötig, wenn es um die letzten Millisekunden geht, aber da sind wir noch weit entfernt)
Besten Dank für eure Antworten
Gruss
P51D
Ich weiss ehrlich gesagt nicht so recht, zu welchem Forum das am besten passt...
In einer Maschine haben wir eine B&R Steuerung und P3 Servor-Antriebe und einem APC 3300. Als man mich (ich komme aus der Embedded-Welt) dazu verdonnert hat, die von unseren externen Entwicklern umgesetzten Prozesse zu analysieren, hat mich beinahe der Schlag getroffen. Bevor ich den Leuten von ihrer "Leistung" berichte, möchte ich ein paar Vergleichswerte haben. Denn wie gesagt, ich kenne mich mit SPS nicht aus.
Die Zahlen und Informationen, die ich mittlerweile zusammengetragen habe:
Latenz = tin (was das auch immer sein soll) + 2 PowerLink + 1 Task + 2 PowerLink + 1 P3 + tout (auch nicht weiter bekannt)
PowerLink läuft mit 1.6ms, Task-Zeit ist 3.2ms und das P3 arbeitet mit 400us. Wenn man also die obige Kette zusammenzählt, sind das mindestens 10ms "Wartezeit", wenn eine Achse auf Position gefahren ist, und bis dann schlussendlich die nächste Achse von dieser Position "getriggert" wird.
Als ich ein paar Traces aufgezeichnet habe (ich sag nur soviel: bin ich froh, dass ich mit der Toolchain nicht arbeiten muss, denn zum State of the Art in der Embedded-Welt sind da gefühlt 30 Jahre unterschied. Aber das ist ein anderes Thema und tut nichts zur Sache) habe ich Wartezeiten zwischen solchen "Achs-auf-Achs" Aktionen im Bereich von 20-60ms gemessen (nicht einmal konstant??). Und da sind in der FSM nur 2 States (Übergangsbedingung ist das Erreichen der Position).
Da stellte sich für mich die Frage, wer da die Bremse vergessen hat zu lösen
. Über die 10ms Latenz kann man ja noch diskutieren (obwohl das schon sehr grenzwertig ist, denn eine simple TCP/IP Verbindung ohne RealtimeOS bei Millionen von Internet-Teilnehmern kann in die gleiche Region kommen), aber bei 60ms ist dann definitiv Schluss mit meinem Verständnis.Vor allem wenn da 30ms auf der Position verharrt wird, 60ms für das kurze Verfahren benötigt werden und dann wieder 30ms gewartet wird. Über den gesammten Prozess ist die Anlage so 20-25% mit Warten "beschäftigt".
Ich sehe momentan folgende Ansätze:
- Akzeptieren, da das wohl so ist (desswegen die Frage nach Vergleichswerten)
- Die Programmierer herzitieren, sodass sie sich mit der Analyse ihrer Prozesse respektive der SPS und der kompletten Bus-Topologie, sowie den Servo-Antrieben auseinander setzen
- Die von den Programmierern geliebte FSM so umbauen, dass überall wo möglich ein ASAP Scheduling gemacht wird, respektive die Trajektorien selber rechnen und die Startpunkte selber händisch ermitteln (würde für mich nur nötig, wenn es um die letzten Millisekunden geht, aber da sind wir noch weit entfernt)
Besten Dank für eure Antworten
Gruss
P51D
Zuletzt bearbeitet:
