TIA TIA V15.1 Kompatibilität von PLC-Programmen aus früheren Versionen

ducati

Level-3
Beiträge
9.649
Reaktionspunkte
2.752
Zuviel Werbung?
-> Hier kostenlos registrieren
Im Handbuch finden sich da solche Dinge:

Größe von ARRAY of BOOL/BYTE/CHAR (S7-1500)
Bisher hatten ARRAYs der Datenypen BOOL, BYTE oder CHAR unterschiedliche Größen,
abhängig davon, ob sie innerhalb einer Struktur verwendet wurden oder nicht. Ab V15 wurde
die Größe der ARRAYs vereinheitlicht. Wenn Sie in Ihrem Programm absolut, z. B. über einen
ANY-Zeiger, auf ein ARRAY von BOOL, BYTE oder CHAR zugreifen, müssen Sie das
Programm nach dem Hochrüsten prüfen.

Vergleich eines ARRAY-Elements mit einer Variable vom Datentyp "VARIANT" in SCL (S7-1200/1500)
Der Vergleich eines variabel indizierten ARRAY-Elements mit einem VARIANT wurde bisher
in einigen Fällen nicht korrekt durchgeführt. Statt des ARRAY-Elements wurde das gesamte
ARRAY für den Vergleich herangezogen.
Dieses Verhalten wurde in V15 korrigiert: Für den Vergleich wird nun das indizierte ARRAYElement
ausgewertet. Wenn Sie in Ihrem Programm solche Vergleiche verwenden, müssen
Sie den betroffenen Baustein nach dem Hochrüsten prüfen.
Beispiel:
IF (#my_Array[#1] = #my_variant) THEN…
Bisher wurde "my_variant" mit "my_Array" verglichen. Ab V15 wird der Vergleich korrekt
durchgeführt und "my_variant" wird mit Element #1 von "my_Array" verglichen.


Anweisungen "(U)MOVE_BLK" und "(U)FILL_BLK" (S7-1500)
Die Anweisungen "(U)MOVE_BLK" und "(U)FILL_BLK" haben im TIA Portal <= V15 beim
direkten Zugriff auf die Peripherie nur auf das Prozessabbild zugegriffen.
Dieses Verhalten wurde korrigiert und führt jetzt zu einem Laufzeitfehler, da direkte
Peripheriezugriffe bei BLK-Befehlen nicht zulässig sind.

AWL: Anweisungen "SRW", "SLW" und "SSI" (S7-300, S7-400, S7-1500)
Der erlaubte Wertebereich der Schiebezahl dieser Anweisungen hat sich vom TIA Portal V13
SP1 zum TIA Portal V14 verändert.
In der Version V13 SP1 ist es möglich, auf einer CPU der Baureihen S7-1200/-1500 als
Schiebezahl eine Zahl im Wertebereich von 0 bis 31 und auf einer CPU der Baureihen
S7-300/-400 als Schiebezahl eine Zahl im Wertebereich von 0 bis 15 anzugeben.
Ab der Version V14 wurden die Wertebereiche für alle CPU-Baureihen
(S7-300/400/1200/1500) auf den einheitlichen Wert von 0 bis 15 festgelegt.

Schnittstelle von Organisationsbausteinen mit Standardzugriff
Die Schnittstelle von Organisationsbausteinen mit Standardzugriff muss eine Mindestgröße
von 20 Byte haben. In älteren Versionen des TIA Portals wurde während des
Übersetzungslaufs nur die Schnittstelle des OB1 hinsichtlich der Mindestgröße überprüft. Ab
V14 werden die Schnittstellen aller Organisationsbausteine geprüft. Möglicherweise erhalten
Sie beim Übersetzen eines bisher fehlerfrei übersetzbaren Programms nun eine
Fehlermeldung.

Offline/Online-Vergleich
In der aktuellen Version wurden Bereinigungen der internen Projektdaten vorgenommen, um
die Datenintegrität zu erhöhen. Nach der Installation können dadurch vereinzelt Bausteine
beim Öffnen automatisch korrigiert werden und der Offline/Online-Vergleich zeigt folglich
unterschiedliche Prüfsummen an.
Online-/Offline-Unterschiede in der Projektnavigation (S7-1200 FW V2.0 und V2.1)
Wenn Sie mithilfe der Anweisung "WRIT_DBL" einen Datenbaustein ändern, wird der dadurch
entstandene Unterschied zwischen Online- und Offline-Baustein zunächst nicht korrekt durch
die Symbole in der Projektnavigation angezeigt. Der Unterschied wird erst dargestellt, wenn
Sie die Online-Verbindung trennen und anschließend erneut online gehen.

...

Also nen fremdes Projekt mal eben hochrüsten, weil man die richtige alte TIA-Version nicht dabei hat, kann mächtig in die Hose gehen, vor allem Freitag Nachmittag...

Gruß.
 
AWL: Anweisungen "SRW", "SLW" und "SSI" (S7-300, S7-400, S7-1500)
Der erlaubte Wertebereich der Schiebezahl dieser Anweisungen hat sich vom TIA Portal V13
SP1 zum TIA Portal V14 verändert.
In der Version V13 SP1 ist es möglich, auf einer CPU der Baureihen S7-1200/-1500 als
Schiebezahl eine Zahl im Wertebereich von 0 bis 31 und auf einer CPU der Baureihen
S7-300/-400 als Schiebezahl eine Zahl im Wertebereich von 0 bis 15 anzugeben.
Ab der Version V14 wurden die Wertebereiche für alle CPU-Baureihen
(S7-300/400/1200/1500) auf den einheitlichen Wert von 0 bis 15 festgelegt.

Es ist ja schon mal gut, dass das Verhalten dokumentiert ist. Interessant wäre jetzt natürlich noch,
was passiert denn, wenn man in der V14 >15x schieben möchte, was in <V14 ja noch möglich war.
Meckert das der Kompiler an oder wird es einfach übertragen und er schiebt dann statt der Vorgabe z.B. 20 nur die
maximal möglichen 15?

OK, ich habe es einmal schnell ausprobiert, der Kompiler meckert es an.
AWL.jpg
 
Es ist ja schon mal gut, dass das Verhalten dokumentiert ist.

Jo, ich hab mal nur das für mich relevante hier gepostet, im Handbuch steht noch viel viel mehr. Die Frage ist, was alles nicht dokumentiert ist, u.U. weils sie's grad selber noch nicht wissen.

Weil immer wieder verbreitet wird, dass man mal so eben schnell hochrüsten kann, will ich hier nur davor warnen. Vor allem bei fremden, großen, unübersichtlichen Programmen...

Wenn da nur 10 UND/ODER Verknüpfungen in FUP drin sind, kann man sicherlich alles machen, sogar das Programm schnell neu schreiben...

Gruß.
 
Weil immer wieder verbreitet wird.....will ich hier nur davor warnen.

Ich verstehe schon was du meinst. Da ich selber gerade vor einem riesen Problem mit den abstürzenden
Comfort Panels stehe, bin ich generell schon vorsichtig und versuche sogar bei eingenen Anlagen
wenn möglich nichts mehr anzufassen solange es läuft. Schöner Mist.
 
Hallo Ducati,

ich habe mich jetzt mal durch deinen Link durchgelesen. Deine Liste könnte man ja noch endlos erweitern :-(

Vor allen ändert sich das Verhalten teilweise nicht nur durch eine andere TIA Version, sondern auch schon durch eine andere FW

Nicht genutzte Bits von PLC-Datentypen (UDT) bei Firmware >= V1.8.1
Die nicht genutzten Bits von PLC-Datentypen in Standard Speicherbereichen werden belegt bzw. überschrieben, z. B. bei einem PLC-Datentyp, der 4 Bit beinhaltet.

Bei Firmware Versionen < V1.8.1 konnten Sie die nicht genutzten Bits eines PLC-Datentyps anderweitig verwenden.
Ab der Firmware Version >= V1.8.1 werden alle Bits, auch wenn nur 4 Bits benutzt werden, belegt bzw. überschrieben.

[h=4]Explizite Datentypkonvertierung in SCL (S7-1200) bei Firmware >= V4.2[/h] Bei Firmware Versionen < V4.2 wurde bei der expliziten Datentypkonvertierung in SCL von SINT/INT/DINT/REAL_TO_STRING/WSTRING die Zeichenkette rechtsbündig übertragen und mit führenden Leerzeichen aufgefüllt.
Beispiel: REAL_TO_WSTRING(12) = ' 1.200000E+1'
Ab dem TIA Portal V13 wird bei der expliziten Datentypkonvertierung in SCL von SINT/INT/DINT/REAL_TO_STRING/WSTRING die Zeichenkette mit einem führenden Vorzeichen dargestellt und linksbündig übertragen.
Beispiel: REAL_TO_WSTRING(12) = '+1.200000E+1'

usw...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
was passiert denn, wenn man in der V14 >15x schieben möchte, was in <V14 ja noch möglich war.
Warum sollte man ein Word um mehr als 15 Bitstellen schieben wollen? Der Programmierer der sowas programmiert hat, der hat doch eh keine Ahnung was er da tut. Da ist es gar nicht verkehrt wenn der Compiler (oder schon der Editor) sowas anmeckert. Allerdings sollte der Compiler (nach meiner Meinung) auch meckern, wenn jemand um 0 Stellen schieben will (oder SSD/SLD/SRD um 32 Stellen) - das ist genauso sinnfrei, bleibt aber zulässig.

Es ist ja schon mal gut, dass das Verhalten dokumentiert ist.
Nur schade, daß die heutzutage selbst solche kleinen Änderungsmeldungen nicht eindeutig und fehlerfrei hinkriegen, von der eigentlichen Dokumentation der Anweisungen ganz zu schweigen.
Eine S7-1200 kann gar kein AWL, von daher kann das Verhalten der S7-1200 auch nicht angepasst worden sein.

In der Version V13 SP1 ist es möglich, auf einer CPU der Baureihen S7-1200/-1500 als
Schiebezahl eine Zahl im Wertebereich von 0 bis 31 und auf einer CPU der Baureihen
S7-300/-400 als Schiebezahl eine Zahl im Wertebereich von 0 bis 15 anzugeben.
Falsch. Tatsächlich kann man im AWL-Editor für S7-300/400 und S7-1500 jeweils 0 bis 32 angeben und ohne Fehlermeldung übersetzen.
(ob sich das mit 0 Fehlern übersetzte Programm in die CPU laden läßt habe ich nicht geprüft)
Lediglich die Hilfe sagt
- zu SLW/SRW/SSI : "Die angegebene Zahl muß in einem Wertebereich von 0 bis 15 liegen"
- zu SLD/SRD/SSD : "Die angegebene Zahl muß in einem Wertebereich von 0 bis 31 liegen"
und das einheitlich für S7-300/400 und S7-1500

Ab der Version V14 wurden die Wertebereiche für alle CPU-Baureihen
(S7-300/400/1200/1500) auf den einheitlichen Wert von 0 bis 15 festgelegt.
Stimmt das wirklich? Und wie ist es bei SLD/SRD/SSD?

Code:
zulässige Schiebezahl in AWL
           +-------------------+-------------------+-------------------+--------------+
           |    Step7 V5.5     | TIA V13 SP1 Upd 8 |      TIA V14      | TIA 13 Hilfe |
           +-------------------+-------------------+-------------------+--------------+
           | 300/400 |   1500  | 300/400 |   1500  | 300/400 |   1500  | 300/400/1500 |
+----------+-------------------+-------------------+-------------------+--------------+
| SLW, SRW |  0 - 15 |    -    |  0 - 32 |  0 - 32 | 0 - 15 ?| 0 - 15 ?|    0 - 15    |
+----------+-------------------+-------------------+-------------------+--------------+
| SSI      |  0 - 15 |    -    |  0 - 32 |  0 - 32 | 0 - 15 ?| 0 - 15 ?|    0 - 15    |
+----------+-------------------+-------------------+-------------------+--------------+
| SLD, SRD |  0 - 32 |    -    |  0 - 32 |  0 - 32 |    ?    |    ?    |    0 - 31    |
+----------+-------------------+-------------------+-------------------+--------------+
| SSD      |  0 - 32 |    -    |  0 - 32 |  0 - 32 |    ?    |    ?    |    0 - 31    |
+----------+-------------------+-------------------+-------------------+--------------+

PS: die hier genannte Begrenzung der Schiebezahl wirkt nur auf die Angabe einer konstanten Schiebezahl direkt in der Anweisung. Wenn die Schiebezahl aus Akku2 kommt, dann kann die Schiebezahl 0 bis 255 sein. Wie sich die Anweisung bei einer Schiebezahl 0 oder > 15 verhält ist dokumentiert.

Harald
 
warum sollte man ein word um mehr als 15 bitstellen schieben wollen? Der programmierer der sowas programmiert hat, der hat doch eh keine ahnung was er da tut. Da ist es gar nicht verkehrt wenn der compiler (oder schon der editor) sowas anmeckert. Allerdings sollte der compiler (nach meiner meinung) auch meckern, wenn jemand um 0 stellen schieben will (oder ssd/sld/srd um 32 stellen) - das ist genauso sinnfrei, bleibt aber zulässig.

*ack*
..........
 
Warum sollte man ein Word um mehr als 15 Bitstellen schieben wollen? Der Programmierer der sowas programmiert hat, der hat doch eh keine Ahnung was er da tut. Da ist es gar nicht verkehrt wenn der Compiler (oder schon der Editor) sowas anmeckert. Allerdings sollte der Compiler (nach meiner Meinung) auch meckern, wenn jemand um 0 Stellen schieben will (oder SSD/SLD/SRD um 32 Stellen) - das ist genauso sinnfrei, bleibt aber zulässig.

Ganz so sinnfrei ist es nicht.
Wo landet das herausgeschobene Bit?
Gab's da nicht mal was mit den Status-Bits?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Warum wohl meint Siemens seit 24 Jahren und nun wieder, daß die mit TIA (versehentlich?) eingeführten Anweisungen SLW/SRW/SSI mit Schiebezahl >= 16 unnötig sind und wieder abgeschafft werden? ;)

SLW/SRW/SSI mit Schiebezahl 0 werden wie NOP behandelt. Es werden keine Statusbits verändert. Die Anweisungen tun nichts.

SLW/SRW mit Schiebezahl 16 schieben das Bit 0 bzw Bit 15 ins Statusbit A1 (das erreicht man auch mit SRW/SLW 1) und löschen den AKKU1-L auf 0. Vom ehemaligen AKKU1-L-Inhalt ist nur das Bit 0 bzw. 15 im Statusbit A1 übrig. Schiebezahl > 16 ergibt immer das gleiche Ergebnis: AKKU1-L = 0 und A1 = 0

SSI mit Schiebezahl >= 16 ergibt immer das gleiche Ergebnis: AKKU1-L = 0 und A1 = 0 bzw. AKKU1-L = 16#FFFF und A1 = 1

Will man nur die Bits 0 oder 15 in A1 haben, dann kann man SRW 1 oder SLW 1 verwenden. Braucht man tatsächlich mal zusätzlich auch das komplette löschen bzw. 1-setzen des AKKU1-L, so kann man das wie früher in Step7 classic durch zwei aufeinanderfolgende Schiebebefehle mit Summe der Schiebezahl 16 machen, z.B. SLW 15 + SLW 1.

Harald
 
Warum sollte man ein Word um mehr als 15 Bitstellen schieben wollen? Der Programmierer der sowas programmiert hat, der hat doch eh keine Ahnung was er da tut. Da ist es gar nicht verkehrt wenn der Compiler (oder schon der Editor) sowas anmeckert.

Jo, das ist schon klar, die meisten der Änderungen sind ja auf die eine oder andere Weise "Fehlerbereinigungen". Darum geht's mir aber garnicht. Der Punkt ist, dass sich das S7-Programm nach einer Hochrüstung u.U. anders verhält. U.U. wurde das alte Fehlverhalten im alten Programm ja auch irgendwie umgangen und nach der Hochrüstung passiert jetzt ganz großer Quatsch...
Bei größeren Anlagen kann man ja auch nicht immer alle Funktionalitäten neu testen, nur weil mal ein Bit invertiert wurde.

Was ich damit sagen will, ich werd niemals nen TIA-Projekt mal eben auf der Baustelle auf ne neue Version hochziehen.

Gruß.
 
Ein 16-bit Wort bitweise zu schieben mehr als 16 Stellen ist meist wahrscheinlich ein Programmierfehler.
Mit diesen update macht TIA den Programmierer darauf aufmerksam, das vielleicht etwas faul ist.
Der Programmierer kann dann entscheiden ob es so gewollt ist, und den Code mit andere Verfahren das gewünschte erreichen, oder es war ein einfache Tippfehler und diese Tippfehler korrigieren.
Ich finde das es von Siemens korrekt gelöst ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein 16-bit Wort bitweise zu schieben mehr als 16 Stellen ist meist wahrscheinlich ein Programmierfehler.
Mit diesen update macht TIA den Programmierer darauf aufmerksam, das vielleicht etwas faul ist.
Der Programmierer kann dann entscheiden ob es so gewollt ist, und den Code mit andere Verfahren das gewünschte erreichen, oder es war ein einfache Tippfehler und diese Tippfehler korrigieren.
Ich finde das es von Siemens korrekt gelöst ist.

Die Frage ist ja nicht unbedingt, ob die Änderung vom Siemens jetzt richtig oder falsch ist. Sondern die Aussage ist, dass es Änderungen gibt, welche dazu führen, dass ein Projekt u.U. nach einer Hochrüstung nicht bzw. nicht mehr identisch funktioniert, und händische Nacharbeit und Tests notwendig sind.

Gruß.
 
Man wird nicht in den Situation gelangen dass man ohne Warnung ein Programm einspielt dass denn unterschiedlich funktioniert.
Man wird gezwungen Stellung zu nehmen was zu tun.
Ich finde es korrekt.
 
Wie kommt man denn überhaupt in die Verlegenheit unverhofft auf der Baustelle mal eben ein Projekt hochrüsten zu müssen?

edit: Ausser man macht velleicht wirklich Service für sehr viele Fremdanlagen. Aber wenn man das macht hat man auch alle Versionen dabei.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie kommt man denn überhaupt in die Verlegenheit unverhofft auf der Baustelle mal eben ein Projekt hochrüsten zu müssen?

edit: Ausser man macht velleicht wirklich Service für sehr viele Fremdanlagen. Aber wenn man das macht hat man auch alle Versionen dabei.

Wir haben halt Anlagen, bei denen verschiedene Firmen mal Änderungen machen, bzw. der Kunde auch mal selbst... Und vieles auch mal schnell auf Zuruf. Wer da wann mit welcher Version dran war, kann man nicht mehr wissen...

Alle Versionen kann man dann als VM auch nicht immer dabei haben
 
Wird die verwendete TIA-Version eigentlich irgendwo auf der CPU gespeichert? So dass man diese beispielsweise am HMI anzeigen könnte?
 
Zurück
Oben