# Abarbeitungsreihenfolge in TIA



## baprau (4 November 2020)

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


----------



## Heinileini (4 November 2020)

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.


----------



## Fireman_Frank (4 November 2020)

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


----------



## baprau (4 November 2020)

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)


----------



## MSB (4 November 2020)

baprau schrieb:


> 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 ....... ?


----------



## Heinileini (4 November 2020)

Fireman_Frank schrieb:


> 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.


----------



## baprau (4 November 2020)

... "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.


----------



## Heinileini (4 November 2020)

baprau schrieb:


> 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 ...


----------



## JesperMP (4 November 2020)

baprau schrieb:


> Jetzt sind aber die dort erfassten Daten nicht schlüssig.


Meinst du die Daten kommen nur Teilweise, oder .. ?


baprau schrieb:


> 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.


----------



## baprau (4 November 2020)

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


----------



## Heinileini (4 November 2020)

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.


----------



## baprau (4 November 2020)

_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.


----------



## baprau (4 November 2020)

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.


----------



## Heinileini (4 November 2020)

baprau schrieb:


> 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!


----------



## baprau (4 November 2020)

Heinileini schrieb:


> 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?


----------



## JesperMP (4 November 2020)

Heinileini schrieb:


> 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.


----------



## Heinileini (4 November 2020)

JesperMP schrieb:


> 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?


----------



## JesperMP (4 November 2020)

Heinileini schrieb:


> 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.



Heinileini schrieb:


> Der Server muss also Easylog genügend Zeit lassen, nachdem die SPS den Puffer eingefroren hat?


So sehe ich es.


----------



## Blockmove (4 November 2020)

Such mal hier nach dem Stichwort "Zykluskontrollpunkt".
Vielleicht erklärt das dein Problem


----------



## PN/DP (4 November 2020)

baprau schrieb:


> 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):

```
Triggerbit := KommReadTriggerbit();
IF Triggerbit THEN
  KommReadPayload();
  KommWriteTriggerbit(FALSE);
  WriteCSVfile();
END IF;
```
Dein SPS-Programm muß die Daten so zur Verfügung stellen:

```
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


----------



## baprau (4 November 2020)

@Heinileini:
_- Löschen des Puffers sollte überflüssig sein, kann Dir aber behilflich sein, ein Fehlverhalten zu beobachten._   --> sag ich ja
_- 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._   --> genau so hatte ich es ja (siehe meinen vorherigen Beitrag)

@JesperMP:
_Wäre schön wenn den Thementitel "Easylog" inkludiert hätte. Dann hätte Rainer vielleicht seinen Senf mitteilen können. _  --> ich weiß nicht, wer Rainer ist, hatte aber heute früh schon Probleme damit, das Thema treffend zu benennen 


... Jedenfalls habe ich die "Kunstpause" jetzt eingebaut und werde das beobachten. Ist zwar unschön aber möglicherweise zielführend: bis jetzt gab's noch keine fehlerhaften Dateien wieder 

Danke für euer (Mit)Denken


----------



## baprau (4 November 2020)

jetzt hab ich mal noch ne allgemeine Handlingsfrage (aber net auslachen!)
Wie macht ihr das eigentlich, wenn ihr einzelne Textabschnitte zitiert? Ich kann immer nur den ganzen Beitrag zitieren (mit der Schaltfläche unten rechts am Kasten) ... ???


----------



## JesperMP (4 November 2020)

Rainer Hönle ist von DeltaLogic und ist sehr hilfreich wenn es um Deltalogic geht.

Wenn du etwas zitierst, dann ensteht es ein Textblock der mit reckteckige Klammer und QUOTE umgerandet ist.
Innerhalb von die QUOTEs kannst du editieren (und verfälschen) wie du willst.


----------



## PN/DP (4 November 2020)

baprau schrieb:


> ich weiß nicht, wer Rainer ist


Damit ist Rainer Hönle gemeint, der Chef von Delta Logic, dem Hersteller der Software ACCON-EasyLog. Rainer liest hier oft mit, und könnte Hinweise zu Details von ACCON-EasyLog geben.



baprau schrieb:


> ... Jedenfalls habe ich die "Kunstpause" jetzt eingebaut und werde das beobachten. Ist zwar unschön aber möglicherweise zielführend: bis jetzt gab's noch keine fehlerhaften Dateien wieder


Das ist vermutlich auch nur unsichere Stümperei. Macht ein funktionierendes Handshake mit dem Triggerbit, siehe Beitrag #20

Harald


----------



## baprau (4 November 2020)

PN/DP schrieb:


> Damit ist Rainer Hönle gemeint, der Chef von Delta Logic, dem Hersteller der Software ACCON-EasyLog.



na DAS wäre ja tatsächlich der richtige Ansprechpartner für mein Problem gewesen.
Wie schon im Verlauf erwähnt, hatte ich beim Service von Delta Logic angerufen und dort die Aussage erhalten, dass die gelesenen Daten tatsächlich aus dem jeweils gleichen SPS-Zyklus stammen (überzeugend klang der aber nicht)



PN/DP schrieb:


> Das ist vermutlich auch nur unsichere Stümperei. Macht ein funktionierendes Handshake mit dem Triggerbit, siehe Beitrag #20



mit Sicherheit ist das unsichere Stümperei. Aber wie der EasyLog liest hab ich weder Ahnung noch Einfluss. Ich kann mich nur auf die Beschreibung der Software verlassen (... und bin vermutlich damit verlassen)

Roland


----------



## hucki (4 November 2020)

baprau schrieb:


> Wie macht ihr das eigentlich, wenn ihr einzelne Textabschnitte zitiert? Ich kann immer nur den ganzen Beitrag zitieren (mit der Schaltfläche unten rechts am Kasten) ... ???


(Komplettes) Zitat kopieren und erneut einfügen. Dann beim jeweiligen Zitat das rauslöschen, was nicht benötigt wird.
Links oben kann man auch zum Standard-Editor umschalten und dann nur die Zitat-(Ende)-Tags kopieren und an entsprechender Stelle einfügen.


----------



## PN/DP (4 November 2020)

Wenn die Server-Anwendung sich an den richtige Leseablauf mit dem Handshake hält, dann ist es relativ egal wie genau EasyLog die Variablen liest. Die Aufgabe des SPS-Programms ist lediglich, die Daten während gesetztem Triggerbit nicht zu verändern. Und die ServerAnwendung darf keinen Daten von Zeitpunkten vor dem gesetzten Triggerbit verarbeiten.

Harald


----------



## baprau (4 November 2020)

PN/DP schrieb:


> Wenn die Server-Anwendung sich an den richtige Leseablauf mit dem Handshake hält, dann ist es relativ egal wie genau EasyLog die Variablen liest. Die Aufgabe des SPS-Programms ist lediglich, die Daten während gesetztem Triggerbit nicht zu verändern. Und die ServerAnwendung darf keinen Daten von Zeitpunkten vor dem gesetzten Triggerbit verarbeiten.
> 
> Harald



ja, das ist schon klar.
nur das zweite kann weder sicher nachvollziehen geschweige denn beeinflussen.


----------



## PN/DP (4 November 2020)

baprau schrieb:


> Beim Hersteller der Serveranwendung habe ich angerufen: der behauptet, die Daten werden beim Trigger zyklusgenau gelesen.


Was meint der mit "_zyklusgenau_"? Daß alle Variablen und das Triggerbit in einer einzigen Abfrage gelesen werden?

Harald


----------



## baprau (4 November 2020)

ja.
das ist allerdings meine Fofmulierung; ich hatte das so gefragt. Aber wie gesagt: überzeugend klang die Antwort nicht (eher so "man muss auch manchmal ja sagen, damit man seine Ruhe hat)


----------



## baprau (4 November 2020)

... also aus dem gleichen SPS-Zyklus stammen


----------



## ducati (4 November 2020)

baprau schrieb:


> ... also aus dem gleichen SPS-Zyklus stammen




Was für eine SPS ist das denn jetzt? Oder hab ichs überlesen? Ich vermute S7-1500 oder S7-1200 wegen TIA? Da werden die VAriablen immer parallel zum SPS-Zyklus gelesen.

Bei S7-300 war das noch anders...

Gruß.


----------



## baprau (4 November 2020)

ja, das ist ne 1200er



ducati schrieb:


> Da werden die VAriablen immer parallel zum SPS-Zyklus gelesen.



meinst du jetzt von easylog? oder wer liest parallel zum Zyklus?


----------



## PN/DP (4 November 2020)

Also wenn die Serveranwender behaupten, daß die Variablenwerte inkl. Triggerbit alle aus dem selben SPS-Zyklus stammen, dann müssen sie die Werte in nur einer Kommunikationsanfrage lesen, und dann auch zusammen "konsistent" verarbeiten. Als Block oder Multi-Variablen-Read. (Oder kann man bei der S7-1200 das Bearbeiten aller Kommunikationsanfragen im selben SPS-Zyklus besonders mitteilen/erzwingen? Und wird das auch tatsächlich gemacht?)



baprau schrieb:


> 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. (...)
> Somit wird der Bereich, in dem die Daten von der SPS in den zu lesenden Bereich kopiert werden für einen Zyklus bearbeitet.


Hast Du Dich nur unklar/unvollständig ausgedrückt oder wird das Kopieren der Werte in den Kommunikationsbereich dauernd ausgeführt solange der Kommunikationspartner lesen soll? Wann genau wird kopiert, wann genau wird übersprungen?

Oder kopierst Du tatsächlich nur einmalig (nur einen Zyklus lang) die Werte in den Kommunikationsbereich und setzt anschließend das Triggerbit? Und solange das Triggerbit TRUE ist, schreibst Du nicht in den Kommunikationsbereich? Weder sich ändernde Daten noch Löschwerte?
Dann kann es nicht zu falschen Daten beim Kommunikationspartner kommen, wenn die Serveranwendung so liest wie behauptet: das Triggerbit = 1 stammt aus dem selben SPS-Zyklus bzw. der selben Kommunikationsanfrage wie die Variablenwerte. (Es wäre sogar egal, ob die Variablen am Stück oder einzeln gelesen werden, nachdem das Triggerbit als 1 gelesen wurde).
Irgendjemand macht was anders als behauptet.
Kannst Du uns auszugsweise Deinen Code mit der Logik zum Überspringen des Kopier-Codes und Setzen des Triggerbits und Löschen des Bereichs zeigen? 1000 Worte können nicht so klar und korrekt ausdrücken was der Code tut, als wenn man den Code selber zeigt.



baprau schrieb:


> In den meisten Fällen funktioniert das wie erwartet, ab und zu sind aber Felder in der erzeugten csv-Datei leer.


Was meinst Du mit "_leer_"? Wirklich ganz leer oder sind die Werte = 0?

Nochmal nachfragen: wie schnell und oft müssen die Werte vom Server gelesen werden?

Harald


----------



## PN/DP (4 November 2020)

baprau schrieb:


> meinst du jetzt von easylog? oder wer liest parallel zum Zyklus?


Das ist so gemeint: Bei der S7-1200 wird S7-Kommunikation nicht im Zykluskontrollpunkt bearbeitet, sondern "parallel" während das SPS-Programm ausgeführt wird und unterbricht dafür irgendwann das SPS-Programm. Das kann auch mitten in Deinem Kopieren der Werte in den Kommunikationsbereich passieren - dann ist die Aussage "zyklusgenau" für die Katz, wenn ein Teil der Werte von vor dem kompletten Füllen des Kommunikationsbereiches stammt.

Harald


----------



## ducati (5 November 2020)

PN/DP schrieb:


> Das ist so gemeint: Bei der S7-1200 wird S7-Kommunikation nicht im Zykluskontrollpunkt bearbeitet, sondern "parallel" während das SPS-Programm ausgeführt wird und unterbricht dafür irgendwann das SPS-Programm. Das kann auch mitten in Deinem Kopieren der Werte in den Kommunikationsbereich passieren - dann ist die Aussage "zyklusgenau" für die Katz, wenn ein Teil der Werte von vor dem kompletten Füllen des Kommunikationsbereiches stammt.
> 
> Harald


kommt auch noch drauf an, wieviele Daten das sind und wie viele Kommunikationsaufträge das sind. U.U. wird das SPS Programm mehrfach unterbrochen und dass sogar über mehrere SPS Zyklen, bis alles einmal gelesen ist...


----------

