TIA Warnungen nach Migration

Draco Malfoy

Draco Malfoy

Level-1
Beiträge
1.168
Reaktionspunkte
82
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen.

Habe mal ein Paar FBs von STEP 7 v5.5 nach TIA migriert. Habe in einem FB haufenweise Warnungen von der Sorte "Zugriff auf %LB8" mit nicht eindeutiger Adresse" oder "Änderungen von AR2 können lokale Variablenzugriffe in Funktionsbausteinen des Projekts zerstören". Der FB ist allerdings im Rahmen seiner bisherigen Verwendung unter STEP 7 v5.5 super gelaufen und da gab es keinerlei Probleme.

Soll ich mir jetzt angesichts dieser Warnungen jetzt Sorgen machen oder meckert hier das TIA Portal wegen Nichtigkeiten ? AR2 wird übrigens immer nur gelesen, aber nirgendswo geschrieben.
 
Es sind berechtigte, wenn man weiß was man tut sinnlose Warnungen ... nicht mehr aber auch nicht weniger.
Willkommen in der oftmals sinnbefreiten Welt von TIA ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also jetzt nochmal für mich: muss ich in diesem konkreten Fall was machen oder nicht ? Wie gesagt, in den 300er Steuerungen ist bisher alles prima gelaufen und wurden auch keine Warnungen generiert. Jetzt live in der 1500 zu testen habe ich leider keine Möglichkeit.
 
In Bezug auf 1500: keine Ahnung wie da das Speicherkonzept in Bezug auf Adressregister ausschaut.
Das kommt jetzt also schwer darauf an, wofür und wie das AR2 verwendet wird, generell unterscheidet sich S7-300 und 1500 hier im Detail schon.
http://support.automation.siemens.com/WW/view/de/67655405

Wenn du aber sowieso eine 1500er verwenden willst, wäre es vielleicht ohnehin das bessere den Baustein auf die Möglichkeiten der S7-1500 hin anzupassen.

Mfg
Manuel
 
MSB schrieb:
Wenn du aber sowieso eine 1500er verwenden willst, wäre es vielleicht ohnehin das bessere den Baustein auf die Möglichkeiten der S7-1500 hin anzupassen.
Zum Vergrößern anklicken....

Danke für den Hinweis. Scheint also doch nicht ganz trivial zu sein. Für mich ist halt immer noch schwierig zu verstehen, was ich denn jetzt genau machen muss ?
Ich gebe mal ein Beispiel von dem Code:

