[Gelöst] DataPort-Komponente und Datenübertragungsproblem

[Lomat]

Hallo zusammen,

ich habe die DataPort-Komponenten von Sergey Bodrov installiert, um ein Spektrometer (Messgerät) an seinem COM-Port zu betreiben. So weit so gut: Die Kommunikation funktioniert grundsätzlich, die Einstellungen und die Datenverarbeitung stimmen. Es wird das erwartete Spektrum ausgeleisen. Allerdings sind 30% der Messwerte von Übertragungsfehlern betroffen, die sich in willkürlichen sogenannten Spikes äußern. Das Spektrum wird als String aus ca. 3600 Zeichen übertragen. Hierbei handelt es sich um 1600 UInt16-Variablen, wobei abwechselnd das Hi- und das Lo-Byte übertragen werden. Die Baudrate beträgt 3.000.000 bauartbedingt durch das Spektrometer. Bei meiner Datenverarbeitung habe ich wie gesagt keinen Fehler gefunden. Die nicht korrupten Zahlen machen Sinn. Die Software von Spektrometerhersteller auf Lab-View-Basis zeigt keinerlei Übertragungsfehler. Kurze Rückantworten, wie das Auslesen des Spektrometertys funktionieren auch bei meiner Software, aber wie gesagt, die Übertragung des Datenstrings nur unzuverlässig. Hat jemand eine Idee, woran die Probleme liegen könnten?

Ich habe auch schon SynapseVS probiert. Hier scheitert die Sache schon daran, dass TvsComPort keine so hohe Baudrate erlaubt.

Viele Grüße

Christoph

[NoCee]

Hallo,
was benutzt du für eine Schnittstelle?
Com-Port kann ja vieles sein. echte RS232, RS422/485-Karte, virtueller Com-Port von USB/Netzwerk usw.
Die angegebene Baudrate ist schon ordentlich. Da macht nicht jede Hardware mit.
Eine echte RS232 z.B. mit Sicherheit nicht.
Läuft die Software von Spektrometerhersteller auf Lab-View-Basis auf der gleichen Hardware?

Gruß
NoCee

[Winni]

Hi!

Wenn es nicht zur Beseitigung der Fehlerquelle hilft, dann dient es aber zur Erheiterung:

Ich hatte Probleme beim Auslesen der Daten einer Telefonanlage eines namhaften deutschen Herstellers. Im Handbuch stand, wie sie es gerne gehabt hätten. Aber:

Statt der dokumentierten 8 Bit wurden nur 7 Bit geliefert - Umlaute gab es nicht.
Und es stand viel Müll in den Daten.

Da half schließlich ein Blick in die ANSI-Tabelle:
Der Müll entstand, wenn das 8. Bit gesetzt war.
Und wann das gesetzt war, entschieden die Elektro-Götter.

Nach dem maskieren des 8. Bits klappte alles wunderbar.
Wenn auch nur mit 7 Bit.

Deutsche Wertarbeit.

Will sage: Die Fehler können auch dort liegen, woran man zuerst mal nicht denkt.

Winni

[Lomat]

Hallo nochmal und Nachtrag:

Es handelt sich um einen virtuellen com-Port über USB.

Viele Grüße

Christoph

[Lomat]

Hallo, hier ein paar neue Infos:

Das Problem liegt wohl daran, dass die Daten in Binärcode übergeben werden. Da die Komponente einen Null-terminierten String verwendet, ist dies der Todesstoß, da auch Nullen übertragen werden.

Gibt es eine Komponente, die stattdessen ein Array of Char oder Int8 verwendet?

Viele Grüße

Christoph

[Winni]

Hi!

Und was, wenn im HI byte oder im Lo byte ne Null steht???
Dann gibt's auch Ärger.

Du solltest die Daten nach Base64 umwandeln. Das ist für genau solch Fälle entwickelt worden.

Winni

[Lomat]

Hallo Winni,

so was ähnliches habe ich den Spektrometerhersteller auch schon vorgeschlagen. Antwort: Zu kompliziert und in Labview C oder Pyton geht es ja. Toll, soll ich jetzt in Lazarus eine Komponente auf Basis von Win-Api-Funktionen neu schreiben, habe ich mir gedacht. Die Frage ist, ob es auch einfacher geht. Über ein paar Tips, die nicht die Firmware eines Herstellers auf den Kopf stellt, wäre ich sehr dankbar, da letzteres ich will es mal so sagen, sehr anstrengend werden könnte.

Viele Grüße

Christoph

[six1]

Also ich habe mal bei gekaufter nrCom und auch bei TLazSerial nachgeschaut.
Da gibt es neben dem Empfang eines String ala "LazSerial1.ReadData" auch einen Zugriff auf einen Buffer.
Hiermit ist der Empfang eines Null Bytes gar kein Problem: "LazSerial1.SynSer.RecvBuffer()"

...oder habe ich dich missverstanden?

[Lomat]

Hallo six1,

ich habe zusätzlich noch SynapseVS installiert und das Paket enthält auch eine Com-Komponente. Die Fehler waren die gleichen. Ich habe jetzt mal nachgeforscht und komme auch auf SynSer.RecvBuffer(). Wenn ich hier auf den unveränderten Eingangspuffer Zugriff habe, habe ich wohl gewonnen. Was ich mich in dem Zusammenhang frage ist, ob diese Komponente wirklich frei ist. Ich habe in den heruntergeladenen Dateien keine Angaben zur Lizenz gefunden.

Viele Grüße und vielen Dank

Christoph

[Lomat]

...und noch eine entscheidende Frage:

Für die Funktion brauche ich die Größe bzw. den Füllstand des Eingangspuffers. Wie komme ich an diese Info?

VG Christoph

[six1]

gibt es für deine Übertragung so etwas wie ein Protokoll? (Startzeichen, länge, daten, Endekenner) oder so etwas?
Ansonsten kann man Daten auch mit Timeout am Ende der daten empfangen...

[Lomat]

Ja, die gibt es natürlich. Aber dafür muss ich ja auf den Puffer zurückgreifen. Ich weiß halt nicht, ob bei dem Ereignis onRXData schon alle Daten übertragen worden sind. Da steht dann irgend ein Teil in dem Block. Meine bisherige Programmierung läuft so, dass alles in einen Pufferstring geladen wird, bis die Terminierungszeichenfolge am Ende steht. Hierbei kommt es aber zum Verschlucken der Null-Bytes.

[Lomat]

Ich muss ja irgendeinen Zeiger übergeben, der eine Variable repräsentiert in der die Daten stehen. Ich weiß halt nicht, was passiert, wenn der Block zu groß ist. Ansonsten müsste man hier sich bis zur Terminatinsbitfolge vortasten. Was ich mich frage ist halt, ob es irgendeine Funktion gibt, die mir den Füllstand des Puffers verrät. Alternativ kann ich mir vorstellen, dass es sich um einen statischen Puffer handelt, bei dem halt ein Block definierter Größe hinterlegt ist. Hier müsste ich die größe des Speicherblocks wissen.

[Lomat]

Hallo nochmal,

ich habe das Hauptproblem gelöst, indem ich von Synaser TBlockSerial direkt verwendet habe, statt über irgendwelche visuellen Komponenten zu gehen. Mit Verwendung der Funktion RecvBufferEx werden jetzt auch keine Bytes mehr verschluckt. Es tut sich jedoch ein anderes Problem auf. Beim Öffnen des Ports kommt es nicht reproduzierbar zum Totalversagen. Die Kommunikation ist tot. Das Spektrometer reagiert auf kein Kommando. Es hilft auch kein Ausstöpseln und wieder Reinstöpseln. Was hilft ist Hyperterminal starten, den Port öffnen und wieder schließen. Was kann denn da wieder schief laufen?

VG Christoph

[siro]

Ein grosses Problem gibt es bei den Virtuellen Comports (USB) mittels FTDI/Silabs/Ch340 usw:
Wenn der Port nur kurzzeitig unterbrochen wird, dann verliert das System den kompletten Port.
Zieht man also einen USB ab, dann verschwindet der Port komplett aus dem Gerätemanager.
Deine Software bekommt davon "vermutlich" nix mit, aber der vergebene Handle vom System ist dann nicht mehr gültig.
Du kannst die Schnittstelle demnach nicht mehr nutzen. Noch schlimmer, Du hast eine geöffnete Schnittstelle
bzw. einen ungültigen Handle mit dem man versucht zu kommunizieren und/oder die Schnittstelle zu schliessen.

Solche Probleme treten bei mir auch durch Störungen auf.
Man solls nicht glauben, aber zum Beispiel reicht es bei mir manchmal
wenn ich den Lötkolben einschalte, dann klingt es als würde man einen USB an bzw. abstöpseln,
der typische Signalton und dann wars das mit der Schnittstelle.
Ähnliches durch elektrostatische Aufladungen wenn ich über den Teppich gelaufen bin und meinen Arm auf den Arbeitstisch ESD Matte lege,
gibts tatsächlich oftmals eine Störung auf dem USB.
Hier muss ich dann das Programm komplett neu starten.

Sowas tritt bei den "echten" seriellen nicht auf. Da kann man an und abstöpseln wie man will.
Für die Synchronisation hat da nur das Programm zu sorgen.
Das kann ich sehr gut testen, da mein Motherboard vom Rechner noch "richtige" Serielle hat.
Die brauchen ja auch keine Treiber....

Ich hab grad mal etwas rumprobiert und mir den Handle(also die vergebene Nummer vom System) nach dem öffnen der Schnittstelle ausgeben lassen.
Manchmal bekomme nach Programmstart die gleiche Nummer, aber das ist nicht sichergestellt. Ziehe ich den USB ab und stecke
ihn wieder dran gibt es mal einen neune Handle, manchmal aber auch den gleichen.
Man kann das also nicht vorhersagen.

Ein ReConnect, also Schnittstelle schliessen und neu öffnen löst dann das Problem,
Selbst wenn nach dem Anstöpseln der USB der gleich Handle vergeben wurde, ist das Schliessen und neu Öffnen der Schnittstelle zwingend erforderlich.

Wenn über eine Zeit keine Daten mehr kommen vom Gerät dann Re Initialisiere ich die Schnittstelle.
Unschön aber anscheinend unumgänglich

Achso, vergessen zu erwähnen, ich arbeite ausschliesslich mit Windows und meiner eigene seriellen Komponente, aber im Prinzip werden
überall die gleichen Funktionen von Windows aufgerufen.

Ergänzung:
Wegen solcher USB Probleme flippte bei meinem Kumpel auch immer sein 3D Drucker aus.
Abhilfe hat hier tatsächlich eine Ferrit am USB Kabel gebracht....