TIA Programmmigration AWL S7 416 in S7 1500

[Vex]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Liebe Community,

ich stehe zur Zeit vor einem kleinen aber feinen Problem und hoffe ich könnt mir weiterhelfen.
Ich habe vom Kunden ein altes Simatic Programm bekommen, welches zu 99% in AWL geschrieben ist.
Die Anlage soll von einer S7 416 auf eine S7-1516 und ET200SP Stationen umgebaut werden.
Das Programm soll auf TIA V15.1 migriert werden. Folgender AWL Code lässt sich allerdings nicht migrieren:

L #Pos_Nr
SLW 4
T #Offset
LAR1

A #FL_Ziel_1
OPN "SAP_Ziel"
AN DBX [ AR1 , P#1.0 ]
OPN "SPS_Quit"
S DBX [ AR1 , P#1.1 ]
OPN "SAP_Ziel"
A DBX [ AR1 , P#1.0 ]
AN DBX [ AR1 , P#1.1 ]
OPN "SPS_Quit"
R DBX [ AR1 , P#1.1 ]

Da ich erst als Programmierer eingestiegen bin und AWL auch nicht gerade meine Stärke ist, würde ich mich über Hilfe freuen.
Gibt es aus eurer Erfahrung heraus noch Probleme die häufig auftreten bei der Migration, aber von TIA nicht als Fehler erkannt werden bzw. später zu Fehlern führen?

 

[DeltaMikeAir]

Folgender AWL Code lässt sich allerdings nicht migrieren:

Dürfte man denn die Fehlermeldung des TIA Compilers erfahren ( und auf welche Zeile er zeigt )?
Und auf was ist deine TIA Mnemonik eingestellt? Deutsch oder international?

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Vex,

ich muss gestehen, dass ich mit der Migration von AWL-Code in das TIA-Portal nicht so vertraut bin.
Aber, was für Fehlermeldungen kommen denn?

VG

MFreiberger

 

[DeltaMikeAir]

Gibt es aus eurer Erfahrung heraus noch Probleme die häufig auftreten bei der Migration, aber von TIA nicht als Fehler erkannt werden bzw. später zu Fehlern führen?

Es würde mich wundern, wenn das migrierte Programm der 416 sofort und ohne Probleme funktionieren würde.

 

[JesperMP]

Vielleicht probieren die AWL Code ins SCL umzusetzen ?
Es gibt in "SAP_Ziel" und "SPS_Quit" Array-Strukturen die mit Pos_Nr gesprungen werden kann.
Die Untervariablen .bit_1_0 und .bit_1_1 kann mehr beschreibender Namen haben.
Ich glaube die dementsprechende SCL Code wurde so aussiehen:

IF #FL_Ziel_1 THEN
  IF NOT "SAP_Ziel".[#Pos_Nr].bit_1_0 THEN
    "SPS_Quit".[#Pos_Nr].bit_1_1 := TRUE ;
  END_IF ;
  IF "SAP_Ziel".[#Pos_Nr].bit_1_0 AND NOT "SAP_Ziel".[Pos_Nr].bit_1_1 THEN
    "SPS_Quit".[#Pos_Nr].bit_1_1 := FALSE ;
  END_IF ;
END_IF ;

 

[Vex]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen Dank für die schnellen Antworten.
Die Mnemonik ist auf International gestellt.
Fehlermeldungen bekomme ich Folgende:


Fehlermeldung FC92
Der Compiler zeigt immer auf den P#1.0 oder P#1.1 von den Aufrufen
AN DBX [ AR1 , P#1.0 ].
Die anderen Fehlermeldungen bezüglich des Know-How Schutz sind nicht relevant da die Bausteine nicht mehr genutzt wurden bis auf FC7 und FC8 diese müssen allerdings händisch geändert werden.

Ich gehe auch ganz stark davon aus das es Probleme geben wird. Allerdings möchte ich so viele Stolperfallen wie möglich vor dem Umbau beseitigen, da für die IBN wenig Zeit ist.

 

[MFreiberger]

Moin Vex,

es steht ja geschrieben, dass "Die teilqualifizierte Adresse kann nicht in eine vollqualifizierte Adresse umgewandelt.."

Warum wäre das denn nötig? Der entsprechende DB ist doch aufgeschlagen.

Kann man den Fehler ignorieren und den Code in FC92 manuell anpassen? Wie sieht der denn aktuell aus?

VG

MFreiberger

 

[Vex]

Der aktuelle Code in FC 92 ist:

Netzwerk 1
L #Pos_Nr
SLW 4
T #Offset
LAR1

Netzwerk 2:

A #FL_Ziel_1
OPN "SAP_Ziel"
AN DBX [ AR1 , P#1.0 ]
OPN "SPS_Quit"
S DBX [ AR1 , P#1.1 ]
OPN "SAP_Ziel"
A DBX [ AR1 , P#1.0 ]
AN DBX [ AR1 , P#1.1 ]
OPN "SPS_Quit"
R DBX [ AR1 , P#1.1 ]

mehr steht dort nicht geschrieben. Ich habe es auch so verstanden, dass ich den DB erst aufschlage und dann auf die Adressen zugreifen kann.
Der Code wurde also 1 zu 1 übernommen und kann nun noch angepasst werden.
Den Vorschlag von JesperMP werde ich mal ausprobieren.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was ich noch nicht verstanden habe:
Ist das die Fehlermeldung nach dem migrieren oder nach dem übersetzen?

Was sagt TIA denn, wenn Du den Code in einem andern Baustein hineinschreibst? Wird grundsätzlich immer der PointerOffset P#1.0 oder P#1.1 angemeckert (eigentlich ist da ja nichts falsch dran)?

Zumindest wurde ja kein vollqualifizierter Zugriff eingefügt (Es wird ja auch gemeckert, dass das nicht geht).
Aber warum kann der Teilqualifizierte Zugriff nicht bleiben?

Wenn ich so einen Code bei mir in eine FC schreibe (anderer DB-Name, aber von der Syntax her gleich), dann wird das anstandslos übersetzt.

Wobei ich zugeben muss, dass ich TIAV16 und nicht 15.1 verwende. Vielleicht gibts da irgend einen Bug? Hast Du das aktuellste Update installiert?

VG

MFreiberger

 

[Windoze]

Ich habe mal Testweise in einem Projekt die zwei DBs eingefügt.
Dann lässt sich der Code 1:1 übersetzen ohne Fehler.

Bei mir ist es eine CPU 1511F im TIA Portal V15.1 Upd6

 

[Vex]

Die Fehlermeldung taucht nach der Migration auf, wenn ich übersetzte zeigt er mir dort keine Fehler.
Klickt man nach der Migration auf den Fehler verweist er immer auf die Pointer.
Mein Gedanke dabei ist halt das obwohl der Programmcode übersetzt wird es trotzdem zu Fehlern kommen könnte.?

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mein Gedanke dabei ist halt das obwohl der Programmcode übersetzt wird es trotzdem zu Fehlern kommen könnte.?

Eigentlich nicht. Wenn der Code (fehlerfrei) übersetzt wurde, muss er auch funktionieren.

 

[PN/DP]

Der Compiler zeigt immer auf den P#1.0 oder P#1.1 von den Aufrufen
AN DBX [ AR1 , P#1.0 ].

Nein. Den Compiler stört nicht das P#1.0 oder P#1.1, sondern wie der Meldetext schon sagt, es stört die nur teilqualifizierte Adresse (DBX ohne DB-Nummer).

Mein Gedanke dabei ist halt das obwohl der Programmcode übersetzt wird es trotzdem zu Fehlern kommen könnte.?

Damit muß man immer rechnen, wenn man ein Programm auf eine andere CPU migriert. Besonders wenn die CPU viel schneller als die ursprüngliche CPU ist und eine ganz andere CPU-Familie ist. Ein S7-1500-CPU ist nicht 100% kompatibel. Und hat andere Firmware-Fehler als die 416. Und es kommt drauf an, welche "Programmiertricks" im ursprünglichen Programm vorkommen, die könnten auf der S7-1500 eventuell nicht mehr funktionieren.

Harald

 

[SPS-Pascal]

Da du schon genug qualifizierte Antworten bekommen hast kommt hier jetzt Mal was unqualifiziertes. Bis du deine 1516 und deine ET200SP E/A's bekommst und die Anlage in Betrieb nehmen kannst, hast du mehr als genug Zeit um entweder AWL ausführlich zu lernen oder wie @JesperMP schon sagte den Code on SCL zu übersetzen. Ironie off und schönes Wochenende.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mein Gedanke dabei ist halt das obwohl der Programmcode übersetzt wird es trotzdem zu Fehlern kommen könnte.?

Du wirst mit der Nase darauf gestossen, wenn das Programm formale Fehler enthält.
Änderst Du die bemeckerte[n] Zeile[n] so, dass die FehlerMeldungen nicht mehr auftreten, so ist das definitiv keine Garantie dafür, dass das Programm tasächlich (nur) das tut, was es tun soll (und darf). So gesehen: es ist beim besten Willen nicht auszuschliessen, dass es zu Fehlern bzw. FehlVerhalten kommen könnte.

Und es kommt drauf an, welche "Programmiertricks" im ursprünglichen Programm vorkommen, ...

Um die ProgrammierTrickser einwenig in Schutz zu nehmen: manchmal sind WorkArounds erforderlich/unvermeidlich und die können später als ProgrammierTricks (miss-)verstanden werden, insbesondere, wenn sie eines Tages überflüssig und bereits fehlerhaft/unvollständig "angepasst" wurden.

 

[Vex]

So komme jetzt endlich dazu mal zu antworten.
Danke für die Hilfe und Tipps.
Leider ist die Zeit um sich ausführlich mit AWL und Programmiertricks zu beschäftigen nicht da, weil alle Bauteile bereits geliefert sind und der Kunde den Umbau am liebsten letzte Woche schon gemacht hätte

 

[ducati]

warum will er denn überhaupt ne coole 400er in ne blöde TIAverseuchte 1500er umbauen? Und dann noch mal eben schnell und ohne den Code aufzuräumen...

Naja, hab auch abundzu so Anfragen. Stellt sich halt immer die Frage, neumachen oder migrieren. Beim Migrieren kommt meist noch unverständlicher Code raus, als es vorher schon war und bei der Fehlersuche mal eben bist voll im Eimer. Beim Neumachen sagt Dir meist niemand, wie die Funktion der Software aussehen soll, dafür weisst aber bei der Inbetriebnahme wo Du suchen musst...