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



## dfIas (26 Oktober 2017)

*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 "-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.)


----------



## Phoenix Contact (2 November 2017)

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:




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


----------



## dfIas (2 November 2017)

*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ß


----------



## dfIas (3 November 2017)

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


----------



## Phoenix Contact (3 November 2017)

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


----------



## Phoenix Contact (3 November 2017)

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


----------



## dfIas (3 November 2017)

*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


----------



## Phoenix Contact (6 November 2017)

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).




Vielen Dank.
Gruß Eduard


----------



## dfIas (6 November 2017)

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


----------



## dfIas (6 November 2017)

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.


----------



## Phoenix Contact (7 November 2017)

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


----------



## Phoenix Contact (14 November 2017)

Hallo Kay,

das Verhalten ist nachgestellt und wird von der Entwicklung verifiziert. Ich gebe dir einen Feedback, sobald ich eine Antwort erhalte.

Gruß Eduard


----------



## dfIas (12 März 2018)

Hallo Eduard,
gibt es inzwischen ein Update oder wird der Bug zum festen Bestandteil der ILC-3xx-Reihe?
Gruß
Kay


----------



## dfIas (3 Juni 2018)

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 ...


----------



## dfIas (14 November 2018)

Alle halbe Jahre wieder ...? Fehler aussitzen? Ich warte immer noch ...!


----------



## dfIas (23 April 2021)

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.


----------



## Phoenix Contact (26 April 2021)

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.


----------

