CPU Auslasten mit ST

[Majestic_1987]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Aussage, dass SCL und ST gleich sind ist - bezogen auf die Sprachmittel - korrekt. ABER nicht bezogen auf das, was die Steuerung damit nachher tut.

Warum? Weil eben in S7 aus dem SCL erstmal fleißig AWL erzeugt wird, während bei z.b. CoDeSys aus dem ST direkt ein kompilat erstellt wird. Bei der S7-300 wird dieser AWL-Kram dann in MC7-Code (quasi auch AWL mit ein paar Unterschieden) übersetzt und interpretiert.

Somit hast du hier mehrere Übersetzungsschritte drin, die natürlich alle suboptimal sein können für eine gegebene Aufgabe.

ST auf ner z.B. Beckhoff-, Wago- oder Bosch-Steuerung ist also was anderes, als SCL auf ner S7. Zumindest zur Laufzeit.

Du könntest nun auf der S7 AWL direkt proggen und das gleiche in ST auf der Vergleichssteuerung machen. Da dein AWL aber nicht dem entsprechen wird, was auf Maschinencode-Ebene in der Vergleichssteuerung passieren wird, ist auch das nicht wirklich gleich. Bleibt also nur: Alles in AWL machen. Theoretisch sollten alle Steuerungen sich bei gleichem AWL-Code auch gleich verhalten. Deswegen: AWL.

Es wäre allerdings auch mal eine Interessante Aufgabe, diese Unterschiede wissenschaftlich zu untersuchen. Also: Gegebenes Programm. Einmal in SCL, einmal in AWL. Relativen Laufzeitunterschied ermitteln. Gleiches Spiel auf sagen wir CoDeSys.

Jitter bezeichnet allgemein eine zeitliche Schwankung bei einem theoretisch isochronen Prozess, ums mal einfach zu formulieren.

Bei der Übertragung in einem Echtzeit-Feldbus kann das auftreten, weil du eben nie zu exakt äquidistanten Zeitpunkten senden kannst. Er tritt aber auch bei ner Steuerung auf, weil auch hier der Aufrufzeitpunkt nie exakt im selben Zeitabstand erfolgt.

Die Schwankung der Zykluszeit bei nicht isochronem Bausteinaufruf (man kanns auch "Freilaufende Task" nennen) ist also auch ne Art Jitter. Übrigens geben die Steuerungshersteller i.d.R. für ihre Runtime den max. Jitter der Basiszeit an. Könnte man z.b. auch mal messen und mit dem Datenblatt vergleichen.

Und mit Speicherbereiche kopieren meinte ich sowas wie "512 Byte von a nach b kopieren" oder sowas. Typumwandlungen sind aber auch ne gute Idee. Wie gesagt. Man kann alles mal mit rein bringen. Dadurch wird auch das Programm größer. Kann auch nich schaden ;-)

 

[borromeus]

Würde ich so nicht sagen. Es ist schon eine sinnvolle Frage, wie weit die Leistungsfähigkeit eines PC-basierten Systems über der einer Hardware-SPS liegt, insbesondere, wenn man die Preise mal begutachtet. Und zwar auch unter Berücksichtigung der zusätzlichen Vorteile und Möglichkeiten...jener, die über die pure Rechenleistung noch hinaus gehen.

Allerdings kann ich dem TE jetzt schon sagen, dass er mit der WinAC nicht sonderlich viel Spaß haben wird. Auf dem Soft-SPS-Markt gibt es deutlich bessere Alternativen. Gehört aber hier nicht rein ;-)

Ja, genau diesen Irrtum ;-) (nicht übel nehmen bitte) meine ich: im Regelfall sind die Anforderung an eine SPS NICHT die Geschwindigkeit, sondern ganz andere Kriterien. Die Frage nach der Geschwindigkeit ist m.E. nur dann sinnvoll wenn eine konkrete Anwendung dies benötigt. Neben den von Dir beschriebenen Vorteilen, die nicht von der Hand zu weisen sind, gibts auch sehr große Nachteile, die im "Regelfall" niemand in Kauf nehmen möchte, es sei denn er braucht wirklich die Geschwindigkeit (oder hat zuwenig Geld).

Darum:
DAS ist meine Anforderung.
Welches System genügt dem?

Würdest Du eine 100 mal schnellere SoftSPS, die ein Drittel einer CPU kostet grundsätzlich einsetzen?
Ich sehe es umgekehrt: von meinen 500 verbauten SPSn in den letzten 20 Jahren gibt es eine (sic!) Soft-SPS... Grund war, dass wir in einer Minianlage, die genau 2h im Monat läuft ein PCS7 verwendet haben und die Soft-SPS einfach billiger war.... aber dort ist es auch egal wenn man den Rechner neu startet oder komplett hinüber ist. Dann fahren sie den Versuch eine Woche später.

 

[Majestic_1987]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich weiß, dass Speed nicht alles ist. Und meistens auch nicht Priorität. Aber es gibt genug andere Vorteile. Vom Preis mal abgesehen.

Allerdings ist es auch Fakt (nicht übel nehmen), dass die meisten PROGRAMMIERER Vorurteile gegen PC-basierte Systeme haben, weil sie denen keine Zuverlässigkeit zutrauen.

Aber, um mal einen Vergleich zu fahren: Basieren nicht Server auch auf PC-Technik und so weiter? Und laufen die NICHT 24/7, über Jahre?

Ums mal so zu sagen: Von den Soft-SPSen, die ich kenne...in Betrieb...ist noch keine einfach so aus heiterem Himmel abgestürzt.
Und ich habe auch schon 400er CPUs abstürzen oder kaputtgehen sehen. Und zwar nicht nur eine. Also ist das alles relativ.

Fakt ist: Solange man eine Soft-SPS als das versteht, was sie ist, nämlich eine STEUERUNG an der man eben nicht 20 mal am Tag neue Software installiert, seine Mails abruft oder sonstwas, läuft die genau so zuverlässig, wie eine klassische SPS.

Andernfalls hätten renommierte Firmen wie AIXTRON, bei deren Anlagen höchste Verfügbarkeit absolut notwendig ist, nicht ihre komplette Steuerungstechnik auf PC-basierte Steuerungen umgestellt. Oder?

Also, halten wir uns doch einfach fern von Vorurteilen (Bosch-Rexroth verkauft immerhin auch etliche Steuerungen...die sind alle PC-basiert) und bleiben bei harten Fakten.

Außerdem schreibt der TE eine Studienarbeit über das Thema. Das ist eine theoretische Untersuchung....keine praktische Einschätzung der Eignung eines bestimmten Systems für eine gegebene Aufgabe. Deine Kritik am Vorgehen bringt den TE also nicht weiter.

Und um deine Frage zu beantworten: Ich setze 100 mal lieber ne Beckhoff- oder Bosch-Steuerung ein, als eine S7. Aber das tut hier für die Aufgabenstellung des TE auch nix zur Sache. Zumal meine Beweggründe für diese Sichtweise auch über pure Leistungsdaten hinausgehen.

 

[MPH]

Die Aussage, dass SCL und ST gleich sind ist - bezogen auf die Sprachmittel - korrekt. ABER nicht bezogen auf das, was die Steuerung damit nachher tut.

Warum? Weil eben in S7 aus dem SCL erstmal fleißig AWL erzeugt wird, während bei z.b. CoDeSys aus dem ST direkt ein kompilat erstellt wird. Bei der S7-300 wird dieser AWL-Kram dann in MC7-Code (quasi auch AWL mit ein paar Unterschieden) übersetzt und interpretiert.

Somit hast du hier mehrere Übersetzungsschritte drin, die natürlich alle suboptimal sein können für eine gegebene Aufgabe.

ST auf ner z.B. Beckhoff-, Wago- oder Bosch-Steuerung ist also was anderes, als SCL auf ner S7. Zumindest zur Laufzeit.

VERDAAAAAAAAAAAMT des ist ja Obersch.......!!!!!!

Das wusste ich ja garnicht. Oh Mann, dass ist wenn man zu wenig Erfahrung hat.
Gut für mich das ich überhaupt kein AWL kann. Habe bisher immer in FUP und ST programmiert.

Die Ausführungszeiten zwischen der WIN AC und TWINCAT sind tatsächlich sehr unterschiedlich. Die TwinCat Steuerung bearbietet ihren Task wesentlich schneller als die WIN AC den OB1.
Kann es jetzt wirklich sein, dass dies an der höheren Anzahl der Übersetzungsschritte liegt????

Danke

Gruß

 

[borromeus]

Das stimmt, meine Kritik bingt dem TE nicht weiter, es war aber keine Kritik am TE sondern an dessen Aufgabensteller.
Auch wenn ich Deine Argumente nicht mit Zahlen entkräften kann- es sind aber sicherlich gute Argumente- würde ich minem Kunden keine Soft-SPS zumuten.
Ein vergleichsweise bezahlbarer PC hat eine Lebensdauer von ein paar Jahren, CPU's liegen da sicher um fast eine Potenz höher.
Im Regelfall kostet ein Anlagenausfall in einer ausgewachsenen Industrieanlage ganz schnell zig-tausende Euro, das steht in keiner Relation zu gesparten 5k Euro.
Wir haben einen Kunden, der hat mittlerweile 100 Bedienstationen (Siemens Industrie-PC's) und etwa 40 400er CPU's.
Fakt dort ist (15 Jahre Beobachtungszeit): CPU kaputt: 1 in 15 Jahren. Rechner kaputt: 2 im Jahr.

 

[MPH]

Zuviel Werbung?
-> Hier kostenlos registrieren

Weil eben in S7 aus dem SCL erstmal fleißig AWL erzeugt wird, während bei z.b. CoDeSys aus dem ST direkt ein kompilat erstellt wird. Bei der S7-300 wird dieser AWL-Kram dann in MC7-Code (quasi auch AWL mit ein paar Unterschieden) übersetzt und interpretiert.

Hi Majestic

hast du eine Quelle wo das beschrieben steht, wie die Steuerung den SCL Code verarbeitet.
Ich habe im Inet gesucht aber bis jetzt noch nichts passendes gefunden.

Danke

Gruß

 

[Thomas_v2.1]

Warum? Weil eben in S7 aus dem SCL erstmal fleißig AWL erzeugt wird, während bei z.b. CoDeSys aus dem ST direkt ein kompilat erstellt wird. Bei der S7-300 wird dieser AWL-Kram dann in MC7-Code (quasi auch AWL mit ein paar Unterschieden) übersetzt und interpretiert.

Bei einer 300er ja, es gibt aber auch CPUs deren Maschinensprache eben MC7 ist. Woher weißt du denn dass Codesys direkt in Maschinensprache des Zielsystems übersetzt? Vielleicht gibt es dort ja auch noch eine Zwischensprache die von der Codesys Laufzeitumgebung nur interpretiert wird.
Auf dem PC ist sowas bei Java oder den .Net Sprachen auch üblich, da wird nichts mehr in Maschinensprache übersetzt.

 

[Majestic_1987]

Bei einer 300er ja, es gibt aber auch CPUs deren Maschinensprache eben MC7 ist. Woher weißt du denn dass Codesys direkt in Maschinensprache des Zielsystems übersetzt? Vielleicht gibt es dort ja auch noch eine Zwischensprache die von der Codesys Laufzeitumgebung nur interpretiert wird.
Auf dem PC ist sowas bei Java oder den .Net Sprachen auch üblich, da wird nichts mehr in Maschinensprache übersetzt.

Weil das so definiert bzw. beschrieben ist. Abgesehen davon ist JAVA und .Net ne ganz andere Geschichte. Das sind nämlich sog. "managed" Programmiersprachen, der Code wird also zur Laufzeit sozusagen überwacht. Speicherzugriffe, Garbage-Collection und solche Späße. Eine solche Sprache ist in keinem Fall Echtzeitfähig. Die Notwendigkeit hierfür liegt vor allem in einem Sandbox-ähnlichen Verhalten (unter anderem). Das kannst du keinesfalls mit ner Interpretersprache vergleichen sondern eher mit einer Quellcodeüberwachung zur Laufzeit.

Es ist korrekt, dass die 400er CPU's einen MC7-Befehlssatz haben. Deswegen kann man da quasi schon von Kompilierung sprechen. Daher habe ich meine Aussage auch bewusst auf 300er gemünzt.

@borromeus: Du sitzt auf dem selben falschen Pferd auf. Rechner kaputt kann durchaus passieren. Warum? Weil eben der normale Consumer-PC in der Regel keine Komponenten hat, die auf 24h-Betrieb ausgelegt sind. Allein bei Festplatten gibt es dafür extra Modelle. Wenn du einen guten Industrie-PC kaufst, dann geht der auch nicht kaputt. Was dazu kommt ist das ovn mir erwähnte Problem: Wenn man einen PC so benutzt, wie man das von zu Hause gewohnt ist, dann wird der irgendwann Probleme machen. Wenn man aber das installiert, was zum Betrieb der Anlage nötig ist und den PC entsprechend einrichtet, dann ist der ebenso zuverlässig wie jedes andere System. Oder anders ausgedrückt:

Was ist an einem x86-Prozessor denn so anders, was ihn unzuverlässiger machen sollte, als sagen wir ein ATMega? Nichts. Beides sind Mikroprozessorsysteme. Auch in der S7 schlummer irgendein Microprozessor. Etwaige Probleme resultieren allerhöchstens aus dem Betriebssystem als "Zwischeninstanz" zum Anwenderprogramm.

Du würdest deinem Kunden NIE eine Soft-SPS ans Herz legen. Worauf basiert denn diese Aussage? Also: Auf welchen ARGUMENTEN? Denn bisher sehe ich hier nur deine persönliche Präferenz. Wie groß ist denn deine tatsächliche Erfahrung mit sagen wir Wago, Bosch oder Beckhoff? Worauf stützt du deine Abneigung?
Oder begehst du den Kardinalfehler, einen Embedded-PC wie z.b. nen CX5010 mit nem Bürorechner zu vergleichen? Das wäre nämlich grob fahrlässig. Fakt ist: Aufgrund der Vorteile steigt der Marktanteil PC-basierter Steuerungssysteme kontinuierlich. Dem wäre ja nicht so, wenn deine Aussage bezüglich der problematischen Betriebsbedingungen korrekt wäre, oder? Meine Erfahrung sagt: Diese Abneigung besteht VOR ALLEM bei Entwicklern und Kunden, die Siemens einsetzen (weil sie es schon immer getan haben, weil man eben Hard-PLCs gewohnt ist und "neuem" gegenüber irgendwie nicht sonderlich aufgeschlossen gegenüber steht). In der Druckindustrie oder Papierindustrie ist Bosch z.B. sehr verbreitet. Die laufen auf VXWorks. Also auch PC-basiert. Oder willst du mir sagen, eine Druckmaschine wäre nicht auf auf Zuverlässigkeit angewiesen? Fakt ist halt: Wer Siemens kauft, kauft in der Regel eben keine WinAC. Wer aber andere Steuerungshersteller konsultiert, der nutzt sie einfach, ohne sich groß nen Kopf zu machen über hypothetische Probleme. Ich hab mal an einem Tag 2 400er-CPUs tauschen müssen, weil kaputt. Die waren frisch aus der Fabrik. Also ist hier persönliche Erfahrung bezüglich der Zuverlässigkeit von Hard- und Software vielleicht nicht unbedingt repräsentativ.

Und wenn wir jetzt hier von Anlagenausfällen und deren Kosten reden, dann könnte man auch argumentieren, dass eine Soft-SPS (oft) die deutlich besseren Debugging-Möglichkeiten bietet und damit die Stillstandszeit deutlich minimiert werden kann. Ist aber vllt. auch etwas polemisch. Letztlich ist Anlagenstillstand und Zuverlässigkeit auch immer vom Programmierer abhängig. Kennst du Registerindirekte Adressierung? Hast du da schonmal Code von Leuten in ner Anlage gehabt, der fehlerhaft war? Da kannste noch sone tolle Steuerung da stehen haben, wenn der Programmierer Murks macht und dieser Murks erst während des Betriebs auffällt weil da eben andere Randbedingungen herrschen? Hast du in sowas mal Fehler gesucht? Dann haste ne ultra-zuverlässige Super-CPU, die Anlage steht dennoch und du suchst 5 Stunden lang in nem unkommentierten Registerverschiebemarathon nach nem Fehler, den du selber nicht gemacht hast. Da bringt dir also dann ne MTBF der CPU von 27 Jahren auch herzlich wenig, wenn die MTBF der Software wegen "ich mach einfach mal was, was ich nicht wirklich kann..." zwischen 20 Jahren und 10 Sekunden schwankt ;-)

MPH: Das wird wohl in irgendwelchen Hilfedateien genauer erläutert werden. Andernfalls verweise ich auf entsprechende Literatur. Aber ob die Laufzeitunterschiede bei WinAC und TwinCAT nun am Interpretieren oder an der genauen Arbeitsweise der WinAC liegen, kann ich dir nicht hinreichend erklären. Ich würde aber behaupten, dass da durchaus ein Zusammenhang bestehen kann. Wäre doch ne Sache, die du auch mal untersuchen kannst ;-) Dazu könntest du z.b. den identischen Code der WinAC mal auf ner 400er laufen lassen, die ja direkt den MC7 Code ausführen kann, ohne ihn interpretieren und in "ihre" Maschinensprache übersetzen zu müssen. Eventuell kannst du so den Zusammenhang nachweisen.

 

[Majestic_1987]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Majestic

hast du eine Quelle wo das beschrieben steht, wie die Steuerung den SCL Code verarbeitet.
Ich habe im Inet gesucht aber bis jetzt noch nichts passendes gefunden.

Danke

Gruß

Was die Steuerung aus dem SCL macht, kannst du dir anschauen, wenn du die SCL-Quelle übersetzt und dann löschst. Anschließend öffnest du den generierten Baustein. Da siehst du dann normalerweise den resultierenden AWL-Code. Ob man den MC7-Code sehen kann, der dann letztlich DARAUS gemacht wird, weiß ich allerdings nicht.

