S7 1200

[Werner29]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ob das auch mit CoDeSys geht? - paralleles Arbeiten von verschiedenen
Rechnern mit gleichen oder verschiedenen Programmteilen
an der gleichen CPU?

Geht nicht. Positiv ausgedrückt: das Projekt muss immer als ganzes übersetzbar sein, bevor ein Online Change durchgeführt werden kann. Man kann nicht eine Schnittstelle ändern und runterladen ohne das der Aufruf dazu auch stimmt. Wenn ich es richtig verstanden habe kann man bei Siemens ja durchaus inkompatible POUs einspielen.

 

[IBFS]

Ja, SIEMENS unterstützt den "VIRTUOSEN" Programmierstil ich liiiiebe das!

 

[Werner29]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich sag ja nicht, dass das nicht manchmal praktisch ist. Aber ich würde diese Art von Online Change nicht unbedingt beim Kernkraftwerk empfehlen.
Aber das habe ich richtig verstanden: man kann bei Siemens die Daten eines Bausteins ändern, aber dann verliert der seine aktuellen Werte und wird initialisiert? Wozu kann man denn das brauchen?

 

[zotos]

...
Im übrigen arbeiten wir bei uns zu zweit oder dritt an einer CPU und
machen das permannent auch parallel.
...

Was ist der Grund für das vorgehen? Schlechte Hardwareplanung oder unfähige Programmierer?
Die Zeiten wo eine CPU halbe Werkhallen steuert sollte eigentlich Vergangenheit sein? Sind das anlagen von ehemaligen VEBs (Volkseigene Betriebe)?

Zurück zum Thema: Geht denn die von dem Kollegen IFBS angesprochene "VIRTUOSE" Programmierung auch auf einer S7-1200? Ging das denn schon bei der S7-200?

PS: Wer sich mal bei einer solchen Aktion mehrere Programmierer parallel an einem Sepp7-Projekt sich das selbige mal auf dem Server geschossen hat hebe die Hand. :s12::s12: (Wir waren ja auch zu zweit an dem Projekt. Hoffentlich stimmt mein Kollege nicht auch noch ab ;o) )

 

[crash]

Wer die 1200er testen möchte...
Die S7-1200 ist jetzt verfügbar.
https://mall.automation.siemens.com/DE/guest/index.asp?aktPrim=0〈=de

 

[Perfektionist]

Zuviel Werbung?
-> Hier kostenlos registrieren

...
EXAKT so ist das!
...

sorry, dann hab ich wohl diese Meldung: "Bitte prüfen sie die für die Übertragung erforderliche Reihenfolge der Bausteine" wohl immer missinterpretiert
ich werd mal bei nächster Gelegenheit testen (vermutlich gibt es auch bei der S7-300 eine Mengenbegrenzung).

 

[Perfektionist]

... (vermutlich gibt es auch bei der S7-300 eine Mengenbegrenzung).

und die beträgt genau eins!

das hier:

FUNCTION_BLOCK "testchange"
TITLE =
VERSION : 0.1
 
VAR_INPUT
  IN0 : BOOL ; // wurde dann nachträglich eingefügt
  I_True : BOOL  := TRUE; 
  I_False : BOOL ; 
END_VAR
BEGIN
NETWORK
TITLE =
      ON    #I_True; 
      O     #I_False; 
      S     "Fehler"; 
      U     "Anlauf"; // SPS-Neustart
      R     "Fehler"; 
 
END_FUNCTION_BLOCK
FUNCTION_BLOCK "Steuerung"
TITLE =
VERSION : 0.1
BEGIN
NETWORK
TITLE =
      CALL "testchange" , "testchange_Instanz" ;
 
END_FUNCTION_BLOCK

lässt sich mitsamt dem dazugehörigen DB nicht auf eine 319 so übertragen, dass nicht anschliessend der Fehler-Merker gesetzt ist. Und das liegt eben daran:

 

[Ralle]

lässt sich mitsamt dem dazugehörigen DB nicht auf eine 319 so übertragen, dass nicht anschliessend der Fehler-Merker gesetzt ist. Und das liegt eben daran:

Das hat aber was mit den Dateninhalten zu tun. Ist die SPS auf Stop gegangen beim Übertragen, wegen fehlendem DB oder FB etc? Wenn nein, dann geht es doch. Das Fenster sagt doch gar nchts. WinCCFlex generiert auch dauernd neu, selbst wenn man das PRojekt nur geöffnet und nichts verändert hat.

 

[BoxHead]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wahrscheinlich ist die SPS nicht in Stopp gegangen. Aber dennoch lässt das Experiment die Vermutung zu, dass der Programmcode (FB) und der Datenspeicher (DB) in unterschiedlichen Zyklen übertragen wurden.

 

[Ralle]

Wahrscheinlich ist die SPS nicht in Stopp gegangen. Aber dennoch lässt das Experiment die Vermutung zu, dass der Programmcode (FB) und der Datenspeicher (DB) in unterschiedlichen Zyklen übertragen wurden.

Das ist sicher so. Die Frage ist wann genau die geänderten Bausteine aktiviert werden, und ob das für FB und DB gleichermaßen gilt.

 

[BoxHead]

Richtig erklären kann ich es mir aber ehrlich gesagt nicht warum diese Fehlerbit auf TRUE steht.

Behalten die Variablen nun ihren Wert? --> Wenn ja dann hätte I_False=0 und I_True=1 sein sollen und das Fehlerbit wäre somit nicht gesetzt worden.

Werden die Werte neu Initialisiert? --> Wenn ja dann hätte I_False=0 und I_True=1 sein sollen und das Fehlerbit wäre somit nicht gesetzt worden.

Die Variablen sind ja VAR_INPUT und werden von außen nicht beschrieben so deute ich den Aufruf im Code. Das würde dann aber bedeuten das es wahrscheinlich zu einer Verschiebung der Daten während der Programm Abarbeitung kam. Egal ob der FB vor dem DB oder der DB vor dem FB aktiviert wurde. Ich würde mal behaupten das eine solche Verschiebung in einer Anlage, mit einer hohen Wahrscheinlihkeit, zu unerwünschten Nebeneffekten führen würde.

 

[Perfektionist]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es ist wohl so, dass Vipa in der Lage ist, mehr als einen Baustein in den Hintergrund zu laden und dann mehrere Bausteine am Zykluskontrollpunkt gleichzeitig aktiv zu schalten. Möglicher Weise ist das auch bei den 400ern so (entzieht sich meiner Kenntnis - bei der 318 ist mir derartiges Verhalten nie aufgefallen).

Aber alles das nutzt nichts - das Einzige, das ich mit der richtigen Übertragungsreihenfolge erreichen kann, ist, dass ich einen Bereichslängenfehler vermeide. Damit vermeide ich einen Stopp der CPU. Einen Stopp meines Prozesses kann ich nur vermeiden, wenn ich vermeide, eine Instanz zu verändern oder prozessablaufrelevante Variablen darin abzulegen. Zudem darf ich niemals Daten einfügen, nur anhängen, was mir schonmal verbietet, die Schnittstelle des Bausteins zu verändern (warum nur, um Gottes Willen, hat man die IN/OUT nicht auf den Temp-Stack gelegt?).

Stellt sich jetzt aber die Frage (passend zum Topic): wie sieht das Ganze nun bei der 1200er aus? Gibt es da diese Problematik überhaupt? Oder funktioniert das Ding immer noch so wie 200er, die ausschliesslich von Globaldaten lebt und daher derartige Probleme überhaupt nicht kennen kann?

 

[Perfektionist]

... Das würde dann aber bedeuten das es wahrscheinlich zu einer Verschiebung der Daten während der Programm Abarbeitung kam. Egal ob der FB vor dem DB oder der DB vor dem FB aktiviert wurde. Ich würde mal behaupten das eine solche Verschiebung in einer Anlage, mit einer hohen Wahrscheinlihkeit, zu unerwünschten Nebeneffekten führen würde.

genau so ist es! Daher bei Instanz-DB-Änderungen immer: 1.: Prozess anhalten. 2.: CPU auf Stopp. 3.: DB, FB und Baustein mit Aufrufstelle übertragen. usw...

Und bei mir kommt neuerdings als Schritt 2a noch hinzu: Parameter und wichtige Prozessdaten des DB in Rezept auf HMI sichern. Und ausserdem als Schritt 3a: HMI aktualisieren und Rezept rückübertragen.

 

[Thomas_v2.1]

lässt sich mitsamt dem dazugehörigen DB nicht auf eine 319 so übertragen, dass nicht anschliessend der Fehler-Merker gesetzt ist. Und das liegt eben daran:

Hast du vielleicht nur den FB "testchange" und den Instanz-DB zusammen übertragen, aber nicht den aufrufenden FB?
Dann werden im aufrufenden FB die Parameter nämlich noch auf Adressen DBX0.0/DBX0.1 geschrieben, was dann falsch wäre.

Sonst könnte es noch sein dass der FB "testchange" mit seinem Instanz DB vor dem Aufruf-FB eingebunden wurde. Was ich aber für unwahrscheinlich halte, da ich sowas schon etliche Male ohne Probleme gemacht habe.

 

[Perfektionist]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du vielleicht nur den FB "testchange" und den Instanz-DB zusammen übertragen, aber nicht den aufrufenden FB? Dann werden im aufrufenden FB die Parameter nämlich noch auf Adressen DBX0.0/DBX0.1 geschrieben, was dann falsch wäre.

Der Versuch, im aufrufenden Baustein auch noch die Zuweisung zu den Inputs zu programmieren, war nicht nötig, weil:

Sonst könnte es noch sein dass der FB "testchange" mit seinem Instanz DB vor dem Aufruf-FB eingebunden wurde. Was ich aber für unwahrscheinlich halte, da ich sowas schon etliche Male ohne Probleme gemacht habe.

Egal in welcher Reihenfolge, allein schon die Bausteine testchange und dessen Instanz wurden nicht am gleichen Zykluskontrollpunkt eingebunden.

im Übrigen lässt

... da ich sowas schon etliche Male ohne Probleme gemacht habe.

darauf schliessen, dass wir zwei hübschen wohl einen grundverschiedenen Programmierstil pflegen (ich habe das nicht nur etliche Male so gemacht - bei mir ist es das normale Vorgehen, da ich fast ausschliesslich FB code und darin normalerweise deutlich mehr Lokalvariablen, als Globalvariablen vorzufinden sind).

Allerdings bin ich mir im Moment nicht sicher, ob das Laden der Bausteine mit CTRL-L (Zielsystem-->Laden) der einzige Weg ist, den Laufzeitcode ins AG zu bringen. Aber was schlussendlich auf jeden Fall bleibt (und da hilft auch nicht das Umschalten von drei Bausteinen an einem Zykluskontrollpunkt) ist, dass die Daten des vorangegangenen Zyklus im DB danach futsch sind.

So, könnten wir nun wieder auf das Verhalten von 1200ern beim Online-Change zu sprechen kommen?

 

[Schnellschuss]

S7-1200 online ändern

Hallo,

das man das Programm bei der S7-1200 nicht online ändern kann ist nicht schön. Das war früher bei der S7 200 auch so und man konnte trotzdem programmieren. Eine absolute Katastrophe ist, dass auch die Datenbausteine überschrieben werden. Bei einer Anlage die man nur testen kann, wenn bestimmte Daten in den Bausteinen liegen kommt man nicht voran.
Das Überschreiben der Datenbausteine konnte man bei der S7-200 aber schon immer ausnehmen.
Was mich bei der ganzen Sache ärgert, ist das man von Siemens hört, dass die S7-1200 eine Innovation ist, aber nicht vor diesen Missständen gewarnt wird.



Schnellschuss

 

[stefenli]

Online Änderung

Hallo

Eine Änderung im Programm während des online
Betrieb ist ab der V11 Sp2 möglich. Es gibt allerdings Beschränkungen
Bezüglich des Änderungsumfangs. Sprich und in oder und auch kleinere netzwerkänderungen
Sind kein Problem.

Nähere Infos in der v11 Doku