Zyklus und Polling

[reinerdoll]

Zuviel Werbung?
-> Hier kostenlos registrieren

"Philosophische" Fragestellung ;-)

Eine SPS macht (außer man parametriert das anders, was bei modernen Systemen ja möglich ist) klassisch immer einen zyklischen Ablauf.
Optimal darstellbar sind Ablaufketten dann mit Petrinetz-ähnlichen Konstrukten (Graph 7 zum Beispiel.
Eine Schrittkette in AWL oder auch in SCl simuliert das gleiche in Syntax.
-> hier läuft die SW immer wieder an den gleichen Bedingungen vorbei (if oder case), und entscheidet so oder so.

Ein PC-Betriebssystem macht das erstmal nicht. Klassisch werden Bedingungen von außen über polling abgefragt.
-> Eine Warteschleife läuft solange, bis das Ereignis eintritt.

Nun die "philosphische" Frage :

Wenn ich aus einem PC raus (MES-System) mit mehreren SPS kommuniziere (Handshakeprotokolle), kann ich das erstmal nicht mit polling machen, weil eine stehende SPS dann wegen fehlendem Signal die ganze Steuerung lahmlegt. Der PC bleibt in einer Pollingschleife stehen (watchdog mal außen vor).

--> ist der Königsweg, der Goldstandard, jetzt a) SPS-System nachbilden und ne Schleife um die ganze SW rum,
oder b) weiter Polling, aber die einzelnen SPS-Kommunikationen als Threads, die parallel laufen ??

gibts da ne Lehrmeinung oder sowas ???

 

[kpeter]

hallöchen

wieso sollte dich eine stehende sps aufhalten wird ja hoffentlich einen timeout geben ????

 

[weißnix_]

Zuviel Werbung?
-> Hier kostenlos registrieren

Handshaking kann auch zyklisch sehr gut abgebildet werden - sofern das Timing passt.
Du unterliegst dem klassischen Denkfehler, das man schnelle Kommunikation im Zyklus abwickelt. Das wird über das Betriebssystem der Steuerung abgewickelt bzw. dedizierte Kommunikationsschnittstellen mit Eigenintelligenz und nicht von der Runtime. Die Runtime versorgt die Schnittstellen(programme) mit den abgefragten Daten. Fragst Du schneller ab als die Runtime Daten nachliefert bekommst Du im Zweifel die selben Daten nochmal. Das sollte aber mittels Handshaking nicht passieren: Der Pollingprozess synchronisiert sich mit der Datenliefergeschwindigkeiit. Dadurch wird die Kommunikation unabhängig vom Job der SPS.
Du kannst also normalerweise von MES-Seite problemlos pollen. Die SPS-Runtime kommt dabei nicht zum Stillstand (und wenn ist es schlecht programmiert).
Auf PC-basierten Steuerungen läuft eine Runtime (die SPS) und das Betriebssystem (PC-basiert).

Übrigens: In aller Regel ist eine SPS an (erreichbar) oder aus. Zyklus steht ist in aller Regel eine Fehlerkondition (Runtime arbeitet Programm nicht mehr ab). Timeouts auf MES-Seite sollten ein festhängen des Pollingprozesses verhindern.

 

[Heinileini]

Wenn ich aus einem PC raus (MES-System) mit mehreren SPS kommuniziere (Handshakeprotokolle), kann ich das erstmal nicht mit polling machen, weil eine stehende SPS dann wegen fehlendem Signal die ganze Steuerung lahmlegt. Der PC bleibt in einer Pollingschleife stehen (watchdog mal außen vor).

Hmmm. Eben nicht. Es ist Bestandteil der "Polling-Philosophie", NICHT gnadenlos in einer WarteSchleife auf Dinge zu warten, die vielleicht nie eintreten werden. Von Polling spricht man, wenn man immer wieder mal hinschaut, ob sich an einer von normalerweise mehreren Schnittstellen etwas gerührt hat, um dann ggfs aktiv zu werden. Das kann natürlich dazu verleiten, andere dringende Aufgaben zu ignorieren. Aber nicht, wenn die Idee korrekt umgesetzt wird.
Ob Du dabei auf je 1 Thread für je 1 Schnittstelle setzt, oder lieber ein zyklisches Programm realisierst … dafür habe ich keinen Tipp. Ist GeschmacksSache und sicherlich auch von weiteren Faktoren abhängig. Ich hätte z.B. Hemmungen, einen "Treiber" schreiben zu müssen, da man normalerweise nichts über die Hardware-nahen Gegebenheiten erfährt, die man anbohren müsste.
Ich habe zwar in der Vergangenheit aus BASIC heraus "direkt" eine COM-Schnittstelle angesprochen oder - noch direkter - den U(S?)ART, um mit 8Bit PLUS Parity zu üben.
Aber wo gibt es diese Möglichkeiten heute noch? Wollte immer mal ein Programm, in dem ich reihum mehrere JUMO-Regler ausgehorcht habe, auf VBA unter Excel umschreiben und dort direkt die Werte in eine Tabelle schreiben, ohne erst per Q-Basic Dateien zu erzeugen und die dann später in Excel zu importieren … aber dank dem technischen Fortschritt ...

 

[reinerdoll]

konkret gehts darum, eine kleine anlage mit ein paar sps aus einem pc per opcua zu steuern. abgewickelt wird ein kleiner handshake mit order und timing.

auf sps-seite ist alles klar, egal welche sprache, im normalfall immer zyklisch. polling per schleife verträgt sich nicht mit dem zyklus, also eine schrittkette.

auf pc-seite sind dann z.b. 3 handshakes zu drei verschiedenen sps abzuwickeln. ohne threading gehts ja nur seriell, und da würde eine stehende sps (z.b. wegen wartung oder anderen randbedingungen gerade nicht auf "run") evtl. bedeuten, daß der pc in einem handshake stecken bleibt. wenn man statt polling einen zyklus, also das sps-verhalten "emuliert", gibts keine probleme.

frage ist nicht, ob das so oder so geht, natürlich kann man beides funktionsfähig, und mit watchdogs und so auch sauber programmieren : frage ist, ob es hier irgendeinen "standard" oder ähnliches gibt.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

… polling per schleife verträgt sich nicht mit dem zyklus,
… ohne threading gehts ja nur seriell,
… wenn man statt polling einen zyklus, …

Sorry, ich versuche hier weiterhin nicht, Deine Frage nach einer "PatentLösung" oder einer Standardlösung zu beantworten.
Mich stört aber weiterhin, dass Du, nur weil grottenschlechte Realisierungen des Polling denkbar sind, so tust, als sei das Polling an sich ein Verfahren, bei dem sich das Programm in einer Warteschleife festbeisst, wenn die Reaktion der Gegenseite nur allzu zögerlich oder gar nicht erfolgt.
Polling bedeutet doch nur, dass reihum immer wieder mal ein Blick auf die Schnittstelle geworfen wird, um zu ermitteln, wann HandlungsBedarf besteht bzw. entsteht.
Polling und zyklische Programmierung sind nicht von Natur aus Gegensätze (Zyklus statt Polling???) - im Gegenteil. Ob Zyklische Progammierung, ob MultiTasking in ZeitscheibenTechnik, ob Abarbeitung von Interrupts oder Ereignissen, ob Verwendung von (scheinbar) parallel ablaufenden Threads - egal, das Polling lässt sich damit allemal realisieren und ist absolut nicht gleichbedeutend mit einer Blockade von anderen Prozessen durch "konzentriertes" vergebliches Warten.
Polling bedeutet nicht, dass die Schnittstelle pausenlos überwacht wird(werden) und es dadurch unmöglich ist, auch noch andere Aufgaben zu erledigen.
Polling bedeutet auch nicht, dass es eines WatchDogs bedarf, um ein WachKoma eines Programms zu unterbrechen. In welcher nicht blockierten Task soll denn der WatchDog realisiert sein - in der blockierenden?

 

[reinerdoll]

entschuldige bitte mein beharren auf "grundsätzliches".

selbstverständlich hast du in der anlagenpraxis recht !
lehrbuch und wikipedia sind aber auf meiner seite, grundliegend ist pollig zyklisches fragen, im theoretischen fall also 100% rechenleistung ;-) ich kenne sogar realisierungen, wo das wirklich so geschrieben wird, weil der prozessor keine anderen aufgaben hat. theoretisch altenativ (in anderen umgebungen) die interruptstruktur.

trotzdem ist denke ich richtig, daß schnelles pollen viel rechenzeit kostet. bei schnellen zyklischen prozessen könnte es da auch mal kritisch werden. wenn man auf der sicheren seite bleiben will ohne viel nachdenken (was fehlerbehaftet sein kann), läßt man besser grundsätzlich die finger von solchen strukturen bei zyklischen systemen, wenn es nicht nötig ist.

ich wollte im kern meinungen hören, was den einsatz von multithreading in der prozesswelt angeht. ist ja schon ein tick komplizierter als ne einfache zyklische state machine. von der simplen sps zum threading mit semaphoren usw. auch der programmentwurf (spätestens dokumentationstechnisch...) wird schwieriger.

 

[PN/DP]

trotzdem ist denke ich richtig, daß schnelles pollen viel rechenzeit kostet. bei schnellen zyklischen prozessen könnte es da auch mal kritisch werden.

Wie schnell willst Du bzw. mußt Du denn pollen? Ich kann mir nicht vorstellen, daß für die Kommunikation mit ein paar SPS eine nennenswerte Rechenzeit-Auslastung des PC nötig ist.

Im PC muss das Polling so programmiert sein, daß es völlig egal ist, ob die erwartete Antwort sofort, oder erst nach 100 Millisekunden oder erst nach Stunden oder gar nicht kommt. An Kommunikations-Timingproblemen muß nicht die SPS dran schuld sein, es kann auch die Vernetzungsinfrastruktur ausgefallen sein. Das darf aber nicht zu Blockierungen im PC-Prozess führen.

Für die Interprozesskommunikation zwischen asynchronen Prozessen würde ich einen einfachen zyklischen Ansatz bevorzugen. Wozu etwas unnötig kompliziert machen - man erhält sicher keinen Design-Oscar für eine besonders schön komplizierte Realisierung.

Harald