TIA Problem (U)BLKMOV bei SCL und TIA v13 SP1

Hallo zusammen,

ich hatte Freitag einen Gau mit v13SP1 Update 1, der mich hinterher wieder zum Downgrade gezwungen hat. Jetzt wollte ich mal fragen, ob das vielleicht schon jemand anderem passiert ist...

Ich habe einen Multi-Kanal-Temperaturregler, der (ein bisschen tricky) in STAT eine Instanz des PID-Reglers hat und danach eine Anzahl x von baugleichen UDFs (Heizzonen) als Array. Beim Aufruf wird nun in SCL die Zone x in die Instanz kopiert, darauf geregelt und danach die Instanz wieder zurückkopiert. Das ganze läuft seit Urzeiten reibungslos (S7 v5/TIA 12/13). Seit dem Update scheint der erste Teil noch zu laufen, aber das Zurückkopieren landet im falschen Bereich - genau um einen versetzt (Ziel +1 Zone). Ist der Fehler schon jemandem aufgefallen?

Hier die Definition des Interfaces:



Hier der signifikante Auszug aus der Software:

[..]

// This Zone is active and on
#bReset := "bFALSE";
#ret:=BLKMOV(SRCBLK := #ZONE[#index], DSTBLK => #PID); // Kopieren in die PID-Instanz

#PID(PV_IN:=#PV_IN, SP_INT:=#SP_INT, COM_RST:=#bReset); // Regeln auf der Instanz

#ret:=BLKMOV(SRCBLK := #PID, DSTBLK => #ZONE[#index]); // Zurückkopieren in das ursprüngliche Fach (Versatz!)

[..]

Wenn du noch Step7 V5.5 zur Verfügung hast, kannst du dir den AWL Code den der Compiler erzeugt ansehen indem du diesen damit aus der Steuerung oder aus Plcsim zurücklädst.
Es wäre nicht der erste Fehler der beim TIA-SCL Compiler eingebaut wurde, es kommen auch mit Updates gelegentlich neue hinzu die vorher noch nicht da waren.

Hast Du schonmal probiert, ob es mit

Struct1 := Struct2;

anstelle des BLKMOV funktioniert?

Bist Du sicher, daß beim zweiten BLKMOV die Variable #index den gleichen Wert hat wie beim ersten BLKMOV?

Harald

Ja, das hat sie.
Wie gesagt, die Funktion ist seit Urzeiten unverändert und funktioniert seit Jahren in verschiedensten Versionen von S7/TIA.

Michael

"Leider" habe ich jetzt das SP1 runtergeschmissen. Ich muss mir das nochmal in einer virtuellen Maschine installieren und dann ausprobieren. Das ist zumindest ein interessanter Ansatz. Ich hoffe, der Compiler nimmt es nur an - die Definition von Quelle und Ziel unterscheidet sich doch. Im einen Fall ist es eine UDT, im anderen Fall eine Instanz eines FB. Der Inhalt und struktuelle Aufbau ist allerdings in beiden Fällen identisch.

Michael

Hast du dir den Rückgabewert des BLKMOV-Aufrufs schonmal angesehen?
Vielleicht baut der TIA Compiler seit neuestem unterschiedliche Datentypen in den Any-Pointer ein. Bisher wurde eine Struktur wenn ich mich recht erinnere im Any-Pointer immer in eine Anzahl vom Datentyp Byte umgesetzt. Wenn die Datentypen oder die Längenangabe im Any-Pointer ungleich sind, schlägt das Kopiern fehl. Evtl. werden auch die Strukturen in unterschiedlicher Größe erkannt. Das sollte aber beides über den Rückgabewert entsprechend gemeldet werden.

Der BLKMOV kopiert ja, nur leider zur falschen Adresse. Da sollte der BLKMOV-Rückgabewert 0 sein.

Ich vermute, daß das TIA wie bei dem anderen Optimierungs-Bug nicht den Wert der Variablen #index benutzt, sondern den Wert einer anderen Variablen, von der der Compiler glaubt, die hätte den selben Wert wie #index.

Harald

Der Rückgabewert war in beiden Fällen null. Daran kann ich mich noch erinnern. Der Kopiervorgang läuft auch problemlos - nur halt zurück an die falsche Adresse.
Ich hatte nur Glück im Unglück, weil die Temperaturüberwachung in einer anderen Funktion läuft - und die hatte angeschlagen. Ansonsten hätte ich das wahrscheinlich nicht einmal gemerkt und mir die Anlagen zu klump gefahren.

Michael