# S7 1200



## ekersten (29 Mai 2009)

Bei der Vorstellung der neuen S7-1200 wurde mitgeteilt das die CPU bei jedem Übertragen von Programm oder Daten in den STOP Zustand geht. Ein solches Verhalten schliesst die Steuerung für die einfachsten Anwendungen (z.B. eine Ampelsteuerung ) schon aus.
Da sollte Siemens unbedingt nachbessern.


----------



## MSB (29 Mai 2009)

Da die S7-1200 Nachfolger der 200 ist,
hat man an dem Verhalten nichts geändert.

Abgesehen davon ist das für diese Steuerungsklasse in der die 1200 operiert durchaus als marktüblich zu bezeichnen.

Mfg
Manuel


----------



## Move (29 Mai 2009)

ekersten schrieb:


> Bei der Vorstellung der neuen S7-1200 wurde mitgeteilt das die CPU bei jedem Übertragen von Programm oder Daten in den STOP Zustand geht. Ein solches Verhalten schliesst die Steuerung für die einfachsten Anwendungen (z.B. eine Ampelsteuerung ) schon aus.
> Da sollte Siemens unbedingt nachbessern.


 
Hi,
echt? Habe mir die S7-1200 auf der H-Messe vorführen/zeigen lassen. Davon war aber nicht die Rede . Wenn das so ist, dann reicht sie höchstens für die Toilettensteuerung zu Hause .
Wie will man das einem Kunden erklären, das jedesmal seine Anlage abschmiert, wenn man eine Änderung einspielen muss. Das wäre ja ein richtiger Rückschritt zu bisherigen. 
Gruß


----------



## MSB (29 Mai 2009)

@Move
Sorry, aber wenn dich das überrascht, dann kennst(kanntest) du die 200er auch schon nicht.
Erwähnenswert wäre das ganze nur wenns NICHT mehr so wäre.
Also hier nicht Äpfel mit Birnen sprich 200/1200 mit 300/400 vergleichen.

Abgesehen davon ist der Stop bei Maschinen im Normalfall kein Problem, bei Anlagen mit
längeren Prozessen etc. natürlich schon eher ...

Und wie gesagt, haben die meisten mir bekannten Kompaktsteuerungen mit dem Problem (was bei entsprechenden Maschinen keins ist) zu kämpfen ...

Mfg
Manuel


----------



## offliner (29 Mai 2009)

Es gibt etliche Steuerungen, die mit Compiler arbeiten, bei der die Steuerung in Stop geschaltet werden muss. Stellt sich die Frage, was besser ist, geziehlt in Stop oder komplette Katastrophe, weil die in Run eingespielte Anderung einen Fehler hat und die Anlage völlig undefiniert runterfährt... Davon abgesehen wurde bei der Vorstellung der 1200er auch erwähnt, dass hier noch nachgebessert wird und ein teilweiser Download in Run möglich sein werden soll. Wo die Einschränkungen da liegen werden, kann ich nicht sagen... Ansonsten hat mir die 1200er bei der Präsentation ganz gut gefallen, vor allem einige Funktionen in der Engineeringsoftware gefallen mir sehr gut.


----------



## Paule (29 Mai 2009)

War auch auf einer 7n5 über S7-1200

erst Version war Übertragung ohne stopp schalten.
Ein Baustein kopieren 10 min > Untragbar :shock::shock::shock:
Also Versionsänderung > Übertragung wieder nur im Stoppzustand
Wird aber noch dran gearbeitet.
Frühste mögliche Version inklusive SCL-Programmierung 2010
AWL gibt's gar nicht mehr! :sb6: :sm18: :sw8:


----------



## Thomas_v2.1 (29 Mai 2009)

Paule schrieb:


> Wird aber noch dran gearbeitet.
> Frühste mögliche Version inklusive SCL-Programmierung 2010



Bei Codesys hat das auch lange gedauert bis Teilladen möglich war. Scheint wohlt nicht so einfach zu sein ;-)

Ich kann mir aber vorstellen dass das bei der kleinen Steuerung mit Absicht so gemacht wird. So kommt man nicht auf die Idee für wichtige Anlagen die günstige Steuerung zu verwenden.


----------



## Paule (29 Mai 2009)

offliner schrieb:


