Abarbeitungsreihenfolge in TIA

baprau

Level-2
Beiträge
30
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Tag,

ich hab jetzt mal ne Grundlagenfrage bezüglich der Programmabarbeitung.
in Classic habe ich gern in AWL programmiert, unter Anderem deshalb, weil ich mich darauf verlassen konnte, dass eine Anweisung dann bearbeitet wird, nachdem die vorherige Anweisung fertig bearbeitet wurde. Keine Ahnung, warum AWL in TIA nicht geht; ist vielleicht auch von der verwendeten CPU abhängig ... Das ist aber NICHT meine Frage!

Meine Frage ist, ob ich davon ausgehen kann, dass in einem in FUP oder KOP in TIA geschriebenem Programm ein Netzwerk nach dem anderen abgearbeitet wird. Sprich: kann ich davon ausgehen, dass bei Bearbeitung eines Netzwerkes das vorhergehende NW vollständig bearbeitet wurde (auch wenn dieses MOVE, S_MOVE, Chars_TO_Strg oder ähnliche Anweisungen enthält). Im Informationssystem von TIA hab ich keinen Hinweis darauf gefunden, ob vorgenannte Anweisungen ggf. mehrere Zyklen zur Bearbeitung benötigen ...

Falls es zur Beantwortung notwendig wäre, würde ich auch noch erklären, woraus mir diese Grundlagenfrage erwächst.

MfG Roland
 
Zuletzt bearbeitet:
Ja, Roland, davon darfst Du ausgehen. Alles, was nicht sofort an Ort und Stelle abgearbeitet und fertig wird, "versteckt" sich in FBs, die zyklisch aufgerufen werden und die Du nur über einen Eingang der FBs aktivierst, nachdem sie eine FertigMeldung von sich gegeben haben (z.B. KommunikationsBausteine). Ein MOVE gehört nicht dazu und belastet die ZyklusZeit entsprechend, wenn er umfangreiche Daten umschaufelt, ist dann aber fertig, ehe Dein Programm an genau der Stelle hinter dem MOVE fortgesetzt wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Roland,

es gibt auch Funktionen die über mehrere Zyklen laufen, zum Bauspiel Kommunikations-Funktionen. Diese haben i.d.R. aber dann auch einen 'Done'-Ausgang, der den vollständigen Ablauf dieser Funktion anzeigt. Die von dir genannten Funktionen zählen aber nicht dazu. Demnach ist es also so: Ein Netzwerk nach dem anderen.
Die Abarbeitungsreihenfolge innerhalb eines Netzwerkes (interessant wenn zum Beispiel Zwischenergebnisse erzeugt und an anderer Stelle weiter verarbeitet werden) ist bei größeren Netzwerken aber (jedenfalls für mich) manchmal nur schwer erkennbar.

Frank
 
