ILC-3xx-Stringlaenge nicht mehr konsistent (angezeigte Laenge <> belegter Speicher)

Status
Für weitere Antworten geschlossen.

dfIas

Level-1
Beiträge
19
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
ILC-3xx-Stringlaenge nicht mehr konsistent (angezeigte Laenge <> belegter Speicher)

Stringlaengen auf ILC-3xx-Devices (ARM_L_40) koennen zwar nach wie vor per "string (n)"-Anweisung angepasst werden und belegen dementsprechend den Arbeitsspeicher (Struktur bestehend aus max. Laenge, aktueller Laenge, der variablen Zeichenkette selbst plus einer Extra-Null am Ende). Die max. Laenge in der String-Struktur steht allerdings beim aktuellen PC WORX (6.30.1914) nunmehr konstant auf 0, was der Default-Laenge von 80 Zeichen entspricht (Bias = 80 (!) bei der ILC 3xx, bei ILC 1xx wird die Laenge ohne Bias angegeben).
Die Visualisierung (z. B. Webvisit) kann nun bei kurzen Strings den Speicher dahinter ueberschreiben - mit entsprechenden Folgen. Auch beim Schreiben einer Struktur mit Nicht-Standard-Strings in eine Datei wird dieses Fehlverhalten offenbar. Bei laengeren Strings ist vorher Schluss, was ueber 80 hinausgeht, bleibt als Leiche im Speicher liegen. So oder so fatal. Vor einiger Zeit wurde die Laenge noch korrekt eingetragen, z. B. mit einer -37 bei 43 Zeichen langen Strings.
Bei welchem der letzten PC-WORX-Updates sich dieser Fehler eingeschlichen hat, kann ich nicht sagen, muesste gefuehlt etwa in den letzten zwei Jahren passiert sein. (Solange hatte ich nicht mehr mit ILC-3xx-Geraeten zu tun, wäre bestimmt aufgefallen. Bei den ILC 1xx ist auch noch alles i. O. Leider sind Daten zwischen 1xx und 3xx durch diesen 80er-Bias (mal mit, mal ohne) nicht direkt austauschbar, aber mit dem aktuellen Bug laeuft nun nicht mal mehr die Visualisierung ohne Absturzgefahr.)
 
Hallo dfIas,

vielen Dank für die Fehlerbeschreibung, um das Verhalten zu prüfen benötige ich Informationen, wo du die einzelnen Eigenschaften der String Struktur eingelesen hast.

Ich habe unter PCWorx 6.30.1914 ein Projekt mit ILC 390PN angelegt und ein String-Datentyp mit einer Zeichenlänge von 200 (Byte) definiert, anschließend wurde eine "NewVar1" PDI-Variable mit diesem Datentyp angelegt. Als Ergebnis wurde eine csv-Datei mit folgendem Inhalt erzeugt:

Unbenannt.JPG

In dieser Datei wird die definierte (max.) Zeichenlänge der String-Variable richtig angegeben.

Ich würde das Verhalten anhand deiner Erfahrungen gerne näher untersuchen, bitte melde dich unter unten stehender Support-Nummer.

Vielen Dank!

Gruß Eduard
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
ILC-3xx-Stringlaenge nicht mehr konsistent (angezeigte Laenge <> belegter Speicher)

Hallo Eduard,
die Variable wird im Speicher auch schon nach wie vor in der richtigen Größe angelegt. Nur enthält das Strukturelement "String-Länge" (signed short) selbst nicht mehr die korrekte Angabe. Bei den 3xx-Controllern müsste dort bei einer Länge von 200 Zeichen eine 120 erscheinen (wegen des 80er Offsets).
Allerdings benutze ich aus Platzgründen nur noch Strings mit weniger als 80 Zeichen, speziell 11, 23 und 43 Zeichen (4*n-1 erzeugt keinen Verschnitt, daher die merkwürdigen Längen). In diesen Fällen müsste die biasbezogene Längenangabe negativ ausfallen, also -69 (0xfffb), -57 (0xffc7), -37 (0xffdb). Stattdessen bekomme ich jetzt dort nur noch jeweils 0x0000.
Möglich, dass der Fehler nur bei kürzeren Strings als 80 Zeichen auftritt und der Struktureintrag gegen Null geclippt wird. Eine einfache Diagnose besteht darin, einen String in eine Datei zu schreiben und diese dann mit einem Hexviewer zu betrachten. In meinem Fall kann ich auch mit WebVisit einen kurzen String mit Überlänge befüllen, was sich dann darin äußert, dass die Inhalte der dahinter liegenden Variablen zerstört werden.
Ich werde nochmal selbst den Fall untersuchen, da ich auch Strukturen aus einer Datei lese und in den SPS-Speicher schreibe. Es werden hier beide Richtungen unterstützt. (Ich war mir bislang allerdings sicher, dass ich die Datei per SPS erzeugt und dann analysiert hatte und nicht umgekehrt. Und eine Länge 80 (biasbezogen 0) benutze ich sonst nirgends, sondern nur die oben erwähnten.)
Gruß
 
Ich habe das Problem gerade nochmal mit einer 350-ETH/M (3.95A.6) durchgespielt, der Fehler ist reproduzierbar. Das gesamte Datensegment steht zum Programmstart faelschlich auf Null. Ich werde den Test noch mit einer 350 PN und einer 370 PN wiederholen. Ggf. spielt die F/W-Version hier ihre Rolle, falls das enthaltene OS fuer die (fehlende) Variablen-Initialisierung mitverantwortlich ist.
Gruss
Kay
 
Zuletzt bearbeitet:
Hallo Kay,

ich kann den beschriebenen Fehler nicht reprodzieren und würde gerne meine Testergebnisse mit deinen vergleichen:

1. Ich habe für den Test folgendes Testprogramm implementiert (Anzahl der ASCII-Zeichen = 11, Stringlänge = 11+5 = 16):



2. Anschließend wurden die Textdateien erzeugt und mit HexEditor analysiert:





Ergebnisse:
Biasbezogene Längenangabe= 0xFFBB = -69 (-80+11)
Zeichenlängenangabe =0B =11

Gruß Eduard
 

Anhänge

  • TestProgram.jpg
    TestProgram.jpg
    40,9 KB · Aufrufe: 17
  • ILC350PN.JPG
    ILC350PN.JPG
    70,1 KB · Aufrufe: 17
  • ILC390PN.JPG
    ILC390PN.JPG
    73,8 KB · Aufrufe: 14
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
ebenfalls wurde die Stringlänge von 220 Zeichen getestetet:

Für den Test wurden verwendet:
- PCWorx 6.30.1914 und ILC390 PN V 3.98 J.6
- PCWorx 6.30.1914 und ILC350 PN V 3.98 F.6

Testergebnisse:
Biasbezogene Längenangabe= 0x008C = 140 (-80+220)
Zeichenlängenangabe = 0xDC=220

ILC350_220.JPG


ILC390_200.JPG
 
Zuletzt bearbeitet:
FILE_READ-Problem mit ILC-3xx (Titel geaendert!)

Vielen Dank für die vielen Bemuehungen!
Ich habe das gleiche Problem auch bei der 350 PN. Allerdings weiß ich jetzt den genauen Grund für den komplett mit Null beschriebenen Speicher: Der Funktionsblock FILE_READ initialisiert bei den ARMs das Target, auch wenn keine oder eine leere Datei zum Lesen geoeffnet wird! Dort liegt also der Fehler.
Bei den eCLRs benutze ich den gleichen Aufruf, dort bleibt bei erfolglosem FILE_READ der Target-Speicher verschont - so, wie es sein sollte.
Gruss
Kay
 
Zuletzt bearbeitet:
Hallo Kay,

Danke für dein Feedback,

ich möchte gerne dieses Verhalten untersuchen, kannst du mir bitte deinen Weg der Nachstellung näher erklären bzw. Screenshots zum Testprogramm und Ergebnissen hochladen?

Ich habe das gleiche Problem auch bei der 350 PN. Allerdings weiß ich jetzt den genauen Grund für den komplett mit Null beschriebenen Speicher: Der Funktionsblock FILE_READ initialisiert bei den ARMs das Target, auch wenn keine oder eine leere Datei zum Lesen geoeffnet wird! Dort liegt also der Fehler.
-> Der FB FILE_OPEN versucht eine Datei zu öffnen, falls die noch nicht vorhanden ist wird eine erzeugt und geöffnet. Anschließend wird an FB FILE_READ ein Handle übergeben, somit sollte immer auf eine existierende Datei zugegriffen werden.

