Empfehlung für Messwerterfassungssystem mit >100 analogen Eingängen

[Devil120]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke dir erstmal
Ich verstehe nur nicht, wieso er aus einer 0 im Byte (also NULL) ein Leerzeichen macht. Ich kann diese Nullen ja auch nicht durch "Nichts" ersetzen. Immer wieder was neues

 

[PN/DP]

        fbFilePuts( sNetId := sNetId, hFile := hFile, pWriteBuff := ADR(sCSVField_array),cbWriteLen :=[COLOR="#FF0000"]SIZEOF[/COLOR](sCSVField_array), bExecute := TRUE );

 fbWriter(pBuffer := ADR(sCSVField_Array), cbBuffer := [COLOR="#FF0000"]SIZEOF[/COLOR](sCSVField_Array), putValue := sCSVField '', pValue := 0, cbValue := 0 ,

Du hast einen Puffer sCSVField_array mit 1000 Bytes deklariert und danach (hoffentlich) Deine Strings lückenlos hintereinander in das Byte-Array kopiert. Dabei wird der Byte-Puffer allerhöchstwahrscheinlich nicht voll belegt, sondern es bleiben unbeschriebene Bytes am Ende übrig. Danach schreibst Du (mit fbWriter oder fbFilePuts oder beiden ) das komplette Array inklusive der nicht belegten Bytes am Ende in die Datei.
Du solltest nur den tatsächlich von Nutzdaten/Strings belegten Teil des Arrays in die Datei schreiben. Dazu musst Du Dir beim Zusammenbasteln merken wie lang der Gesamtstring ist, oder nachträglich die Gesamtlänge ermitteln (z.B. so), und bei fbWriter/fbFilePuts anstatt der gesamten Puffergröße cbBuffer := SIZEOF(sCSVField_Array) nur die tatsächliche Länge angeben.

Irgendwie finde ich in Deinem gezeigten Code nicht, wo Du in das Array sCSVField_Array schreibst und wie Du den laaangen String zusammenbastelst ...

Ein Byte mit dem Inhalt 0 ist nicht leer, sondern es steht der Wert 0 drin. Daß diese 0 für Dich wie ein Leerzeichen aussieht liegt an dem Programm, was Dir die 0 als Leerzeichen präsentiert.

            sCSVField_array := [COLOR="#FF0000"]null; (* sCSVField_array "Löschen"*)[/COLOR]

Ich kenne Twincat nicht, doch ich vermute, auch dies tut nicht das was Du erwartest - ich glaube nicht daß dabei alle Bytes in dem Array auf 0 initialisiert/gelöscht werden. Ich hätte sogar erwartet, daß der ST-Compiler diese Anweisung anmeckert ("null" sollte nur an Pointer zugewiesen werden können) ...

Harald

 

[Devil120]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Harald,

die Daten schreibe ich lückenlos in den BytePuffer (sCSVField_Array). Diese werden in der FOR-Schleife im Funktionsbausteinaufruf von fbWriter() hineingeschrieben (siehe Code).
Das mit der Abfrage der geschriebenen Bytes hatte ich gestern schon versucht, in dem ich abgefragt habe, ob die ein Byte nicht den Wert 0 trägt und dann einen Zähler hochzählen lassen habe. Das Ergebnis war aber sehr verwirrend, da immer nur das 1. Datenfeld geschrieben wurde, was sehr unlogisch ist. Ich versuche mit heute nochmal weiter daran.

Zum Schreiben verwende ich den FB_FileWrite. Der FB_FilePuts geht glaube ich nur für Strings die geschrieben werden sollen und nicht für Bytes.

                  ....

                    FOR nSpalte := 1 TO ANZAHL_SPALTEN BY 1 DO
                    
                                        
                    sCSVField := STRING_TO_CSVFIELD(database[ nSpalte, nZeile ], TRUE ); 
                    
                    (* Add new field to the record buffer *)
                                
                    
                    fbWriter(pBuffer := ADR(sCSVField_Array), cbBuffer := SIZEOF(sCSVField_Array), putValue := sCSVField'', pValue := 0, cbValue := 0,
                            bCRLF := ( nSpalte = ANZAHL_SPALTEN ) );(* bCRLF == TRUE => Neuer Datensatz (Zeile)*)
                    IF fbWriter.bOk THEN
                        fbWriter.eCmd := eEnumCmd_Next;(* Schreibe den nächsten Feldwert *)
                    ELSE(* Error *)
                        step := 100;
                        RETURN;
                    END_IF
                    
                    END_FOR(* FOR Spalte 0... Anzahl an Spalten *)

                  .....

EDIT: Ich war wohl gestern zu verpeilt. Habe die WHILE-Schleife zum Zählen der geschriebenen Bytes integriert und jetzt läuft es astrein. Vielen herzlichen Dank!

 

[Devil120]

Es hört nicht auf...

Jetzt habe ich folgendes sehr merkwürdiges Problem mit der CSV-Datei. Auf dem Beckhoff Rechner (Windows 10 Embedded) ist das Layout der CSV gut. Bedeutet - Kopfzeile, mit darauffolgenden Zeilen der Messwerte.

Datum;Uhrzeit;...;Druck1/bar
2020-10-07;10:06:54,405;...;0,9906308
2020-10-07;10:06:54,415;...;0,9918516
2020-10-07;10:06:54,425;...;0,994293
2020-10-07;10:06:54,435;...;0,9955138
...
..
.

Packe ich die CSV-Datei auf meinen Laptop (Windows 10 Pro) wird diese so geöffnet:

Datum;Uhrzeit;...;Druck1/bar


2020-10-07;10:06:54,405;...;0,9906308


2020-10-07;10:06:54,415;...;0,9918516


2020-10-07;10:06:54,425;...;0,994293


2020-10-07;10:06:54,435;...;0,9955138


...

..

.

Verschiebe ich sie wieder auf den Embedded PC, passt es wieder. Liegt das an der Windows-Version, dass zusätzliche Leerzeilen eingefügt werden? Kann ich das irgendwie verhindern oder muss ich das bei dem Import in Matlab, Excel, etc. beachten und die Leerzeilen rausfiltern?

Meine Kollegen haben so etwas auch noch nicht gesehen...

Danke euch schonmal!!

 

[Heinileini]

Das liegt vermutlich daran, dass unterschiedliche Programme die ZeilenEndeZeichen unterschiedlich auslegen.
Vermutlich steht in der Datei ein CR (hex 0D, dez 13) und ein LF (hex 0A, dez 10) und das eine Programm wertet beide Zeichen für sich als ZeilenSchaltung aus und das andere nur eines davon bzw. nur eine bestimmte Reihenfolge der beiden Zeichen (CR LF oder LF CR)?

 

[Devil120]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also in beiden Fällen wird mit dem Editor als Textdatei geöffnet. Excel beispielsweise ließt die zusätzlichen Leerzeilen aber auch ein.
Wie kann ich mir die Binärdaten anzeigen lassen, sodass ich schauen kann was für ein Zeilenumbruch im Hintergrund drin steht?

 

[PN/DP]

Das sieht so aus als ob Du als Zeilenschaltung am Zeilenende nicht die richtige CRLF-Zeichenfolge verwendest. Schau Dir mal Deine csv-Datei als Hex-Dump an.
Es muß so sein:
CRLF = 0x0D + 0x0A = '$0D' + '$0A' = '$R' + '$N' = '$R' + '$L'

Hast Du Dir schon mal dieses Beispiel angesehen?
Beispiel: Schreiben/lesen einer CSV-Datei

PS: Heinrich war schneller

Harald

 

[Devil120]

@PN/DP alias Harald

Du bist Top! Vielen Dank!! Hatte am Ende der Zeile eine 13 und eine 10 drin stehen. Habe jetzt die 13 in eine 10 gewandelt und die zweite 10 in eine 0. War einfach ein Zeilenumbruch + ein Carriage Return. Ein Zeilenumbruch reicht ja
Nochmals Danke!

EDIT: Stimmt, Heinileini war schneller, habe ich leider übersehen xD Auch dir vielen herzlichen Dank!!!

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie kann ich mir die Binärdaten anzeigen lassen, sodass ich schauen kann was für ein Zeilenumbruch im Hintergrund drin steht?

z.B. Notepad++ mit Hex Editor Plugin

Harald

 

[PN/DP]

Hatte am Ende der Zeile eine 13 und eine 10 drin stehen. Habe jetzt die 13 in eine 10 gewandelt und die zweite 10 in eine 0. War einfach ein Zeilenumbruch + ein Carriage Return. Ein Zeilenumbruch reicht ja

Das war doch eigentlich richtig. "Internationaler Standard" seit Jahrzehnten, und so auch von Beckhoff empfohlen, ist die Bytefolge 0x0D + 0x0A (13 +10).
Wenn jetzt irgendein neumodisches Programm oder neumodisches Windows diese Zeichenfolge als 2 Zeilenschaltungen interpretiert, dann muß man sich bei dem Programmhersteller oder Microsoft beschweren... vorausgesetzt, bei Dir steht wirklich 0x0D 0x0A in dieser Reihenfolge drin. Oder wird in dem Windows 10 die csv-Datei irgendwie (unsichtbar?) "intelligent" markiert als ob sie einen bestimmten Zeichencode-Standard verwendet? Oder kann man die Interpretation von 0D 0A in Windows 10 irgendwo einstellen?

Harald

 

[Devil120]

Also - die letzten beiden Bytes (die nicht 0 sind) im Bytepuffer waren definitiv 13 und 10. Das Windows auf dem embedded PC mit dem dortigen Editor fand das ja auch gut. Kann natürlich sein, dass das aktuelle Windows 10 Pro da was anderes interpretiert oder sonst was passiert. Ich weiß es nicht.
Mit nur der 10 am Ende können jedenfalls beide Windows-Versionen die Daten richtig im Editor darstellen.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kennt ihr den "EnterHaken"? So nannte mal ein Kollege den "KnickPfeil" auf der EnterTaste, der von oben nach unten verläuft und dann von rechts nach links.
Der senkrechte Teil symbolisiert die ZeilenSchaltung LF (Line Feed) und der waagerechte den WagenRücklauf CR (Carriage Return).
An den guten alten Fernschreibern gab's dafür getrennte Tasten, an etwas moderneren nur eine Taste, die aber beide Funktionen nacheinander auslöste.
Wenn CR und LF bzw. LF und CR direkt aufeinander folgen, ist die Wirkung im Endeffekt identisch. Und das ist der Ursprung allen Übels, das die beiden Zeichen CR und LF betrifft.
Wer braucht schon einen WagenRücklauf ohne ZeilenSchaltung, wenn er nicht dieselbe Zeile mehrmals beschreiben will (bis sie unleserlich wird)?
Warum die EnterTaste dann ausgerechnet dem Zeichen CR zugeordnet wurde und nicht dem Zeichen LF? Ein Dilemma mit "historischen" Hintergrund und eine Umsetzung von BedienungsKomfort, die ins Chaos geführt hat. Neu ist das Problem wirklich nicht. Im Gegenteil, die Kollegen, die das Problem noch nicht kennen, sind zu neu!

 

[PN/DP]

Bist Du ganz gaaanz sicher, daß Du nicht bei Dir die Reihenfolge 0D + 0A (13 + 10) vertauscht hast zu 0A + 0D (10 + 13)? Das kann ich nämlich mit Windows 10 nachvollziehen.

Ausgabe mit Windows Editor Notepad bzw. Excel:

Zeilenende   Windows 7 Pro/64   Windows 10 Pro/64         Windows Server 2016 /64   Excel 2010 /64
------------------------------------------------------------------------------------------------------------
[B]0D + 0A[/B]      Zeilenschaltung    Zeilenschaltung           Zeilenschaltung           Zeilenschaltung
nur 0A       ---                Zeilenschaltung           ---                       Zeilenschaltung
nur 0D       ---                Zeilenschaltung           ---                       Zeilenschaltung
0A + 0D      ---                mit Leerzeile dazwischen  ---                       mit Leerzeile dazwischen


--- = Ausgabe ohne Zeilenschaltung (alles in einer Zeile)

Da hat es wohl jemand gut gemeint und das Verhalten von Windows 10 an das schon lange existierende Verhalten von Excel angepasst.

Unabhängig davon: Auf der Zielplattform wird die csv-Datei vermutlich nicht mit dem Windows Texteditor Notepad geöffnet, sondern mit Excel oder einer App mit eigener Einlese-Routine (z.B. in VB). Ob VB/VBA/VBS unter Windows 10 auch ihr verhalten geändert haben weiß ich nicht (ich glaube eher nicht). Auch die HTML-Spezifikation sieht die Verwendung des Zeichenpaars 0D + 0A als "Line break" vor. Deshalb würde ich mich an den jahrzehntealten und empfohlenen Standard 0D+0A halten.

Harald