TIA Migration von Funktionsbausteinen (STEP 7 V5.5 >> STEP 7 V13 Professional)

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also warum der Aufwand?

Um nun endlich die S7-Programmierer zu sauberem Programmierstil zu erziehen (das lesen der OUT war auch vorher schon pfui) und um den Programm-Quelltext unabhängig vom Einsatz in FB oder FC zu machen - in FC ist das Lesen der OUT sogar richtig falsch, wie wir hier kürzlich über einen Optimierungs-Bug des SCL-Compilers lesen konnten.

Harald

 

[RONIN]

muss ich meine Bausteine umprogrammieren

Technisch gesehen...

Nein.
Solange nicht jemand, von der Extern (Visu) oder aus einem Interrupt heraus, den OUT-Bereich der FB-Instanz liest, bist du eigentlich immer konsistent.
Aber die Varianten sind beide unglaublich pfui.​

Stil-technisch gesehen...

JA.​

Wo du allerdings schon ein Problem hast ist beim IN/OUT.
Bei der 1200/1500 liest die Visu nicht mehr zwischen Zyklusende und Zyklusanfang, sondern irgendwo mittendrin.
Kann auf sein das die Visu mitten in der Abarbeitung des Bausteins liest und schreibt.

Das solltest du unbedingt bei der Konzeption betrachten.
http://www.sps-forum.de/simatic/79662-umstieg-auf-s7-1500-a-post601632.html#post601632

 

[Kai Schulz]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo RONIN.

Bei der 1200/1500 liest die Visu nicht mehr zwischen Zyklusende und Zyklusanfang, sondern irgendwo mittendrin.
Kann auf sein das die Visu mitten in der Abarbeitung des Bausteins liest und schreibt.

Danke für diese wichtige Information! :icon_idea: :idea: :idea:

Man sollte eventuell die gesamte HMI-Kommunikation zwischenspeichern und besser mit dem Zwischengespeicherten arbeiten, dass man dann, am Anfang des OB1-Zyklus einliest und erst am Ende schreibt. >> Das sollte vor "Gulasch" schützen!

Gruß Kai

 

[RONIN]

Man sollte eventuell die gesamte HMI-Kommunikation zwischenspeichern und besser mit dem Zwischengespeicherten arbeiten, dass man dann, am Anfang des OB1-Zyklus einliest und erst am Ende schreibt.

>> Das sollte vor "Gulasch" schützen!

Wen's interessiert. Das Verhalten kann man schnell nachstellen.

• PLCSIM mit der 1500er
• im OB1 in NW1 einen Datenpunkt auf 1 setzen
• in NW2 2 Wait-Bausteine mit 2x32000 (64ms) einfügen
• in NW3 den Datenpunkt wieder auf 0 setzen
• in NW4 wieder 2 Waitbausteine mit 64ms.

Danach ne Visu projektieren mit ner Animation auf diesen Datenpunkt. In ner 300er sieht man nix. Mit der 1500er blinkt die Animation schön dahin.

Auch wenn es bei der 400er auch schon so war, finde ich die Vorgehensweise nicht wirklich gut. Man muss da so sehr aufpassen das man nicht in einem
von einer Million Fälle einen Fehler produziert. Ja, ich bin auch schon gespannt wie viele Probleme mit sowas (vor allem von Neulingen) hier im Forum auflaufen werden.
Wozu machen wir dann eigentlich noch ein Prozessabbild der Ein/Ausgänge? Soll die CPU doch auf gleich mitten im Zyklus die E/As schreiben.

Der einzige weg drum herum im Moment wäre sein Hauptprogramm mittels Interrupt und SRT_DINT mit einer Prioritätsstufe > 15 aufzurufen.
Die Stufe wird nicht durch HMI-Kommunikation unterbrochen. Ist aber auch nur ne Notlösung wenn man z.b. ein 300er Programm konvertiert das mit dem neuen HMI-Zugriff nicht klar kommt.

Eigentlich sollte nicht viel migrieren sondern eher seine Bausteine neu schreiben. Leider

 

[Onkel Dagobert]

.. Mit der 1500er blinkt die Animation schön dahin...

Für lesende Zugriffe ist das ja auch ganz ok, finde ich. Hat jemand eine Idee, wie man so etwas für Schreibzugriffe testen kann?

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

      U     "Boolmerker"      
SPBN  up
      L     "zählvar"
      L     1
      +I
      T     "zählvar"
up:   NOP 0


      CALL  WAIT
         WT :=32767


      CALL  WAIT
         WT :=32767


      U     "Boolmerker"
      SPBN  up1
      L     "zählvar_2"
      L     1
      +I
      T     "zählvar_2"
      R     "Boolmerker"
up1:  NOP 0

in der 300er würden die zählvars gleichmässig hochzählen.
bei der 1500er gibts dann verschiebungen wenn man innerhalb des Zyklus reinschreibt (boolmerker setzen).


Allerdings Hab ich mir das schon länger angewohnt so zu programmieren als kämen und gingen die Daten irgendwo im Zyklus (weil oft 400er habe). Will heissen Austauschbereiche.

 

[RONIN]

@Onkle, HMI-Kommunikation bedeutet natürlich auch Schreibzugriff.

Allerdings Hab ich mir das schon länger angewohnt so zu programmieren als kämen und gingen die Daten irgendwo im Zyklus (weil oft 400er habe). Will heissen Austauschbereiche.

Ja leider, wir haben ausschließlich 300er und daher hab ich meine Probleme damit.

Die Austausch-Bereiche sind mehr Arbeit und mehr Speicher, daher hab ich bis jetzt nicht so programmiert.
Die ganzen Fbs übernehmen eine Datenstruktur via SFC20 in dem Temp, bearbeiten die, und kopieren Sie am Ende wieder raus.
Auf der 300 ist das wesentlich schneller und weniger Speicherintensiv als INOUT.

Das geht jetzt natürlich nicht mehr und somit hab m(k)eine Freude damit.... :neutral:
Also, alles neu.

 

[vollmi]

Die Austausch-Bereiche sind mehr Arbeit und mehr Speicher, daher hab ich bis jetzt nicht so programmiert.
Die ganzen Fbs übernehmen eine Datenstruktur via SFC20 in dem Temp, bearbeiten die, und kopieren Sie am Ende wieder raus.
Auf der 300 ist das wesentlich schneller und weniger Speicherintensiv als INOUT.

Das braucht überhaupt nicht mehr Speicher, auch wenn ich eher selten in Engpässe kommen würde schau ich schon auch auf den Speicher. Man muss nur davon weg den OB als Manager zu verwenden. Für mich ist der OB nur der Taskoperator. Der ruft meine Hauptfunktion auf (z.B. FC_Anlagensteuerung) Die Daten für Visu, Peripherie werden per SFC20 in diesem Baustein in den Tempbereich kopiert und am Ende des FC wieder zurückgeholt. Nur INOUT und Temp.
Wenn man die Austauschbereiche möglichst strukturiert (UDTs etc) aufbaut, muss man ihn auch wenig von Hand Pflegen, sondern passt die UDTs an und schon sind sowohl HMI DB wie auch Temp Bereich wieder gleich.

Was mich viel eher stört dass das mit den unterschiedlichen UDT für HMI und SPS immer schlimmer wird. Jetzt werden die UDT im HMI sogar noch zwischen 1500er und 300/400 unterschiedlich aufbereitet.
Ich brauch also für meine Datenhaltung ein Exportmacro für die UDT im SPS Programm, ein weiteres Macro für die HMI und dieses dann noch umschaltbar Classic und 1500er. Da kriegt ich Krämpfe (aber erst so richtig wenn HMI import für UDTs funktioniert).

mfG René

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das braucht überhaupt nicht mehr Speicher,

Beim Aufrufer-FB macht das keinen Unterschied, bei dem aufgerufenen FB selber ist es schon ein gewaltiger Unterschied ob du einen UDT oder INOUT oder ANY/SFC20 übergibst.
Habs jetzt nur an nem alten Mini-FB der eine kleine 30Byte Struktur übernimmt probiert.
UDT mit INOUT übergben - 2844Byte
UDT mit ANY/SFC20 übergeben - 1124Byte (Sonst nix geändert)
Ist ja auch klar, auf die INOUT wird ja ständig mittels Pointer rangiert.

Bei ein paar 100 Instanzen und auf ner ET200S-CPU macht sich dass dann schon schnell bemerkbar.
Einerseits bringst du fast nix mehr drauf weil die Bausteine soviel Speicher brauchen, andererseits geht die Zykluszeit auch nach oben.

Man muss nur davon weg den OB als Manager zu verwenden. Für mich ist der OB nur der Taskoperator.

Hab ich nicht ganz verstanden.

Die Daten für Visu, Peripherie werden per SFC20 in diesem Baustein in den Tempbereich kopiert und am Ende des FC wieder zurückgeholt.

Hast du da nicht das selbe Problem. Wenn die die Visu in dem Moment in den Visudatenbereich schreibt während die Kopie gerade im Temp ist.?

 

[Kai Schulz]

Hab ich nicht ganz verstanden.

Er ruft im OB1 nur einen FC auf, den er quasi als "Ersatz"-OB1 benutzt. Die HMI Daten kopiert er, vor der FC-Bearbeitung, mit "Blockmove" in den FC-Tempbereich und am Ende wieder zurück, er erzeugt quasi ein künstliches Prozessabbild der HMI-E/A-Daten.

Gruß Kai

 

[Verpolt]

RONIN

Hast du da nicht das selbe Problem. Wenn die die Visu in dem Moment in den Visudatenbereich schreibt während die Kopie gerade im Temp ist.?

1. FC in der ersten Zeile --> Kopie HMI-Daten in TEMP
2. HMI schreibt jetzt auf HMI-Daten
3. Temp hat immernoch die "vorher kopierten" HMI Daten
4. Logik
5. Kopie aus Temp raus

Ohne Temp

1. Logik mit HMI-Daten.Bitx =1
2. HMI schreibt jetzt auf HMI-Daten (.Bitx.=0)
3. Logik mit HMI-Daten.Bitx =0

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Kai: Den Rest hatte ich kapiert. Mir gings nur um die Sache mit dem OB ruft n r einen FC auf.

@Krumnix. Ja, eben.
Wenn ein Steuerbefehl von der Visu kommt gilt er nur wenn er innerhalb des Zeit zwischen Zyklusende und Zyklensanfang kommt. Kommt er zwischendrinn wird er beim rückkopieren aus dem Temp sogar gelöscht.

Das funktioniert eben nur wenn man sehr genau zwischen Anzeigedaten unf Steuerdaten trennt.

AnzeigeDaten dürfen am Ende aus dem Temp rückkopiert werden, Steuerdaten nicht.

Die Trennung führt aber zu mehr Arbeit und einiger Redundanz. Wenn man sich die Mühe sparen kann, hat man am meisten gewonnen.

 

[vollmi]

Das funktioniert eben nur wenn man sehr genau zwischen Anzeigedaten unf Steuerdaten trennt.

AnzeigeDaten dürfen am Ende aus dem Temp rückkopiert werden, Steuerdaten nicht.

Die Trennung führt aber zu mehr Arbeit und einiger Redundanz. Wenn man sich die Mühe sparen kann, hat man am meisten gewonnen.

Mir hat bis ich alles plausibel hatte vor allem das rücksichern von Steuerdaten rechtes kopfzerbrechen bereitet. Und bei der 300er die Grösse des Lokaldatenstacks.

mfG René

 

[RONIN]

Mir hat bis ich alles plausibel hatte vor allem das rücksichern von Steuerdaten rechtes kopfzerbrechen bereitet.

Ja, ist nicht ganz banal. Wenn man nicht von vorn herein sein System auf diese Verhalten auslegt, is Essig...
... oder wenn man mal schnell irgendwo ohne groß nachdenken einen Datenpunkt erweitert... oder Datenpunkt mehrmals liest liest und der Code verträgt's nicht...

Bei mir musste (muss ich noch) einiges umkrempeln.

Im dem Sinne ist mir grad noch was aufgefallen. (Zumindest wenn der Simulator stimmt)
Bei der 1200 und der 1500 ist die Sache wieder unterschiedlich. Bei der 1200 scheint die CPU wie bei der 300 zu kommunizieren.

Die bei Siemens werden sich einfach nicht einig... :-x
Ist aber nur am Simulator getestet und muss in freier Wildbahn noch getestet werden....