Windows echtzeitfähig mit Delphi

[Harry Stahl]

Übrigens, wer das noch nicht kennt: Seit - ich glaube D2010? - gibt es in Delphi die Unit Diagnostics, die

{************************************************* ******}
{ Support for high-precision timing utilities }
{************************************************* ******}

enthält.

Seit XE2 ist die Unit (System.Diagnostics) crossplattform-fähig, kann man also auch unter Windows (VCL und FMX) und MAC OS X einsetzen.

Mit dem Record TStopWatch kann man ganz einfach hochpräzise Zeitmessungen vornehmen.

[Dejan Vu]

Geht es immer noch um RT-Fähigkeit von Windows, oder um Versuche, das Unmögliche möglich zu machen?

Ich habe viel mit der Beckhoff-SPS gemacht: Wirklich brauchbar, das Teil.

[Medium]

Ich habe da eine Randfrage, wo sich hier gerade die ganzen Soft-SPSler versammeln: Warum setzt ihr diese ein?

Ich frage, weil meine Brötchen auch aus Steuerungen kommen, und ich bisher nicht wirklich den Vorteil von einer "emulierten" SPS begriffen habe. Für die E/A brauche ich doch auch dort wieder spezielle Hardware, oder? Und so ein PC, industrietauglich, schnell genug für ausreichend kurze Taktzyklen bei mittleren bis größeren Steuerungen (wir machen hauptsächlich ganze Betriebe, nicht nur einzelne Maschinen), kostet ja auch nicht so arg viel weniger als eine mittelgute S7-300 CPU. Mit dieser habe ich dann aber ein schön entkoppeltes, lange getestetes, qualitativ zumindest in gewissem Rahmen gesichertes Produkt, dass ich ruhigen Gewissens auch in warmen Schalträumen unbeaufsichtigt machen lassen kann.
Und ich würde mich arg unwohl fühlen, einen PC mit mehr Dingen zu betrauen als eine Soft-SPS, weil ich eben wegen angeprochener Nicht-Echtzeitfähigkeit um meine Zyklen bangen würde. Dazu der Vorteil einfacher Integration von Dingen wie z.B. F-Baugruppen, Siwarex Karten, etc. pp - also die gesamte Infrastruktur um eine SPS herum. Und eine SPS neigt weit weniger zu Abstürzen aufgrund von wasweissich für Schluckaufs, den PCs ja ab und an mal haben.

Kommunikation ist auch kein großes Problem: S7-Online Verbindung via LibNoDave, und ich komme ratzefatze an alles ran. Alles. Dazu braucht es nichtmals einen CP oder projektierten Datenaustausch, die SPS legt einfach, und liest alles in/aus ihre/n DBs und hat aktiv nichts mehr mit der Kommunikation an sich zu tun.

Dazu noch, dass sich eine SPS viel einfacher und kostensparender (weil weniger verbrauchend) mit einer USV versorgen lässt, uuuuund das ganze ist auch noch hübsch klein und handlich auf einer Alu-Schiene angeordnet. Warum wöllte ich da eine Soft-SPS einsetzen? Welchen Vorteil böte das? Wo ist da das Einsatzgebiet?

[Dejan Vu]

Ich habe für eine Firma gearbeitet, die Beckhoff eingesetzt hat. Kein Programmierer hat sich gefreut, S7 zu machen, im Gegenteil: Alle haben gekotzt. Mit diesem CoDeSys-Zeugs (Pascal-ähnlich) kann man ganz brauchbar programmieren, OOP geht zwar nicht, aber Clean Code Ansätze schon.

Eigentlich ist die Beckhoff-SPS (also das TwinCat) ein Treiber, der auch dann noch läuft, wenn Windows ordentlich abgeschmiert ist. Windows ist hier nur der Aufsatz für eine HMI (lustig, die ist auch in Delphi geschrieben. Scheint Mode zu sein). Die SPS schnappt sich feste 80% (einstellbar) der CPU. Mit dem Rest kannst Du machen, was Du willst. Das reicht für ziemlich brauchbare Tools, Datenbankanbindung, HMI etc.

Es ist garantiert, das die Zyklen eingehalten werden (wenn die Steuerung mitspielt, ist ja logisch)

Die Industrie-PC sind -wenn sie den Montagstest überstanden haben- sehr zuverlässig. Die kosten ein wenig mehr, als ein PC von Saturn, aber dafür haben die keinen Lüfter, sind schnell genug usw. Der ganze Schmonz ist in einem Schaltschrank.

Die Firma hatte sich sehr früh für Beckhoff entschieden, weil die Maschinensteuerungen sehr komplex waren und man sich mit S7 vermutlich einen abgebrochen hätte. Weiterhin haben die Programmierer ein Framework entwickelt, das sich auf so ziemlich alle (Sonder-) Maschinen von denen anwenden ließ. Man hat die ganzen Bibliotheken importiert, die man so brauchte, alle Listen angelegt und konnte dann die Maschine ziemlich flott programmieren. Anpassen und Entwanzen dann in der Halle und beim Kunden.