Danke für die Antwort. Allerdings stehe ich damit mit meinem Problem am Anfang.
Ziel ist, Daten von einer Serveranwendung zum bestimmten Zeitpunkt zu lesen. Jetzt sind aber die dort erfassten Daten nicht schlüssig. Beim Hersteller der Serveranwendung habe ich angerufen: der behauptet, die Daten werden beim Trigger zyklusgenau gelesen. Heinileini bestätigt mir meine Vermutung bezüglich Bearbeitung in der SPS.
Jetzt habe ich keinen Schuldigen :(
... wahrscheinlich doch der Programmierer (also ich)
 
Danke für die Antwort. Allerdings stehe ich damit mit meinem Problem am Anfang.
Ziel ist, Daten von einer Serveranwendung zum bestimmten Zeitpunkt zu lesen. Jetzt sind aber die dort erfassten Daten nicht schlüssig. Beim Hersteller der Serveranwendung habe ich angerufen: der behauptet, die Daten werden beim Trigger zyklusgenau gelesen.
Wie genau liest die Serveranwendung die Daten? OPC / OPC UA / Irgendwas TCP / Modbus ....... ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Abarbeitungsreihenfolge innerhalb eines Netzwerkes (interessant wenn zum Beispiel Zwischenergebnisse erzeugt und an anderer Stelle weiter verarbeitet werden) ist bei größeren Netzwerken aber (jedenfalls für mich) manchmal nur schwer erkennbar.
So gesehen ist KOP gegenüber FUP aber noch sehr übersichtlich. Aber KOP weicht auf die DarstellungsFormen von FUP aus, sobald es nicht mehr um reine BitVerknüpfungen geht.
So richtig ins Zweifeln kann man z.B. bei der FUB-Darstellung der LOGO geraten, die nicht einmal die Untergliederung in Netzwerke kennt. Aber es funktioniert! Die Schaltung muss natürlich sauber in die erforderliche, eindeutige Reihenfolge der AbarbeitungsSchritte umgesetzt werden, aber das tut das "BetriebsSystem" - da muss sich nicht der Programmierer rum kümmern.

Früher konnte man sich noch selbst davon überzeugen, als die KOPs und FUPs sich auch als AWL darstellen liessen.
 
... "Irgendwas TCP" gehe ich davon aus, genau weiß ich das nicht. Ist jedenfalls über Netzwerk verbunden.
Die Anwendung heißt "Accon-EasyLog". Vielleicht kennt das ja jemand.
 
Ziel ist, Daten von einer Serveranwendung zum bestimmten Zeitpunkt zu lesen. Jetzt sind aber die dort erfassten Daten nicht schlüssig.
Wessen Daten sind wo nicht schlüssig bzw. inkonsistent?

Wenn Deine Daten nicht konsistent sind, die der Server von Dir erhält bzw. liest, dann kannst Du die Daten selbst zu einem definierten Zeitpunkt in einen Puffer kopieren. Der Server erhält dann den Zustand zu diesem Zeitpunkt, selbst wenn die einzelnen Daten zwischenzeitlich nicht mehr alle aktuell zum Zeitpunkt des Auslesens passen.

Wenn Du aus dem Server Daten erhältst, die dort schon nicht mehr konsistent sind, dann ... :ROFLMAO:
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Jetzt sind aber die dort erfassten Daten nicht schlüssig.
Meinst du die Daten kommen nur Teilweise, oder .. ?
Beim Hersteller der Serveranwendung habe ich angerufen: der behauptet, die Daten werden beim Trigger zyklusgenau gelesen.
Wie werden die Daten gelesen und in deine Steuerung gesendet ?
Das Problem lautet für mich als fehlende Konsistenz.
Daten konsistent übertragen geht nur mittels Send/Receive, oder mittels Profinet IO (I-Device oder PN/PN Koppler) und konsistente Transferbereiche.
 
Ich erklär das jetzt doch nochmal genauer:
Der Server liest permanent vereinbarte Variablen im einstellbaren Lesetakt (kleinster einstellbarer Intervall 10 ms) von der Steuerung. Wird am vereinbarten Triggerbit eine positive Flanke erkannt, erzeugt die Anwendung aus den gelesenen Daten eine csv-Datei.
In der SPS habe ich das jetzt so gelöst, dass ich in einem Bereich von mehreren Netzwerken die benötigten Daten in den vom Server zu lesenden Bereich kopiere. Dieser Bereich wird bedingt übersprungen, wenn die Bedingung zum lesen nicht erfüllt ist. Im letzten Netzwerk des sonst übersprungenen Bereichs wird das Triggerbit gesetzt und die Einsprungbedingung rückgesetzt. Das Triggerbit wird dann vom Server nach erfolgreicher Dateierstellung wieder rückgesetzt. Wenn ich diese Rückmeldung erhalte (Triggerbit "0"), wird der gelesene Bereich geleert (um sicher zu stellen, dass keine falschen / alte Daten erfasst werden)
Somit wird der Bereich, in dem die Daten von der SPS in den zu lesenden Bereich kopiert werden für einen Zyklus bearbeitet. Die Daten müssten aber dort zur Verfügung stehen, solange das Triggerbit noch nicht wieder auf "0" gegangen ist. In den meisten Fällen funktioniert das wie erwartet, ab und zu sind aber Felder in der erzeugten csv-Datei leer. ... und ich hab immer noch keine Ahnung, woran das liegt.
Ob ich das jetzt verstehbar erklärt habe, weiß ich ebenfalls nicht ;)
 
Server einerseits und SPS andererseits sind mir klar. Wer ist nun die "Anwendung"?
Wenn der Server vereinbarte Daten aus der SPS liest, wozu dann noch eine CSV-Datei?
Du arbeitest in einem 10 ms-Intervall. Wie lang ist Deine Zykluszeit? Kannst Du in dem 10 ms-Intervall mehrere Zyklen durchlaufen?

PS:
- Löschen des Puffers sollte überflüssig sein, kann Dir aber behilflich sein, ein Fehlverhalten zu beobachten.
- Die ganzen MOVEs in den Puffer würde ich auf einen einzigen Zyklus begrenzen, in dem dann auch an den Server gemeldet wird, dass er lesebereit ist.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Wer ist nun die "Anwendung"? --> Accon-EasyLog
Wenn der Server vereinbarte Daten aus der SPS liest, wozu dann noch eine CSV-Datei? --> die wird im EDV-System weiterverarbeitet und ist eigentliches Ziel der ganzen Übung
Du arbeitest in einem 10 ms-Intervall. Wie lang ist Deine Zykluszeit? Kannst Du in dem 10 ms-Intervall mehrere Zyklen durchlaufen? --> der Zyklus läuft durchschnittlich 1 - 3ms; das dürfte aber in soweit nicht von Belang sein, dass die Daten in der SPS solange anstehen, bis das Triggerbit von EasyLog rückgesetzt wird.
 
ich denke, ich werde das jetzt so machen, dass ich noch eine kleine "Kunstpause" einlege, bevor ich das Triggerbit auf "1" setze nachdem das Kopieren fertig ist.
Vielleicht erkennt ja die Serveranwendung aus unerfindlichem Grund eine Flanke am Triggerbit, hat aber noch Daten von der vorhergehenden Lesung im Ram (oder weiß ich wo) stehen.
 
ich denke, ich werde das jetzt so machen, dass ich noch eine kleine "Kunstpause" einlege, bevor ich das Triggerbit auf "1" setze nachdem das Kopieren fertig ist.
Vielleicht erkennt ja die Serveranwendung aus unerfindlichem Grund eine Flanke am Triggerbit, hat aber noch Daten von der vorhergehenden Lesung im Ram (oder weiß ich wo) stehen.
Ausgerechnet an dieser Stelle würde ich keine KunstPause einlegen. Diese Zeit geht Dir nutzlos verloren.
Der Server darf doch erst seine LeseAktion starten, nachdem er das TriggerBit empfängt und während Du den Puffer unberührt lässt!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ausgerechnet an dieser Stelle würde ich keine KunstPause einlegen. Diese Zeit geht Dir nutzlos verloren.
Der Server darf doch erst seine LeseAktion starten, nachdem er das TriggerBit empfängt und während Du den Puffer unberührt lässt!

was schlägst du statt dessen vor?
 
Ausgerechnet an dieser Stelle würde ich keine KunstPause einlegen. Diese Zeit geht Dir nutzlos verloren.
Der Server darf doch erst seine LeseAktion starten, nachdem er das TriggerBit empfängt und während Du den Puffer unberührt lässt!
Easylog liest einfach ein Anzahl von Variabeln.
Das Problem ist dass diese Verfahren einfach nicht konsistent ist.
Die Lösung mit die Verzögerung von das Triggerbit ist 'unschön' aber wird funktionieren.
 
Easylog liest einfach ein Anzahl von Variabeln.
Das Problem ist dass diese Verfahren einfach nicht konsistent ist.
Die Lösung mit die Verzögerung von das Triggerbit ist 'unschön' aber wird funktionieren.
D.h. Easylog liest pausenlos vor ich hin und erfährt gar nicht, ab wann es aktiv werden soll? Dann könnte allerdings die KunstPause scheinbar helfen, aber die Triggerung ist dann nur "AugenWischerei" und die Konsistenz nach wie vor rein zufällig!? Der Server muss also Easylog genügend Zeit lassen, nachdem die SPS den Puffer eingefroren hat?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
D.h. Easylog liest pausenlos vor ich hin und erfährt gar nicht, ab wann es aktiv werden soll?
Ehrlich gesagt, ich habe keine reale Erfahrung mit Easylog. Wenn ich die Deltalog Webseite anschaut steht nichts über konsistenz.
Ich nehme an, die Variabeln werden zyklisch aufgerufen mit die Frequenz der eingestellt ist. Wenn der Trigger-Bit wechselt, werden die zuletzt gelesene Daten abgespeichert.
Wäre schön wenn den Thementitel "Easylog" inkludiert hätte. Dann hätte Rainer vielleicht seinen Senf mitteilen können.

Der Server muss also Easylog genügend Zeit lassen, nachdem die SPS den Puffer eingefroren hat?
So sehe ich es.
 
Der Server liest permanent vereinbarte Variablen im einstellbaren Lesetakt (kleinster einstellbarer Intervall 10 ms) von der Steuerung. Wird am vereinbarten Triggerbit eine positive Flanke erkannt, erzeugt die Anwendung aus den gelesenen Daten eine csv-Datei.
Werden alle Variablen und das Triggerbit gleichzeitig mit dem selben Datentelegramm aus der SPS gelesen? Oder werden alle Variablen nach der positiven Flanke des Triggerbits (ggf. noch einmal) gelesen?

Dein eigentlich unnötiges Nullsetzen der Ausgabewerte macht sichtbar, daß der Leseablauf in der externen ServerAnwendung falsch funktioniert. Zyklisch sämtliche Variablen einzeln lesen und csv-Datei schreiben sobald das Triggerbit eine positive Flanke hat, funktioniert nicht, wenn vor dem Triggerbit die Variablen mit ungültigem Inhalt gelesen wurden. Der Server muß/darf die Variablen erst dann lesen, wenn sie gültige Werte haben, was durch das gesetzte Triggerbit signalisiert wird, d.h. er braucht/muß zunächst nur das Triggerbit lesen (pollen). (Oder er muß alle Variablen und das Triggerbit gleichzeitig mit dem selben Kommunikationsauftrag lesen.)

Der Server muß zyklisch das Triggerbit lesen, und wenn die 0-1-Flanke erkannt wurde danach die Variablenwerte lesen, weil der Inhalt der Variablen erst ab diesem Zeitpunkt gültig ist.
Etwa so (Pseudocode):
Code:
Triggerbit := KommReadTriggerbit();
IF Triggerbit THEN
  KommReadPayload();
  KommWriteTriggerbit(FALSE);
  WriteCSVfile();
END IF;
Dein SPS-Programm muß die Daten so zur Verfügung stellen:
Code:
IF NOT Triggerbit THEN
  Ausgabepuffer := Ausgabedaten; //Werte aller Variablen in die KommunikationsVariablen kopieren
END IF;

IF Triggerereignis_posFlanke THEN
  Triggerbit := TRUE; //das Triggerbit wird von der externen Anwendung nach dem Lesen auf FALSE rückgesetzt
END IF;

Wie schnell und oft muß denn Dein System die Werte wegschreiben?
Liest Accon-EasyLog die Variablen einzeln oder als Byte-Block?
Welche SPS/CPU hast Du?

Möglicherweise wird für das Lesen der Werte von Accon-EasyLog Dein Programm unterbrochen. Deshalb darf das Triggerbit erst gesetzt werden, wenn gültige Werte in den Kommunikationsvariablen drin sind, damit der Kopiervorgang selber nicht unterbrochen wird (Variablen-Konsistenz!).

Harald
 
Zurück
Oben