Bei den eCLRs benutze ich den gleichen Aufruf, dort bleibt bei erfolglosem FILE_READ der Target-Speicher verschont - so, wie es sein sollte.
-> Wie wurde der Speicherinhalt ermittelt? Kannst du bitte Screenshot vom Testprogramm/Ergebnissen zusenden?

Ich habe ein Programm erstellt, bei dem eine neue Datei erzeugt und anschließend eingelesen wird. Der Stringbuffer enthällt keine Zeichenkette (siehe Screenshot unten).
SaveString0.JPG


Vielen Dank.
Gruß Eduard
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Eduard,
folgende Vorgehensweise bei mir:
1a) Eine (beim ersten Mal noch nicht vorhandene) Datei oeffnen; FILE_OPEN legt diese Datei dann mit Laenge Null an.
1b) FILE_READ aufrufen, dabei Target-Buffer auf eine Struktur zeigen lassen, die Strings ungleich 80 Zeichen enthaelt und Laengenangabe passend zur Struktur (von Hand berechnen, sizeof () gibt es nicht);
1c) File schließen
2a) Die nun vorhandene Datei erneut oeffnen;
2b) FILE_WRITE mit Target-Buffer auf selbige Struktur zeigen lassen, Laengenangabe wie zuvor, damit es passt;
2c) File schließen
Nun sollte die Datei vollstaendig aus Nullen bestehen - bei den ILC 3xx. Bei den ILC 1xx bleiben alle Daten korrekt erhalten, da dort das erfolglose FILE_READ nichts anrichtet.
Das Ganze geht auch mit bereits initialisierten Variablen (ungleich Null), die sind nach dem erfolglosen FILE_READ allesamt mit geloescht.
Gruß, Kay
 
Noch zu meinem Programmlayout: Ich benutze eine Handvoll Datenbanken in jeweils fester Groesse, bestehend aus Feldern mit Zahlen und Texten. Diese werden zum Programmstart vom Filesystem gelesen und somit auf den aktuellen Stand gebracht. War das Lesen nicht erfolgreich (erkennbar an der zurueckgegebenen Laenge), werden den Strukturelementen Anfangswerte zugewiesen. Letzteres wird auch entsprechend (einmalig) durchgefuehrt, da der Lesefehler korrekt gemeldet wird. Sowie es durch Interaktionen Aenderungen an den Datenbanken gibt, werden die Dateien aktualisiert. Diese Dateien hole ich dann per FTP in ein (Windows-) Parametrierprogramm zur weiteren Bearbeitung. Die Dateien koennen dann auch per FTP zuruecktransferiert werden. Da ich zwischen ILC 1xx und ILC 3xx wechsle, werden die Stringlaengenangaben dort allerdings immer wieder auf das jeweilige Format (eCLR bzw. ARM) angepasst. Somit kann ich quasi die fehlerhaften Laengenangaben reparieren. Das Problem nach der allerersten Inbetriebnahme ohne bzw. mit leeren Dateien (solange keine Aenderungen an den DBs vorgenommen wurden) bleibt aber. Lesen einer leeren Datei darf m. E. keinen Speicher ueberschreiben. Das gibt es bei keinem Betriebssystem, das ich kenne.
 
Hallo Kay,

Danke für die ausführliche Beschreibung, ich werde das Verhalten untersuchen und gebe dir sobald wie möglich einen Feedback.

Gruß Eduard
 
Hallo Eduard,
gibt es inzwischen ein Update oder wird der Bug zum festen Bestandteil der ILC-3xx-Reihe?
Gruß
Kay
 
Hallo, hallo ...
Muss den Thread nochmal nach oben holen. Es gibt immer noch keinen Fix, oder? Wo ist das Problem, das Löschen des Zielspeichers einfach mal aus dem Code zu entfernen? Gehört dort nicht hin. Schade, dass sich hier keiner mehr meldet ...
 
Hallo,
mit einem Fix ist nach über drei Jahren nicht mehr zu rechnen, oder? Wäre mit dieser Vorlage so einfach gewesen - wieder einmal nur Use-as-is-Mentalität. Eduard scheint untergetaucht und kein Kollege springt ein.
 
Hallo Kay,
nach Informationen aus unserer Entwicklung ist das Problem mit der aktuellen PC Worx-Version sowie der neusten Firmware des ILC (3.99) behoben.
Leider ist die Anfrage hier etwas länger unbearbeitet liegen geblieben. Ich hoffe der Fehler kann jetzt behoben werden.
Gerne kannst du dich auch telefonisch bei uns melden.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben