Mir ist heute eine eigenartige Sache untergekommen:
1. CPU 317-2PN/DP, 1 Jahr alt
2. SCL-Baustein (FC), der Strings umkopiert und zwar aus einem Datenbaustein in einen anderen. Dazu gibt es einige IN-Strings und einige OUT-Strings, dort werden außen die Strings angelegt
und bei Aufruf des FC wird umkopiert:
template_db := template;
send_key_01_db := send_key_01;
send_value_01_db := send_value_01;
send_key_02_db := send_key_02;
send_value_02_db := send_value_02;
send_key_03_db := send_key_03;
send_value_03_db := send_value_03;
...
SCL: generiert vom SCL Übersetzer Version: SCLCOMP K05.03.08.00_01.05.00.01 release
3. Das hat in einer alten Anlage 10 Jahre funktioniert Vipa Speed7, in einer neueren Anlage läuft die selbe Software seit 3 Jahren (auch 317). Nun haben wir die VIPA gegen eine 317
getauscht und es läuft seit mehreren Monaten.
Heute ab 10 Uhr ging mitten im Betrieb, während der Produktion plötzlich nichts mehr.
Nach langer Suche habe ich dann festgestellt, dass einige (nicht alle!!!) Strings von obigem SCL-Baustein offensichtlich nicht mehr umkopiert werden.
In den betreffenden Teilen des Ziel-DB stand alles auf hex00, also auch die max. String-Länge, die String-Länge und die Chars. Der Quell-DB enthielt komplett alle korrekten Daten.
Nun sind doch Strings in DB normalerweise initialisiert, also zumindest die max. Stringlänge sollte immer darin stehen oder sehe ich das falsch?
Für mich sieht das so aus, als ob ein Teil des DB plötzlich keinerlei Daten mehr enthielt, also auch die max. Stringlänge nicht.
Das hätte dann evtl. den gleichen Effekt, wie bei nicht initalisierten Temp-Strings, die werden ja auch nicht umkopiert.
Zusatz: SCL erzeugt Code, der nicht den Block_Move nutzt. Leider kann ich den erzeugten Pseudo-AWL-Code nicht posten, er ist so lang, dass der Editor meldet, "zu viele Zeilen". Ich kann durchscrollen,
aber nichts kopieren. :-)
Hab ich einen Denkfehler, muß ich auch die DB-Strings immer erst initialisieren, das wäre echt komisch, dann das geht seit Jahren in vielen meiner Programme völlig klaglos ohne Initialisierung von DB-Strings.
PS: Ich hab dann als schnelle Lösung einfach die max. Länge, eine tatsächliche Länge und ein paar Chars auf die entsprechenden DB-Bytes kopiert, seitdem scheibt er dort wieder korrekt Daten hin. :roll:
1. CPU 317-2PN/DP, 1 Jahr alt
2. SCL-Baustein (FC), der Strings umkopiert und zwar aus einem Datenbaustein in einen anderen. Dazu gibt es einige IN-Strings und einige OUT-Strings, dort werden außen die Strings angelegt
und bei Aufruf des FC wird umkopiert:
template_db := template;
send_key_01_db := send_key_01;
send_value_01_db := send_value_01;
send_key_02_db := send_key_02;
send_value_02_db := send_value_02;
send_key_03_db := send_key_03;
send_value_03_db := send_value_03;
...
SCL: generiert vom SCL Übersetzer Version: SCLCOMP K05.03.08.00_01.05.00.01 release
3. Das hat in einer alten Anlage 10 Jahre funktioniert Vipa Speed7, in einer neueren Anlage läuft die selbe Software seit 3 Jahren (auch 317). Nun haben wir die VIPA gegen eine 317
getauscht und es läuft seit mehreren Monaten.
Heute ab 10 Uhr ging mitten im Betrieb, während der Produktion plötzlich nichts mehr.
Nach langer Suche habe ich dann festgestellt, dass einige (nicht alle!!!) Strings von obigem SCL-Baustein offensichtlich nicht mehr umkopiert werden.
In den betreffenden Teilen des Ziel-DB stand alles auf hex00, also auch die max. String-Länge, die String-Länge und die Chars. Der Quell-DB enthielt komplett alle korrekten Daten.
Nun sind doch Strings in DB normalerweise initialisiert, also zumindest die max. Stringlänge sollte immer darin stehen oder sehe ich das falsch?
Für mich sieht das so aus, als ob ein Teil des DB plötzlich keinerlei Daten mehr enthielt, also auch die max. Stringlänge nicht.
Das hätte dann evtl. den gleichen Effekt, wie bei nicht initalisierten Temp-Strings, die werden ja auch nicht umkopiert.
Zusatz: SCL erzeugt Code, der nicht den Block_Move nutzt. Leider kann ich den erzeugten Pseudo-AWL-Code nicht posten, er ist so lang, dass der Editor meldet, "zu viele Zeilen". Ich kann durchscrollen,
aber nichts kopieren. :-)
Hab ich einen Denkfehler, muß ich auch die DB-Strings immer erst initialisieren, das wäre echt komisch, dann das geht seit Jahren in vielen meiner Programme völlig klaglos ohne Initialisierung von DB-Strings.
PS: Ich hab dann als schnelle Lösung einfach die max. Länge, eine tatsächliche Länge und ein paar Chars auf die entsprechenden DB-Bytes kopiert, seitdem scheibt er dort wieder korrekt Daten hin. :roll: