TIA Zykluskontrollpunkt S7-1500

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei uns hat das 2 recht strikte, aber klare Regeln zur Folge:
1. es gibt nur optimierte Bausteine (mir ist bisher keine Ausnahme bekannt)

Das schränkt dann aber schon ziemlich ein. Denn Ueberlagerungen sind ja so nicht mehr möglich. Da wäre man ja mit nur "nicht optimiert" wesentlich offener

2. Variablen mit HMI-Zugriff sind entweder HMI rw + PLC ro oder HMI ro + PLC rw. Zulässige Ausnahme sind nur das Ablöschen von HMI-Kommandos bei Kommunikationsausfall und das Überschreiben von HMI rw-Feldern mit sicheren Werten. Gleiches gilt für OPC.

Wie macht ihr dann Quittierungen oder Sollwerte von mehreren Stellen? Alles mit Handshakes?

mfG René

 

[maxder2te]

Wenn man es sich selber raussuchen kann ...
Wir bekommen die Datenstrukturen vorgegeben und diese sind auf allen S7-Baureihen fix.
Somit scheiden optimierte Schnittstellen-DBs aus.

Ok.....
Wir darf ich mir das vorstellen? Greift hier ein Leitsystem über einen Nicht-Siemens-Treiber zu?

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das schränkt dann aber schon ziemlich ein. Denn Ueberlagerungen sind ja so nicht mehr möglich. Da wäre man ja mit nur "nicht optimiert" wesentlich offener

jo...

bei uns generell alles NICHT optimiert... (bis auf Siemens Cont_C, da geht's nicht anders)

gruß.

 

[maxder2te]

Das schränkt dann aber schon ziemlich ein. Denn Ueberlagerungen sind ja so nicht mehr möglich. Da wäre man ja mit nur "nicht optimiert" wesentlich offener

Ich selber habe noch nie Überlagerungen genutzt.
Das einzige Einsatzszenario, das mir sinnvoll erscheint, ist das Entpacken und Packen von Rohdaten. Hier bevorzuge ich das Spreizen-durch-Umkopieren, auch wenn es nicht so effizient ist, es ist aber flexibler und imho besser lesbar.
Wo nutzt du das sonst?

Wie macht ihr dann Quittierungen oder Sollwerte von mehreren Stellen? Alles mit Handshakes?

Das Schreiben von ein und demselben Feld (z.B. eine Sollgeschwindigkeit) durch mehrere HMIs ist kein Problem, dass 2 Leute gleichzeitig den selben Sollwert verändern ist sehr unwahrscheinlich.
Schnittstellen für Kommandos (Jog-Funktionen, Achsen justieren, usw.) werden für jede HMI separat bereitgestellt.
Bei der Abwicklung von Kommunikation mit HMI-Skripten oder Leitsystemen werden 3- oder 4-Bit Handshakes gebaut.

Sehr wichtig ist die genannte Regel z.B. dann, wenn die HMI einen Array-Index verändern kann. Der folgende Code soll das verdeutlichen:

daten : ARRAY[0..63] OF INT;
idx: INT;  // HMI-rw
idxLocal: INT;  // PLC-rw, kein HMI-Zugriff
n : INT;  // ist z.B. globale DB-Variable, die angibt, wieviele Einträge im Feld 'daten' existieren, dass 0 < n < 64 ist, wird extern garantiert

idxLocal := idx;
// ab dieser Zeile wird noch auf idxLocal lesend zugegriffen, so kann garantiert werden, dass eine Änderung von idx zwischen 2 Zeilen keine Inkonsistenz bringt
IF ((n = 0) OR (idxLocal < 0)) THEN
    idxLocal := 0;
ELSIF (idxLocal >= n) THEN
    idxLocal := n-1;
END_IF;
idx := idxLocal;

lg

 

[Thomas_v2.1]

idxLocal := idx;
// ab dieser Zeile wird noch auf idxLocal lesend zugegriffen, so kann garantiert werden, dass eine Änderung von idx zwischen 2 Zeilen keine Inkonsistenz bringt
IF ((n = 0) OR (idxLocal < 0)) THEN
    idxLocal := 0;
ELSIF (idxLocal >= n) THEN
    idxLocal := n-1;
END_IF;
idx := idxLocal;

Und wenn der HMI-Befehl zwischen der ersten und letzten Zeile im des obigen Codes SPS-Programm eintrifft, dann geht der Befehl verloren. Das ist doch genau das Problem.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und wenn der HMI-Befehl zwischen der ersten und letzten Zeile im des obigen Codes SPS-Programm eintrifft, dann geht der Befehl verloren. Das ist doch genau das Problem.

Du hast recht. Darüber sollte ich nochmal nachdenken. Aktuell wiegt ein ungültiger Array-Zugriff schwerer, der mit o.g. Code verhindert wird.

 

[Blockmove]

Ok.....
Wir darf ich mir das vorstellen? Greift hier ein Leitsystem über einen Nicht-Siemens-Treiber zu?

Die Kommunikation erfolgt über einen OPC-Server.
Die Datenstrukturen sind vorgegeben und fix für alle Steuerungsreihen.
Somit scheiden optimierte DBs aus.
Auf OPC-Seite wird im einfachsten Fall nur die Konfig für eine Anlage kopiert, IP, Rack und Slot eingetragen -> Fertig.
Also durchaus sinnvoll.
Die Strukturen sind thematisch gegliedert und nicht strikt nach Read / Write / Handshake getrennt.
Ist vielleicht nicht optimal, stellte aber bislang überhaupt kein Problem dar.

S7-300 hat den Zykluskontrollpunkt, somit kein Problem.

S7-400 hat keinen Zykluskontrollpunkt, somit Zugriff aus dem S7-Programm mit InOut und Call-by-Reference.

S7-1500 hat keinen Zykluskontrollpunkt und "seltsame" Verhältnisse aus Call-by-Value und Call-by-Reference.
Somit ist die Gefahr groß, dass dir hier Fehler unterlaufen und Daten verschwinden bzw. überschrieben werden.

Gruß
Blockmove

 

[Thomas_v2.1]

Optimierte DBs helfen da auch nicht überall.
Wie in dem anderen Thread zur Datenkonsistenz erwähnt, ist mit "optimierten" Bereichen bei Strings kein garantiert konsistenter Datenaustausch mit einem HMI möglich. Bei "nicht optimierten" Bereichen kannst du immer noch mit UBLKMOV arbeiten.

Da ist die TIA Dokumentation auch fehlerhaft. Denn diese behauptet, dass eine einzelne Variable immer konsistent gelesen werden kann.
Das gilt so wie es aussieht nur mit der Einschränkung auf Variablen elementaren Datentyps.

Ich habe gerade wieder so einen Fall: Kunde kann nur OPC-DA, und das funktioniert bei der S7-1500 nur mit "nicht optimierten" DBs. Und wenn eine Variable im Programm dann aus "nicht optimierten" Bereichen kommt, dann ändert sich ja das Verhalten in bestimmten Bausteinen. D.h. wenn ich mein Programm mit der Parameterübergabe auf "optimiert" auslege, dann kann ich eigentlich nicht einfach so einen DB auf "nicht optimiert" ändern, ohne wirklich jede Codestelle zu prüfen.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe gerade wieder so einen Fall: Kunde kann nur OPC-DA, und das funktioniert bei der S7-1500 nur mit "nicht optimierten" DBs. Und wenn eine Variable im Programm dann aus "nicht optimierten" Bereichen kommt, dann ändert sich ja das Verhalten in bestimmten Bausteinen. D.h. wenn ich mein Programm mit der Parameterübergabe auf "optimiert" auslege, dann kann ich eigentlich nicht einfach so einen DB auf "nicht optimiert" ändern, ohne wirklich jede Codestelle zu prüfen.

Manche OPC-Server können in der Zwischenzeit optimierte DBs.

Die Paarung nicht optimierter Daten-DB und Übergabe in einen optimierten FB heißt auf jedenfall Call-by-Value.
Und damit ist Ärger vorprogrammiert.

 

[Jochen Kühner]

Ja, z.B. der Tani Opc soll Symbolischen Zugriff ermöglichen...

 

[Blockmove]

softing dataFeed müsste mittlerweile auch optimierte DBs können

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich denke es wird langsam Zeit fuer ne 1600er CPU bei der das ganze mal ordentlich, einfach, nachvollziehbar funktioniert.
Die ganzen Missstaende der 1200/1500er, welche aus Kompatibilitaetsgruenden nicht mehr geaendert werden koennen, fuellen ja schon Baende...
Gruss