Code: 
UMKO: T     #Quelldaten_Anfang
      AUF DB [ #BED_DB_Nummer]
      LAR1  P##Zielfeld
      L     #Datenlaenge
      T LW [ AR1 , P#2.0 ]

      LAR2  #AR2_REG_FB
      L DBW [ AR2 , P#6.0 ]
      LAR2  #AR2_REG_STAT
      T LW [ AR1 , P#4.0 ]
      LAR2  #AR2_REG_FB
      L DBW [ AR2 , P#8.0 ]
      LAR2  #AR2_REG_STAT

      L     #DAT_DB_Adresse
      +D
      SLD   3
      L     DW#16#84000000
      OD
      T LD [ AR1 , P#6.0 ]
Die Warnungsmeldung dazu lautet: "Die Änderung des Registers AR2 hat keine Auswirkung auf symbolische Instanzzugriffe"
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hier steht alles wesentliche drin.

https://a248.e.akamai.net/cache.aut...1318674_Programming_guideline_DOKU_v12_de.pdf

Auf Seite 63 heißt es :

Beachten Sie folgende Empfehlungen bei der Programmierung von S7-1200/1500
Steuerungen, um eine hohe Leistungsfähigkeit zu erreichen:
x AWL: Verwenden Sie keine Register, da Adress- und Datenregister nur aus
Kompatibilitätsgründen von S7-1500 emuliert werden.

Wir selber stellen gerade auch alles auf 1500 um und haben deshalb AWL beerdigt.
In SCL ist sowas mittlerweile auch viel lesbarer zu programmieren.

Im allgemeinen kann ich nur empfehlen für die 1500 alles neu zu schreiben, da man mit migrierten 300/400 er Bausteinen den Leistungsumfang der 1500 nicht nutzt.
 
Also ich habe die Bausteine von einem Kollegen übernommen, und habe keine Möglichkeit den 49-Seitigen AWL Code mal so eben neu zu schreiben. Wie komme ich denn am Schnellsten zu dem Ergebnis, daß mein in STEP 7 v5.5 eigentlich perfekt funktionierender Baustein jetzt auch in der 1500er genau so läuft ? Ich bin nicht so fit in AWL, ich versetehe ja gerade kaum was da überhaupt passiert in diesem Code. Irgendwelche Bausteinzugriffe per Zeiger, der aus dem Akku 2 geholt wird. Und wo soll denn dabei das Problem liegen ? Gibt es für meinen Anwendungsfall nicht eine allgemeine Faustregel, wie vorzugehen ist ? Muss ich denn jetzt etwa wirklich eine 300e Steuerung verbauen weil das auf der neuen nicht geht ?
 
Zuletzt bearbeitet:
Grundsätzlich würde ich bei diesen Warnungen jetzt erstmal davon ausgehen dass alles noch so funktioniert wie gehabt. Im Code werden auch Standardbausteine gegen neue standardbausteine ersetzt worden sein. Diese überprüfen ob alles korrekt gemacht wurde etc.

Also erstmal wird das so funktionieren, allerdings muss man das als vergewaltigung der 1500er ansehen und sollte tunlichst Zeit einplanen das ganze zu optimieren. Ansonsten kommt man da nie wieder raus. Ich habe heute noch S7-300er in Anlagen welche mit S5 Code laufen den kaum noch einer versteht und auch eher suboptimal geschrieben wurde. Unglücklich wenn man die Software weiterverwenden will.

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es gibt noch Fehlermeldung: "Das VKE ist nicht initialisiert. Der Zugriff ist ungültig" - da stehe ich völlig auf dem Schlauch, was ich damit machen soll. Auf welches VKE haben denn die ursprünglichen Programmierer gebaut ? Oder wird es in v5.5 anders gebildet wie in den 1500er Steuerungen. Das is doch völlig unsinnig ?

Code: 
BEAB: L     #Befehlspointer
      SLD   3
      T     #AR2_REG_FB
      AUF DB [ #BED_DB_Nummer]

      U     #FM_Bef_ang
      SPB   BEA1

      L     B#16#0
      T     #Vorbelegung

      CALL  FILL
         ptr_type:=Variant
         BVAL    :=#Vorbelegung
         RET_VAL :=#Rueckgabewert
         BLK     :=#send_empf_zeig

BEA1: R     #ANZ_Reset
      R     #ANZ_Cancel
      R     #ANZ_Next
      R     #Bef_ausgabe_Wr_Re



      LAR1  P##Quellfeld
      L     1
      T LW [ AR1 , P#2.0 ]
      L     #BED_DB_Nummer
      T LW [ AR1 , P#4.0 ]
      L     #Befehlspointer
      SLD   3
      L     DW#16#84000000
      OD
      T LD [ AR1 , P#6.0 ]


      LAR1  P##Zielfeld
      L     1
      T LW [ AR1 , P#2.0 ]
      L     0
      T LW [ AR1 , P#4.0 ]
      L     49
      SLD   3
      L     #save_ar2
      +D
      L     DW#16#85000000
      OD
      T LD [ AR1 , P#6.0 ]



      CALL  BLKMOV
         blk_type:=Variant
         SRCBLK  :=#Quellfeld
         RET_VAL :=#Rueckgabewert
         DSTBLK  :=#Zielfeld


      LAR1  #MOB_DB_Adresse

      L     #Rueckgabewert
      L     W#16#0
      >D
      L     B#16#4
      SPB   F2FB



      LAR2  #AR2_REG_FB

      U DBX [ AR2 , P#0.6 ]
      LAR2  #AR2_REG_STAT

      =     #FM_chain_command
 
Zuletzt bearbeitet:
Draco Malfoy schrieb:
Habe mal ein Paar FBs von STEP 7 v5.5 nach TIA migriert. Habe in einem FB haufenweise Warnungen
Soll ich mir jetzt angesichts dieser Warnungen jetzt Sorgen machen oder meckert hier das TIA Portal wegen Nichtigkeiten.
Zum Vergrößern anklicken....

Draco Malfoy schrieb:
Also jetzt nochmal für mich: muss ich in diesem konkreten Fall was machen oder nicht ? Wie gesagt, in den 300er Steuerungen ist bisher alles prima gelaufen und wurden auch keine Warnungen generiert. Jetzt live in der 1500 zu testen habe ich leider keine Möglichkeit.
Zum Vergrößern anklicken....

Draco Malfoy schrieb:
Also ich habe die Bausteine von einem Kollegen übernommen, und habe keine Möglichkeit den 49-Seitigen AWL Code mal so eben neu zu schreiben. Wie komme ich denn am Schnellsten zu dem Ergebnis
Zum Vergrößern anklicken....

Wer hat Dir denn versprochen, dass so ne Migration mal eben, ohne Probleme, ohne zu testen, am schnellsten gemacht ist? Also wenn die Maschine ordentlich laufen soll, dann teste den Code, oder schreib ihn neu. Es gibt so viele Schweinereien, welche auch mit ner 300 in Step7 AWL gemacht sein könnten, da kann man per se nicht davon ausgehen, dass ohne Test alles auf ner 1500 läuft!

Zu Empfehlung, den Code für ne 1500 optimiert in SCL neu zu schreiben, wurde ja schon weiter oben einiges geschrieben.

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
.
Der TE hat offenbar keine Erfahrung in AWL, ob er diese in SCL hat, ist auch noch fraglich.

Selbst der S5 --> S7 Konverter hat einiges an Warnungen ausgespuckt und es lief trotzdem !
Selbst die indirekten Aufrufe wurden dort richtig migriert.

Bei den Fehlermeldungen musste man schon genauer hinschauen, das betraf aber meistens nur
S5-spezifische Befehle oder Aufrufe von FB´s, die es in S7 nicht mehr gibt.
Da gab es aber stets ein Migrationsprotokoll, das genau auf die fehlerhafte Zeile hinwies.

Ich schliesse mich also erstmal dem Beitrag#8 von René an.


@TE
Schau auf deine Fehlermeldungen und versuche, den Fehler in den betreffenden Zeilen
auszumerzen.
Probiere, dein migriertes (und korrigiertes) Programm zu testen.

Du hast dein Mengengerüst (E/A/Bus/Baugruppen) nicht genannt, schlimmstenfalls kannst
du eine Parallelinstallation machen.
Damit kannst du von der 1500 schnell auf die 300 umschalten, wenn es eine kritische Anlage
ist und du dir keinen längeren Ausfall leisten kannst.

Allerdings musst du schon selbst den einen gegen den anderen Aufwand abwägen.
 
SoftMachine schrieb:
@TE
Schau auf deine Fehlermeldungen und versuche, den Fehler in den betreffenden Zeilen
auszumerzen.
Probiere, dein migriertes (und korrigiertes) Programm zu testen.

Du hast dein Mengengerüst (E/A/Bus/Baugruppen) nicht genannt, schlimmstenfalls kannst
du eine Parallelinstallation machen.
Damit kannst du von der 1500 schnell auf die 300 umschalten, wenn es eine kritische Anlage
ist und du dir keinen längeren Ausfall leisten kannst.

Allerdings musst du schon selbst den einen gegen den anderen Aufwand abwägen.
Zum Vergrößern anklicken....
Danke für den Tipp. Ja, das mit dem längeren Ausfall ist so ne Sache. Ich habe da maximal 1 Tag Zeit an der Anlage, meinstens reicht es nur zum Draufspielen und feintunen.
Also die Fehler wo er gemeckert hat waren einmal mit dem VKE und Resetten (scheint ja mit dem Befehl "SET" davor zu beheben zu sein ?) und dann waren noch Probleme im Datentyp bei der Verwendung von SFB 53. Der alte SFB 53 arbeitet mit INT Werten, während der neue an einigen Stellen scheinbar nur UINT akzeptiert. Hier hätte ich allerdings ne Frage: Ich kann zwar den Datentyp der Variable von INT auf UINT ändern, aber im Code werden ja Konstanten je nach SPB in diese Variable geladen. Eine Abfolge L 256 - T #Adresse ergbibt aber doch nicht dasselbe Ergebnis, abhängig davon ob #Adresse jetzt nun INT oder UINT ist ? Die Laden - Transferieren Routine tut doch nur Bits durch die Gegend schieben, ohne Rücksicht auf Vorzeichen ? Oder nicht ?
 
.
Nun, ich bin jetzt nicht unbedingt der TIA-Verfechter, aber grundsätzlich sehe ich es wie folgt:


Ein SET erzwingt das VKE unbedingt, aber es kann vom Programmablauf auch mal eine "0" erforderlich sein.
Da musst du versuchen, es genauer zu ergründen, leider.

Beim SFB53 kannst du dir die INT-Werte vor dem Aufruf in eine UINT-Variable umkopieren, eben mit
L xxx T yyy.
Und ein "negativer" Datentyp (beim Vorzeichen) ist mir neu.

Und wenn dir ein Tag an der Anlage nur zum "Draufspielen" reicht, mach´doch eine stationäre
Parallelinstallation fest installiert im Schaltschrank für eine schnelle Umschaltung: eine CPU aus,
die andere an und abends wieder zurück.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
SoftMachine schrieb:
.
Ein SET erzwingt das VKE unbedingt, aber es kann vom Programmablauf auch mal eine "0" erforderlich sein.
Da musst du versuchen, es genauer zu ergründen, leider.
Zum Vergrößern anklicken....
Das verstehe ich überhaupt gar nicht. Ich will doch nur ein Paar Merker resetten wie im Beispiel oben ? Da reicht es doch, wenn ich "SET" davor setze, damit diese Anweisung immer ausgeführt wird ?
Beim SFB53 kannst du dir die INT-Werte vor dem Aufruf in eine UINT-Variable umkopieren, eben mit
L xxx T yyy.
Zum Vergrößern anklicken....
Klingt beruhigend. Also ist die Bitfolge einer positiven Ganzzahl im UINT und INT vollkommen identisch ?
Und wenn dir ein Tag an der Anlage nur zum "Draufspielen" reicht, mach´doch eine stationäre
Parallelinstallation fest installiert im Schaltschrank für eine schnelle Umschaltung: eine CPU aus,
die andere an und abends wieder zurück.
Zum Vergrößern anklicken....
Werde mir möglicherweise soetwas in der Richtung überlegen müssen.
 
.
Ein SET setzt das VKE immer auf "1" und nachfolgende VKE-abhängige Anweisungen werden
ausgeführt.
Im Programmablauf kann es aber auch gewollt sein (durch vorherige Verknüpfungen), dass das
VKE nicht erfüllt sein soll und auf "0" bleibt. Dann werden eben diese Anweisungen nicht
ausgeführt.

INT und UINT sind bis zu einem bestimmten Wert in der Bitfolge gleich.
Der Typ UINT nutzt aber die VZ-Stelle für die darzustellende Zahl und kann
damit einen anderen Zahlenbereich als wie in INT darstellen.
Am besten, du schaust dir die Datentypen für Ganzzahlen mal HIER an.
 
Ok, verstehe. D.h. ich rette vorher mein VKE in einem Übertragsmerker und stelle es nach dem Sprung wieder her. INT und UINT auch verstanden. Sprich, das Vorzeichen sitzt dort am MSB und nicht am LSB. Das erklärt natürlich warum die deckungsgleich sind im Bereich 0 bis 32767. Danke!
 

Similar threads

edison
TIA Migration C7 nach TIA
Antworten
4
Aufrufe
2K
JesperMP
JesperMP
P
TIA CPU-Migration auf S7-1500
Antworten
6
Aufrufe
4K
PLCOsman
P
rkoe1
TIA TIA V13 - Im FB Eingangsword nach Localword übertragen
Antworten
14
Aufrufe
3K
Ottmar
O
Zurück
Oben