> Es gibt etliche Steuerungen, die mit Compiler arbeiten, bei der die Steuerung in Stop geschaltet werden muss. Stellt sich die Frage, was besser ist, geziehlt in Stop oder komplette Katastrophe, weil die in Run eingespielte Anderung einen Fehler hat und die Anlage völlig undefiniert runterfährt... Davon abgesehen wurde bei der Vorstellung der 1200er auch erwähnt, dass hier noch nachgebessert wird und ein teilweiser Download in Run möglich sein werden soll. Wo die Einschränkungen da liegen werden, kann ich nicht sagen... Ansonsten hat mir die 1200er bei der Präsentation ganz gut gefallen, vor allem einige Funktionen in der Engineeringsoftware gefallen mir sehr gut.


 
Es gitbt doch wohl ein Unterschied ob ich die komplette Anlage in den Stopp schalte nur weil ich z.B. eine Zeit ändern will, oder wenn ich ganze Structuren ändere. 
Wenn ich bei jeder Änderung sagen muss:
Ne Leute das geht nur am Wochenende, sonst muss ich die Anlage abschalten.
Na dann prost Mahlzeit > Lass dich scheiden.


----------



## thomas_1975 (30 Mai 2009)

Hallo,
nur ein kleiner Nachtrag man kann bei der 200er, ich glaube unter Extras,
das Programm im Run bearbeiten.
gruß Thomas


----------



## zotos (30 Mai 2009)

Zum Thema Online Change (wie auch immer man es nennen möchte). Bei CoDeSys hat diese Funktion auch reifen müssen. Heute funktioniert dies gut, schnell und komfortabel. 

Das ST/SCL schon 2010 kommen wird erweckt bei mir die befürchtung, dass dies kompromisse mit sich bringt wird die der Qualität nicht zuträglich sind. 

Zu AWL wenn ST/SCL ordentlich implementiert wurde kann man auf AWL getrost verzichten.

Aber wie sieht es denn mit einer Simulation aus? War ja nicht gerade die Stärke von der S7-200 wird dieses Manko behoben? 

Ist eine Ablaufsprache AS oder S7-Graph geplant?


----------



## TobiasA (30 Mai 2009)

Das ist aber -leider- nicht unüblich, dass die SPS in Stop geht, wenn man ein Programm überträgt.

Bei Fanuc (CNC-Steuerungen, bei der SPS weiß ich es nicht genau) muss man bei der kleinsten Änderung die ganze Kiste seriell rüberschubsen oder mit einer Memory-Karte hin und her flitzen. Alternativ kann man sich auch an der Steuerung einen abklimpern. 
Bei den Heidenhain CNC's muss man die PLC ebenfalls neu kompilieren.

Es gibt noch viel größere Brüller- bei Fanuc zum Beispiel gibt es ein Level1 und ein Level2. Level 1 wird in jedem Zyklus abgearbeitet + ein Teil von Level 2, der hat noch in den Rest der Zykluszeit passt. Wisst ihr, wie witzig das werden kann, wenn ein Eingang oben im Ladder 1 ist und weiter unten auf einmal wieder 0 (wohlgemerkt, in EINEM Level2 Durchlauf!)? Bei Stop behalten auch die Ausgänge alle Zustände bei, d.h. Bewegungen, die noch aktiv sind, bleiben an, auch wenn der Endschalter lange erreicht ist oder der Schmierdruck schon lange da ist... Kann mitunter unangenehm werden.
Das ist also alles relativ.

Es ist halt die kleine Steuerung. Mir persönlich reicht es, wenn die 200'er sich endlich mal gescheit in den Rest von "Totally Integrated Automation" integrieren lässt und mit den gleichen Tools bzw. Programmiersprachen wie die 300'er programmieren lässt. Das ist dann schon mal ein Fortschritt 

Gruß, Tobias


----------



## Ralle (30 Mai 2009)

Aber ehrlich, wenn ich eine kleine SPS brauche, nehme ich eine kleine von VIPA, die ist dann immer noch in Step7 programmierbar und verhält sich wie eine "große" inkl. kein Stop bei Änderungen!


----------



## Perfektionist (30 Mai 2009)

das Thema "Online-Change" hatten wir bei er 200er schon mal - leider hab ich mit der Such-Funktion den 200er-Terminus dazu noch nicht wiedergefunden. Es ist keine Erfindung der 1200er ...

Leider ist die Sache auch bei der 3/400 nur eingeschränkt nutzbar. Sowie ich einen DB neu generieren muss (weil ich halt in der Instanz noch eine weitere Variable brauche), ist das mit dem nahtlosen Weiterbetrieb mit der Anlage halt auch so eine Sache ...

Mich würde nicht wundern, wenn CoDeSys da inzwischen die Nase vorne hat. Weil: es ist denkbar, dass halt wirklich nur die weitere Variable hinzukommt, aber eben die bestehenden ihre Werte beibehalten :?


----------



## Thomas_v2.1 (30 Mai 2009)

Perfektionist schrieb:


> Mich würde nicht wundern, wenn CoDeSys da inzwischen die Nase vorne hat. Weil: es ist denkbar, dass halt wirklich nur die weitere Variable hinzukommt, aber eben die bestehenden ihre Werte beibehalten :?



