Codeausführung bei S7 vs B&R Automation Runtime

[godi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich frage mich gerade wie intern der Programmcode auf den verschiedenen Steuerungen ausgeführt wird.

Punkt 1:
Bei der S7-300 wird ja der (MC7) Code direkt vom Prozessor ausgeführt, bzw wird jeder Befehl des MC7 code als Opcode Codiert vom Prozessor abgearbeitet.
Bei der S7-1500 habe ich hier im Forum mal gelesen das dieser SCL Code direkt ausführt. Stimmt dies?
Also sind da für die SCL Befehle auch eigene Opcodes hinterlegt?
Was passiert mit dem Code von den anderen Sprachen? Wird das auch wieder als MC7 Code ausgeführt?

Punkt 2:
Weiters interessiert es mich wie dies bei B&R (X20 CP148x) durchgeführt wird.
Hier gibt es ja die Automation Runtime.
Wenn ich das richtig verstehe dann wird hier eine CPU emuliert,
und im Hintergrund läuft ein Betriebssystem (VxWorks?) welches die Automation Runtime ausführt.
Also der Code wird nicht direkt vom Prozessor verarbeitet sondern von der Automation Runtime.
Ist dies zu Vergleichen mit der Java Virtual Machine die den Java Bytecode ausführt?

Auf der Homepage von B&R habe ich nicht viel dazu gefunden die meine Fragen bzw Wissenslücken dazu auffüllen.

Punkt 3:
Desweiteren würde mich interessieren wie die Verarbeitungsgeschwindigkeit des Codes bei B&R aussieht.
In der S7 steht ja im Handbuch die CPU - Bearbeitungszeiten, im Handbuch zur X20CP1486 habe ich nur die typische Befehlszykluszeit gefunden.
Gilt diese für alle Befehle?
Wie können die Bearbeitungszeiten denn nun verglichen werden?

Für eine S7-1516 steht im Handbuch:
CPU-Bearbeitungszeiten
• für Bitoperationen, typ. 10 ns
• für Wortoperationen, typ. 12 ns
• für Festpunktarithmetik, typ. 16 ns
• für Gleitpunktarithmetik, typ. 64 ns

Die typische Befehlszykluszeit der X20CP1486 liegt jedoch bei 3,4ns.

Sind die B&R Steuerungen wirklich um so viel schneller gegenüber einer neuen S7-1500?


Ich freue mich über jede Antwort die ein wenig Informationen über die Verarbeitung von Programmcode in den SPSen enthält.

godi

 

[zako]

... hier kann man bzgl. der S7-1500 einiges rauslesen:
http://support.automation.siemens.com/WW/view/de/81318674

wenn es um Performance geht, dann kannst Du ja noch auf die 1518 warten, die nochmal richtig schneller sein soll.
Was hast Du denn für Anwendungen, wo es auf die Zykluszeit ankommt?
Bei MotionControl Anwendungen würde ich bei SIEMENS z.B. eine SIMOTION nehmen.

 

[godi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
danke für deine Antwort!
Mir gehts jetzt nicht um ein Projekt oder speziell um Zykluszeiten.
Mich interessiert wie dies intern Abläuft, vor allem bei B&R.
Ich habe Gestern nur mit jemanden gesprochen, der gemeint hat, dass er mal einen Kunden gehabt hat der S7 einsetzen wollte aber diese zu langsam war.
In dem Fall ging es um Regler (mittels Optimierung) die aus Simulink generiert wurden.

Aber wie gesagt, ich bin jetzt ganz allgemein an dem Thema interessiert.


Edit:
Punkt 1 ist im oben verlinkten Dokument im Kapitel 2.3 Optimierter Maschinencode beschrieben.
Demnach wird jede Sprache direkt in Maschinencode kompiliert.

 

[Blockmove]

Die 1500er sind keine schlechten Steuerungen.
Von der Geschwindigkeit darf man von den bisherigen CPUs keine Wunder erwarten.

Hier hat Siemens sicher noch einiges an Potential.

Gruß
Dieter

 

[Majestic_1987]

Wenn ich mich nicht irre ist doch auch B&R im Kern auf CoDeSys basiert.
Und wenn dem so ist, dann wird der Code kompiliert und zwar für den konkreten Prozessor. Dieses Kompilat wird dann auf dem Prozessor ausgeführt. Die Runtime sorgt in dem Fall von VXWorks vermutlich nur dafür, dass dieser Code in einer eigenen RT-Task ausgeführt wird. Bei Systemen, die auf Nicht-RT-Betriebssystemen aufsetzen, sorgt die Runtime vor allem dafür, dass der SPS-Code deterministisch und hochprior behandelt wird, quasi am Scheduler des OS vorbei. Es findet aber m.W.n. keine Emulation oder sowas statt.

Wenn's dir um "richtig schnell" geht bin ich mal polemisch, aber es stimmt: Nimm KEINE Siemens-Steuerung. Einer der Gründe für die oben von dir genannte Steigerung der Befehlsausführungszeit bei Siemens ist, dass - soweit ich weiß, korrigiert mich, wenns falsch ist - die S7-Steuerungen noch immer 16-Bit-Prozessoren ohne FPU haben.

Die meisten anderen Hersteller setzen mittlerweile auf Soft-SPS auf Standard-CPU's (Intel z.B.). Diese CPU's haben i.d.R. auch eine FPU und mittlerweile oft sogar 64-Bit-Prozessoren. Letzteres nützt natürlich nur was, wenn die Runtime auch 64-Bit kann. Und dann kann die CPU üblicherweise auch alle Operationen innerhalb eines Zyklus ausführen.

BTW: Ich halte das mit dem "SCL Code wird direkt ausgeführt" für ein Gerücht. Vermutlich meinte der, der das behauptet hat damit, dass der SCL-Code direkt kompiliert wird und nicht in irgendwelchen AWL-Code "zwischenübersetzt". Ob das ohne eine FPU und mit nur 16 Bit im Prozessor aber eine signifikante Leistungssteierung bedeutet sei mal dahin gestellt.

Ein direkter Vergleich könnte jedenfalls knifflig sein. Ich würde aber mal schätzen, dass in ziemlich jeder Anwendung B&R um min. 1-2 Größenordnungen schneller sein dürfte. Bei viel "Mathe" wird dieser Abstand signifikant größer werden. Bin aber kein B&R-Spezialist sondern eher bei Beckhoff zu Hause (und komme ursprünglich von Siemens, das nur zur Info).
Ich habe jedoch kürzlich in einem Projekt einen CX2030 (<2000€ inkl. Motion-Runtime) zur Steuerung und Positionsregelung von insgesamt 11 Servoachsen plus massig SPS-Code bei einer realen Ausführungszeit von unter 100µs eingesetzt. Und ich glaube, dass das bei B&R auch gehen würde.

 

[bits'bytes]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo

Hallo,


Punkt 2:
Weiters interessiert es mich wie dies bei B&R (X20 CP148x) durchgeführt wird.
Hier gibt es ja die Automation Runtime.
Wenn ich das richtig verstehe dann wird hier eine CPU emuliert,
und im Hintergrund läuft ein Betriebssystem (VxWorks?) welches die Automation Runtime ausführt.
Also der Code wird nicht direkt vom Prozessor verarbeitet sondern von der Automation Runtime.
Ist dies zu Vergleichen mit der Java Virtual Machine die den Java Bytecode ausführt?

Auf der Homepage von B&R habe ich nicht viel dazu gefunden die meine Fragen bzw Wissenslücken dazu auffüllen.

Das mit der Automation Runtime musst du dir ein wenig anders vorstellen.

Die RT schafft einfach gesagt die Basis für die Ausführung der vom Anwender erstellten Programmteile. Diese werden ja als .br Module in die Steuerung gespielt. Die Runtime stellt als erstes mal die gesamte Funktionalität zur Verfügung.

Dazu gehört unter anderem

- File Handling
- Variablen Funktionen
- Connectivity
- ...
- ..

Das ganze könnte man im Vergleich mit Windows mit einer Ansammlung von DLL's vergleichen, welche die Funktionalitäten zur Verfügung stellen.

Weiters wird natürlich das gesamte Taskhandling von der RT durchgeführt. Abarbeitung der Taskklassen, Einhaltung der Zeitslots, die Unterbrechung der langsameren Taskklassen um die schnelleren durchzuführen. IO handling, Feldbus usw. usf.

Habe einen kurzen Screenshot aus der B&R Hilfe (-->Echtzeit Betriebssystem/Arbeitsweise) eingefügt. Ich nehme an du hast AS und damit die Hilfe zur Verfügung.



BG
bb

 

[godi]

Danke euch für die ausführliche Information, und den Hinweis mit der Hilfe. Habe ich total übersehen, dass es in der Hilfe ein eigenes Kapitel über das Echtzeit Betriebssystem gibt. :shock: Das werde ich mir jetzt mal genauer durchlesen.

Aber ich hätte nicht gedacht, dass die Unterschiede zu Siemens noch so groß sind. Naja wenn man von Anfang an und überall mit Siemens verseucht wird, dann hat man ein striktes SPS-Siemensweltbild.

 

[zako]

Aber ich hätte nicht gedacht, dass die Unterschiede zu Siemens noch so groß sind.

Bei Siemens gibt`s ja nicht nur ne SIMATIC. Da gibt`s die SIMOTION, SINUMERIK, FM- Baugruppen, SIMATIC TDC, ...

 

[Werner29]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn ich mich nicht irre ist doch auch B&R im Kern auf CoDeSys basiert.

Wir (3S) haben vor >10 Jahren mal Compiler und Editoren an B&R verkauft. Seitdem haben wir nichts mehr mit B&R zu tun.
In aktueller Software von B&R ist kein CODESYS mehr drin.

Die angegebenen Zeiten sprechen dafür, dass beide Systeme direkt Maschinencode erzeugen und den ausführen.

Wenn man die Geschwindigkeit zweier SPSen vergleichen will, dann reicht es jedenfalls nicht, einfach nur die CPU-Zeiten miteinander
zu vergleichen. Es geht dann um Speicherzugriffe, um die Anbindung der IOs etc.
Es könnte auch Skalierungseffekte geben, ein 10 Mal so grosses Programm könnte vielleicht 100 Mal so lange brauchen.
Es könnte Unterschiede geben ob die einzelnen Bausteine klein oder gross sind.

Das ist ein schwieriges Thema, und die CPU-Bearbeitungszeit allein sagt noch nicht viel aus.

Leider gibt es (noch) keinen allgemein anerkannten Benchmark um SPSen miteinander zu vergleichen.
Deswegen bleibt einem nichts anderes übrig als selber Projekte zu schreiben und zu vergleichen, wenn man es wirklich wissen will.

 

[godi]

Bei Siemens gibt`s ja nicht nur ne SIMATIC. Da gibt`s die SIMOTION, SINUMERIK, FM- Baugruppen, SIMATIC TDC, ...

Ja es stimmt schon, dass es bei Siemens alles gibt.
Natürlich die Simatic TDC hat schon einen 64-Bit Prozessor eingebaut, aber für kleinere Anlagen wo jetzt ein eigener etwas komplexer Regler verbaut ist, bestimmt ein wenig teuer.

 

[Majestic_1987]

Siemens hat diesbezüglich halt einfach kein brauchbares P/L-Verhältnis...

Gesendet von meinem C6603 mit Tapatalk

 

[godi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zusammenfassung

Punkt 1 wurde mir durch das verlinkte Dokument von Zako beantwortet.

Punkt 2 wurde durch Majestic und bits'bytes beantwortet.
Es wird direkt der "SPS-Code" in Maschinencode übersetzt und von der CPU ausgeführt.
Automation Runtime ist das Betriebssystem, das auf einen echtzeitfähigen Betriebssystem aufsetzt und nicht von diesem Emuliert wird.
Somit werden die Tasks die im Automation Studio angelegt werden auch direkt von diesem aufgerufen.

Punkt 3 ist für mich momentan auch ausreichend beantwortet worden.

 

[Schleppfehler]

Also verschiedene SPS`n zu vergleichen, ist wirklich nicht so einfach.

Ich hatte vor 3 Jahren mal das (Glück) ein und dieselbe Maschine in 3 verschieden Systemen zu programmieren. Diese waren B&R X20 3484, S-7-300 (317) und eine Allen Bradley (L62). Also alle so ca. im gleichen Preissegment.
Das Programm war in SCL und auf allen drei Systemen fast gleich. Das Grund Programm wurde auf der B&R entwickelt.
Man kann schon sagen, das die Abarbeitung 1-3 mal schneller war, als bei Siemens und AB. Bei der AB und der B&R waren sogar noch Servos mit dabei, was bei AB schon relativ viel Performance verbrauchte.
Ich kann nicht beurteilen, wie der heutige Stand der der Siemens und AB Systeme ist.
Nachteil ist klar, das bei B&R nur das Compilierte Programm auf der SPS zu finden ist.
Wir benutzen nun hauptsächlich B&R, auch die Servo Technik überzeugt doch sehr.

Grüsse

 

[Majestic_1987]

Also bei TwinCat und Rexroth kann man die.Option "Quellcode Laden" nutzen, um den Quellcode zusätzlich zum Bootprojekt auf der Steuerung zu speichern. Würde mich wundern, wenn das bei B&R nicht geht...

Gesendet von meinem C6603 mit Tapatalk

 

[gaiskasimir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich weiss nicht mehr seit welcher AS Version - aber das Projekt kann sehr wohl auf dem Zielsystem gespeichert sein.
Config->Eigenschaften->Quellen

 

[JesperMP]

(gelöscht und ein anderen Thread gestartet)

 

[IBFS]

Es geht doch nicht um höher schneller weiter, sondern um die konkrete Anwendung.
Daher ist dieses ganze Benchmark-Gerede sinnlos.

Man entscheidet sich für ein Plattform, ob nun STEP7, 3S oder .....
wählt die passende CPU aus und der Rest, ja der Rest den entscheidet der Programmierer.
Ist der GUT, dann reicht evtl. eine kleiner CPU, ist er SCHLECHT reicht keine S7-400.
Also!

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich schätze mal dass ein Raspberry Pi für 40 Euro ähnliche Befehlsausführungszeiten wie die B&R High Performance Kiste hat, dort steckt ja auch "nur" ein 650 MHz Celeron drin.
An dem Vergleich kann man sehen was solche Daten für eine Aussagekraft besitzen, denn eine SPS soll ja noch mehr machen als nur die Befehle abarbeiten.

 

[Werner29]

Es geht doch nicht um höher schneller weiter, sondern um die konkrete Anwendung.
Daher ist dieses ganze Benchmark-Gerede sinnlos.

Man entscheidet sich für ein Plattform, ob nun STEP7, 3S oder .....
wählt die passende CPU aus und der Rest, ja der Rest den entscheidet der Programmierer.
Ist der GUT, dann reicht evtl. eine kleiner CPU, ist er SCHLECHT reicht keine S7-400.
Also!

Wenn dem so ist, warum gibts dann überhaupt unterschiedliche Leistungsklassen?
Ja es geht um die konkrete Anwendung, und manchmal kommts dabei auf Performance an.
500 µs Zykluszeit kommen durchaus vor und dann will man wissen, was man in der Zeit alles ausführen kann.

 

[bike]

Wenn dem so ist, warum gibts dann überhaupt unterschiedliche Leistungsklassen?
Ja es geht um die konkrete Anwendung, und manchmal kommts dabei auf Performance an.
500 µs Zykluszeit kommen durchaus vor und dann will man wissen, was man in der Zeit alles ausführen kann.

Liegt es auch daran, dass Entwicklungssysteme immer größeren und Ressourcen fressenden Code ausspucken?
Anstelle bei der Entwicklung zuerst ein sinnvolles Konzept zu erstellen, wird inzwischen einfach los getippt, wie bei einem Brief.
Daher wird immer mehr darauf abgezielt, immer teuere Hardware zu verbauen.
Warum laufen Maschinen mit S5 oder CNC Maschine mit 880 Steuerung oder S3 heute noch und produzieren sehr gute Teile?

Die Entwickler der Programmiersysteme sollten mehr an die Technik und nicht im Sinn von M$ denken.


bike