TIA Export/Import Daten auf/von CSV Momeory-Card SPS

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein Kunde hat eine Library zur Typverwaltung. Darin verwendet er:

sfbExportConfigToCSV
sfbExportDataToCSV
sfbImportConfigFromCSV
sfbImportDataFromCSV

aus dem SPS-Programm heraus.

Wenn ich ein Rezept ecportiere landen Config und Daten in 2 CSV-Dateien auf der Memory-Card der SPS. Alles korrekt.
Wenn ich die eben gerade exportierten Dateien wieder importieren will (gleiche Einstellungen, nichts geändert), bekomme ich für die Daten-CSV die Fehlermeldung

80B2 - Struktur des Rezept-Datenbausteins und CSV-Datei stimmen nicht überein: Die CSV-Datei enthält zu wenige Felder.
Hinweis: Die Zeilen der CSV-Datei werden eine nach der anderen gelesen. Falls eine Zeile der CSV-Datei mehr Zeichen enthält als von der CPU erwartet, wird der Fehlecode W#16#80B2 zurückgegeben, egal wie viele Felder erkannt wurden.

Ich kann keinen Fehler entdecken, der o.g. entspricht.
Hat jemand einen Tip dazuz?

TIA V16
1516TF-3 PN/DP

 

[PN/DP]

Ein Kunde hat eine Library zur Typverwaltung. Darin verwendet er:

sfbExportConfigToCSV
sfbExportDataToCSV
sfbImportConfigFromCSV
sfbImportDataFromCSV

Ist das was selbst-programmiertes oder was von Siemens oder einem namhaften Hersteller, der die Lib entwickelt und auch pflegt?
Vielleicht passt die Version der Import-Bausteine nicht zueinander oder nicht zur Version der Export-Bausteine? Oder es sind einfach nur Bugs drin?
Hast Du Dir mal die csv-Dateien mit einem normalen Texteditor (z.B. Notepad) angesehen?

Harald

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Anzahl der Felder ist begrenzt, ebenso die Anzahl der Zeichen für die Kopfzeile.
Möglicherweise rührt das Problem daher.

 

[Ralle]

Das ist eine Lib eines großen Konzerns, wir müssen für deren Maschinen auch deren Framework nutzen. An die Macher kommt man eher nicht ran bzw. die sind extrem hartleibig, Bugs zu fixen und Änderungen umzusetzen. Ich hab das vor Jahren mit denen versucht und aufgegeben. Ich nutze das Zeug, versuche für mich zu fixen, was geht, aber ich versuche nicht mehr, mit denen zu kommunizieren, sinnlose Zeitvergeudung. Die Lib ist sehr sauber aufgebaut inkl. HMI-Bild. Da gibt es zwar auch ein paar Fehlerchen, aber das scheint mit dem Panel zu tun zu haben. Die sfb heißten RecipeExport und Recipeimport und ich denke, die sind in der FW der SPS hinterlegt.

@NBerger
Die Rahmendaten kommen aus der LIB (Konstanten), aber die kann ich mal kleiner machen. mich irritiert besonders, dass der Export prima klappt und aus meiner Sicht fehlerlos ist. Die CSV werden erstellt und sehen korrrekt aus. Gleiche unveränderte CSV kann ich bei der Config (kleiner + kürzer) einlesen, bei den Daten allerdings nicht.

Noch ein Fehler, den ich nciht erklären kann:

Comfort Pro Panel:
Im Script:

nLeft = 50         '(HmiRuntime.ActiveScreen.Width - 560) / 2
nTop = 50                    '(HmiRuntime.ActiveScreen.Height - 230) / 2
ShowPopupScreen "POP_TypeMessage", nLeft, nTop, hmiOn, hmiAnimationOff, hmiMedium

Das ruft ein PopUp an berechneten Stelle (jetzt fest 50 auf.
Wenn ich die 50 rausnehme und die Berechnung mit ActiveScreen wieder einnehme, geht das bei mind. 25% der Aufrufe schief. Das führt dann dazu, dass das Popup nicht aufgeht, aber irgendwo im Hintergrund zu hängen scheint, denn kein weiteres Popup ist in Folge mehr aufrufbar. Abhilfe schafft nur ein Neustart des HMI. Mit 50 fest geht es problemlos immer.

 

[Larry Laffer]

Hallo Ralle,
das von dir beschriebene Problem hatte ich auch schon das eine oder andere Mal.
Nach meiner Beobachtung hat das HMIRuntime-Objekt den ActiveScreen nicht immer gesetzt. Wenn du hier allerdings den Screen namentlich angibst sollte es funktionieren.

Gruß
Larry

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich halte das irgendwie für einen Bug.

Ich hab zwei Rezeptdateien:

1. eine Config-Datei: Arry of Type
2. eine Daten-Datei: Array of Type with Array of Type, also geschachtelt.

Die erste kann ich problemlos ex- und importieren, die 2. nur exportieren (korrekt) aber nicht importieren.

 

[Larry Laffer]

Wie sieht denn die 2.Datei als CSV-Datei aus ?
Ich denke aber mal, dass du Recht hast und die Import-Routine mit dem Type im Type ein Problem beim de-serialisieren hat. Es wird also wohl ein Bug sein (oder etwas, dass nicht bis zum Schluss getestet worden ist).
Etwas Ähnliches hatte ich mir mal unter .Net gemacht und da war es schon ein bisschen tricky ...

Gruß
Larry

 

[Heinileini]

Ich hab zwei Rezeptdateien:

1. eine Config-Datei: Array of Type
2. eine Daten-Datei: Array of Type with Array of Type, also geschachtelt.

Die erste kann ich problemlos ex- und importieren, die 2. nur exportieren (korrekt) aber nicht importieren.

Die Schachtelung ist aber meines Wissens keine Eigenschaft, die dem CSV-Format "angeboren" ist.
Das liest sich so, als wenn die ConfigDatei eingelesen werden muss, um den Inhalt der zugehörigen DatenDatei wunschgemäss interpretieren zu können.
Quasi als BedienungsAnleitung für die Prozedur, die das Einlesen und Zuordnen der Daten übernimmt.
Wie kannst Du denn beeinflussen, dass für das Einlesen der Daten die Informationen der dazu passenden ConfigDatei benutzt werden?

Kannst Du denn beurteilen, dass die Daten wirklich korrekt exportiert werden (entsprechend dem vermutlich in der ConfigDatei abgelegten Schema) oder sehen die exportierten Daten vielleicht nur oberflächlich betrachtet gut und plausibel aus?

Kannst Du mal andeuten, worum es bei der Schachtelung konkret geht?

PS:
'Array of Type with Array of Type' klingt verdächtig nach Rekursion ... aber das ist hoffentlich nicht gemeint?

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Heinileini

Nein, keine Rekursion
Ja, ich weiß, welche Daten im DB stehen und sehe, was in der CSV ankommt. Das paßt gut. Nur zurücklesen geht nicht.

Es ist ein Array aus UDT, und diese UDT enthält wiederum ein array aus einem anderen UDT. Nichts ungewöhnliches. Aber ich bin nun sicher, dass Das nicht zurückgelesen werden kann und halte es für einen Bug von Siemens. Wäre aber auch nicht ganz leicht zu importieren.

Ich hab einen Workarround gefunden:

Vor dem Export mit serialize in ein Array of Byte wandeln, nach dem Import mit deserialize wieder zurückwandeln.
Das klappt gut hat aber 3 kleine Unschönheiten:
1. die CSV-Datei wird für Menschen so gut wie unlesbar.
2. die CSV-Datei wird sehr groß (bei mir sind 150*40 String[50] im DB, in der Datei sind es dann über 5 MB.
3. Export und Import dauern auf einer 1516TF 5-8 Sekunden.

Aber damit kann ich locker leben.

PS: Die Maschine läuft gut weiter beim Import/Export, also die Zykluszeit wird sicher erhöht, aber anscheinend nicht über Gebühr.

 

[Ralle]

Das Verhalten ist ein Firmware-Bug (Ich hab derzeit V2.8 in der SPS) soll mit V2.9 behoben werden.
Abhilfe: Downgrade auf V2.6.1 oder eben mein Workarround.