Bei einer S7 geht das auch. Aber dann nur über Quellen, die Vorgehensweise habe ich hier im Forum mal beschrieben.
Nur mal zur zeitlichen Abfolge:
Codesys 1.0 - erschienen 1994
Step7 - erschienen 1995

Bei Codesys stand ein Online-Change von Anfang an nicht im Pflichtenheft. Mich würden die Gründe dafür mal interessieren, kann mir aber vorstellen dass die Entwickler die Praxis der SPS-Programmierung nicht kannten.
Es gibt Anlagen da ist dieses mehr oder weniger ein Kill-Argument. Eine S5 konnte das zudem auch schon, wenn auch bei speziellen Steuerungen das Eprom neu gebrannt werden musste, aber das ist nicht meine Zeit ;-)


----------



## Perfektionist (31 Mai 2009)

gut - bei S5 gab es das Konzept des Instanz-DB nur, wenn man entsprechend programmierte. Von der Programmiersprache her waren damals DBs nicht als remanente Lokaldaten, sondern als eine Erweiterung der Globaldaten (Merkerbereich) vorgesehen worden. Und die Temp-Variablen hat man als "Schmiermerker" ab M200.0 abgelegt *ROFL*

und wegen:





> Bei einer S7 geht das auch. Aber dann nur über Quellen, ...


das ist schön und gut, wenn in der Instanz nicht ständig veränderliche Werte stehen. Aber wenn da gerade eine Schrittkette am Ablaufen ist - da darf ich die Zustandsmaschine nicht mit irgendwelchen Werten auf einen "Zufalls"zustand bügeln, da ist es notwendig, in der Manier eines DP-Param, nur die Änderungen/Erweiterungen zu übertragen, aber die Zustände der vorhandenen Variablen unangetastet zu lassen.


----------



## zotos (31 Mai 2009)

Vorneweg: Ich denke nicht das ich jetzt vom Thema abkomme. Der Ursprungsbeitrag dreht sich ja um die Übertragung von Programmänderungen ohne CPU Stopp (Online-Change).



Perfektionist schrieb:


> ...
> Mich würde nicht wundern, wenn CoDeSys da inzwischen die Nase vorne hat. Weil: es ist denkbar, dass halt wirklich nur die weitere Variable hinzukommt, aber eben die bestehenden ihre Werte beibehalten :?



Ich habe gerade extra einen Versuch mit einer WAGO 750-841 (CoDeSys) gemacht:

Zwei benutzerdefinierte Dateitypen (UDTs) wobei die eine in die andere eingebaut ist. 
Dieser übergeordnete Dateityp findet Anwendung in einem Eltern und einem Kind FB. Der Eltern FB beinhaltet wie gesagt den Dateityp und zwei Kind FBs (also Multiinstanz aufbau).

Nun habe ich das ganze in die Steuerung eingespielt und gestartet. 
Anschließend habe ich nach einander an den Dateitypen erweiterungen vorgenommen und wia online Change eingespielt. Resulatat alle Daten behielten ihre Werte, die neu dazugekommenen Standen auf dem Initialisierungswert.
Nun habe ich die Dateitypen einzelner Variablen geändert (von INT auf STRING) und wieder per Online Chance eingespielt -> Resultat war das gleiche alle im Programm unveränderten Variablen haben ihre Werte behalten, die mit dem neuen Variablentyp standen auf ihrem Initialisierungswert.
Letzter Versuch den Variablennamen geändert -> Resultat alle im Programm unveränderten Variablen haben ihre Werte behalten, die mit dem neuen Namen standen auf ihrem Initialisierungswert.

Dauer der Übertragung wenige Sekunden.


----------



## Werner29 (2 Juni 2009)

Thomas_v2.1 schrieb:


> Bei Codesys stand ein Online-Change von Anfang an nicht im Pflichtenheft. Mich würden die Gründe dafür mal interessieren, kann mir aber vorstellen dass die Entwickler die Praxis der SPS-Programmierung nicht kannten.


Codesys hat immer schon ein Online Change Konzept, auch wenn es nie ein Pflichtenheft gab in dem das gestanden wäre. Und die Praxis der SPS-Programmierung ist uns (...leider...) sehr wohl bekannt.
Zugegebenermassen war die Funktionalität lange Zeit einfach nicht gut genug um wirklich eingesetzt werden zu können.
Das ist aber schon seit etlichen Jahren nicht mehr der Fall. Wer mit einer Version > 2.3 arbeitet kann sehr wohl auf Online Change vertrauen.
Damit ist nicht gesagt, dass es keine Probleme mehr gibt, aber ich würde mal behaupten dass die Wahrscheinlichkeit, dass das Problem bei CoDeSys liegt mittlerweile kleiner ist, als dass das Problem in der Applikation liegt.
Mit Online Change bringt man sein System in Zustände, in die es im regulären Lauf nie käme. Das ist aber ein allgemeines Problem.
Man kann es sich leicht machen und nur Codeänderungen zulassen, dann kann schon fast nichts mehr schlimmes passieren. Aber wenn ich auch Datenänderungen zulasse, also beispielsweise einen neuen Input für meinen Funktionsblock, dann gehen die Probleme los.
Und das gilt für jedes System.


----------



## Perfektionist (3 Juni 2009)

Werner29 schrieb:


> ... Aber wenn ich auch Datenänderungen zulasse, also beispielsweise einen neuen Input für meinen Funktionsblock, dann gehen die Probleme los.
> ...


wobei das ja dann schon ganz hohe Schule ist. Da muss ja dann auch der Code für den Aufruf des Funktionsblocks mitgeändert werden. Bei S7-300 unmöglich. Ich habe Stimmen gehört, die behaupten, S7-400 könne mehrere Bausteine im Hintergrund laden und dann gleichzeitig Aufruf, FB und DB umschalten. Aber bei diesem Vorgehen bleibt dennoch der Aktualdatenverlust im DB.

Aus diesen Gründen muss ich mich doch mal intensiv mit CoDeSys auseinandersetzen. Nun erachte ich ja Online-Change bei der 200er-Klasse als nicht sonderlich wichtig (was wohl auch daran liegt, dass ich damit nur selten arbeite und wenn, dann handelt es sich um die Funktionalität eines kleinen FB, wofür eine Logo auch schon fast ausreichend wäre), jedoch hat, wie ich sehe, die 300er Aufholbedarf. Ich hoffe mal, Siemens bringt mit dem neuen Automation-Portal nicht nur neue bunte Oberflächen, sondern in diesem Kernpunkt auch neue Funktionalität.


----------



## Ralle (3 Juni 2009)

Perfektionist schrieb:


> Bei S7-300 unmöglich.



Bist du da sicher? Das geht eigentlich, wobei man dann alle betroffenen FC/FB/DB gleichzeitig übertragen muß. Die werden dann übertragen und erst danach gleichzeitig aktiviert. Das setzt voraus, daß der Speicher groß genug ist, die Bausteine in einem Rutsch aufzuehmen. Das Problem mit den verlorenen Aktualdaten bleibt natürlich! Aber immerhin kann man die Anlage, wenn nötig, einfach anhalten (kein SPS-STOP), den Code einspielen, die betreffenden Stationen u.U. resetten und weiterfahren. Klar, bei kontinuierlich laufenden Prozessen ist auch das ein Problem. Aber deshalb überlege ich mir genau, ob es unbedingt ein FB sein muß, ich nutze meißt FC und als INOUT angelegte Globaldaten zum "Puffern". Die VIPA kann wohl nur eine begrenzte Anzahl an Bausteinen (4?) gleichzeitig aktivieren.


----------



## IBFS (3 Juni 2009)

Ralle schrieb:


> Das geht eigentlich, wobei man dann alle betroffenen FC/FB/DB gleichzeitig übertragen muß. Die werden dann übertragen und erst danach gleichzeitig aktiviert. Das setzt voraus, daß der Speicher groß genug ist, die Bausteine in einem Rutsch aufzuehmen. Das Problem mit den verlorenen Aktualdaten bleibt natürlich!


 
EXAKT so ist das! 
Sind die betreffenden die Bausteine alle eingespielt, werden am Kontrollpunkt
alle alten Bausteine abgemeldet und die neuen in der SPS freigeschaltet.

Ich dachte eigentlich, dass das allgemein bekannt ist 

Im übrigen arbeiten wir bei uns zu zweit oder dritt an einer CPU und
machen das permannent auch parallel. 
Ob das auch mit CoDeSys geht? - paralleles Arbeiten von verschiedenen
Rechnern mit gleichen oder verschiedenen Programmteilen 
an der gleichen CPU?


Gruß

Frank


----------



## Werner29 (3 Juni 2009)

IBFS schrieb:


> 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 (3 Juni 2009)

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


----------



## Werner29 (3 Juni 2009)

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 (3 Juni 2009)

IBFS schrieb:


> ...
> 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 (3 Juni 2009)

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 (4 Juni 2009)

IBFS schrieb:


> ...
> 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 (5 Juni 2009)

Perfektionist schrieb:


> ... (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 (5 Juni 2009)

Perfektionist schrieb:


> 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 (5 Juni 2009)

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 (5 Juni 2009)

BoxHead schrieb:


> 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 (5 Juni 2009)

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 (5 Juni 2009)

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 (5 Juni 2009)

BoxHead schrieb:


> ... 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 (5 Juni 2009)

Perfektionist schrieb:


> 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 (5 Juni 2009)

Thomas_v2.1 schrieb:


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


Thomas_v2.1 schrieb:


> 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 (27 März 2010)

*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 (2 März 2013)

*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


----------