Die Pharmaindustrie wollte wohl unbedingt S7 und dann mussten einige Programmierer umschulen. Glücklich waren die dabei aber nicht.

[Medium]

Ich vermute fast, dass CoDeSys sich nicht allzu stark von SCL unterschiedet, da es hier imho auch Standards zu gibt. (Auch kein OOP, aber strukturiert.) Die meisten SPS Programmierer kennen aber fast nur KOP/FUP und mit etwas Glück genug AWL für den einen oder anderen Kunstgriff. Aber mit SCL lassen sich die wildesten Dinge bauen, bei denen sich unsere Kunden ab und an auch wunderten, dass das mit der SPS alleine möglich ist, ohne einen PC als "Kopf".
Die wenigsten SPSler sind Informatiker, die Regel sind hier eher Elektriker, die sich mehr oder weniger fortgebildet haben. Für die ist KOP/FUP sicherlich prima, ich bekomme da auch leichte Anfälle :D. SCL/AWL sind bei uns die Mittel der Wahl, womit wir z.B. eine komplette sehr variable Rezeptsteuerung in der SPS selbst realisiert haben. Bei BATCH steht ja alles wenn der Leit-PC weg schmiert. Passiert das bei uns, rennt die gesamte Anlage dennoch weiter - ein großer Vorteil wenn chemische Prozesse ablaufen, denen es egal ist wenn was ausfällt. Das Zeug reagiert einfach weiter! Einzig manuelle Eingriffe und Visu sind dann weg, aber deshalb hat man ja noch Taster und Leuchten für ganz kritische Dinge.

Ich lese daher aus deinem Beitrag, dass es im Wesentlichen auf den jeweilig etablierten Firmenstandard (inkl. der bestehenden selbst entwickelten Tool-Chain) und persönliche Zuneigung zurück geht.

Delphi findet sich in der Industrie übrigens noch verhältnismäßig oft. Ich vermute stark, dass das daran liegt, dass die Wurzeln dieses Zweigs gerade da lagen, wo Turbo Pascal so richtig Fahrtwind aufgenommen hat, und dank seiner Syntax in technischen Berufen gerne gelehrt wurde. Sieht man auch schon daran, dass Sprachen wie SCL und CoDeSys so Pascal ähnlich sind. Ich treffe öfter mal offensichtliche Delphi-Progrämmchen an.

[Dejan Vu]

Zitat:

Zitat von Medium (Beitrag 1268546)

Zeug reagiert einfach weiter! Einzig manuelle Eingriffe und Visu sind dann weg, aber deshalb hat man ja noch Taster und Leuchten für ganz kritische Dinge.

Genau das geht natürlich auch mit einer Soft-SPS.

Anhand der Gesichter der Programmierer (die sich an Pascal gewöhnt haben) würde ich annehmen, das S7 einfach schmerzhaft ist. Irgendwie war da was mit Variablen, Strukturen (CodeSys hat Records und Methoden für Records (Funktionsbausteine FB)).

[hanspeter]

Die Soft-SPS ist reiner Installationsaufwand.
Rechner kaputt , irgendein neuer - Installation und fertig.
Der Bus kann z.B. auch über Eternet angeschlossen und damit auch relativ problemlos simuliert werden.
Die Beckhoff SPS kann übrigens 4 SPS unabhängig und parallel realisieren.
Da ich das TWincat als Demo-Version auf dem Rechner daheim installieren kann, habe ich ein eigenes Entwicklungssystem im Büro stehen.
Mit der Demo Version verfährt Beckhoff ziemlich großzügig. Diese ist in der Laufzeit auf 4 Wochen begrenzt.
Nach Ablauf deinstallieren und wieder neu installieren und die Laufzeit beginnt von vorn.
Die SPS Hardware (Buskoppler und E/A) sind im Vergleich preiswert.

Peter
Auf SPS Ebene kann übrigens auch mit C programmiert werden.

[Dejan Vu]

Zitat:

Zitat von hanspeter (Beitrag 1268553)

Auf SPS Ebene kann übrigens auch mit C programmiert werden.

Im Visual Studio, soweit ich mich erinnere.

[hanspeter]

Zitat:

Zitat von Dejan Vu (Beitrag 1268555)

Im Visual Studio, soweit ich mich erinnere.

Im Entwicklungssystem (IDE+Compiler+Bausteinverwaltung+Debugsystem) war direkt ein GNU-C integriert.

[Dejan Vu]

Das ist mir wiederum neu (ich kenne bei Beckhoff nur dieses Pascal-Derivat). Als ich aufgehört habe, für den Maschinenbauer zu arbeiten, war Twincat 3 im Kommen, und das war mit C++ (oder nur C?) in VS zu programmieren. Ob C#, weiß ich nicht (glaub ich auch nicht), aber C(++?) sollte funktionieren.