Aber nicht erschrecken, was da raus kommt. Das kann schonmal...umständlich sein.

 

[Thomas_v2.1]

Weil das so definiert bzw. beschrieben ist. Abgesehen davon ist JAVA und .Net ne ganz andere Geschichte. Das sind nämlich sog. "managed" Programmiersprachen, der Code wird also zur Laufzeit sozusagen überwacht. Speicherzugriffe, Garbage-Collection und solche Späße. Eine solche Sprache ist in keinem Fall Echtzeitfähig. Die Notwendigkeit hierfür liegt vor allem in einem Sandbox-ähnlichen Verhalten (unter anderem). Das kannst du keinesfalls mit ner Interpretersprache vergleichen sondern eher mit einer Quellcodeüberwachung zur Laufzeit.

Ich habe Java / .Net nur als Beispiel für eine Interpretersprache genannt. Aber warum sollte eine Laufzeitumgebung mit GC nicht echtzeitfähig sein? Echtzeitfähig heißt dass innerhalb einer festen Zeitspanne reagiert wird. Wenn man die Laufzeitumgebung so auslegt dass der GC nach einer festen Zeit zum Ende kommt, ist es auch echtzeitfähig.
Das Prinzip einer Sandbox ist bei einer SPS auch nicht mal völlig verkehrt. Einen Beckhoff BC Controller beispielsweise kann man über einen falschen Zeigerzugriff in die ewigen Jagdgründe befördern. Bei einer S7 werden entsprechende Interrupts aufgerufen.

Und ob in einer WinAC ein MC7-Interpreter läuft, oder ob diese den MC7 Code vor Ausführung in x86 Code kompiliert weiß auch nur Siemens.

 

[Majestic_1987]

Ich habe Java / .Net nur als Beispiel für eine Interpretersprache genannt. Aber warum sollte eine Laufzeitumgebung mit GC nicht echtzeitfähig sein? Echtzeitfähig heißt dass innerhalb einer festen Zeitspanne reagiert wird. Wenn man die Laufzeitumgebung so auslegt dass der GC nach einer festen Zeit zum Ende kommt, ist es auch echtzeitfähig.
Das Prinzip einer Sandbox ist bei einer SPS auch nicht mal völlig verkehrt. Einen Beckhoff BC Controller beispielsweise kann man über einen falschen Zeigerzugriff in die ewigen Jagdgründe befördern. Bei einer S7 werden entsprechende Interrupts aufgerufen.

Und ob in einer WinAC ein MC7-Interpreter läuft, oder ob diese den MC7 Code vor Ausführung in x86 Code kompiliert weiß auch nur Siemens.

Gesetzt den Fall, du hast nen entsprechenden OB projektiert, sonst geht die S7 auch in STOP ;-)

Wie willst du denn eigentlich bei .Net oder Java zur kompilierzeit sicherstellen, dass das Programm zur Laufzeit immer in der Lage ist, rechtzeitig zu reagieren? Dazu darfst du theoretisch zur Laufzeit keine neuen Objekte erzeugen. Damit fällt aber auch die Notwendigkeit eines GC weg ;-)

 

[MPH]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was die Steuerung aus dem SCL macht, kannst du dir anschauen, wenn du die SCL-Quelle übersetzt und dann löschst. Anschließend öffnest du den generierten Baustein. Da siehst du dann normalerweise den resultierenden AWL-Code. Ob man den MC7-Code sehen kann, der dann letztlich DARAUS gemacht wird, weiß ich allerdings nicht.

Aber nicht erschrecken, was da raus kommt. Das kann schonmal...umständlich sein.

Alles klar.

Auf jeden Fall vielen Dank für deine Hilfe.
Natürlich auch an alle anderen vielen Dank die sich für mich die Mühe gemacht haben. Tolles Forum!!!!!!!:s12:

Ist ja auch ungewollt ne tolle Diskussion entstanden über SOFT SPS oder nicht. War sehr interessant zu lesen.

Gruß