LabVIEWForum.de - Rahmensysnchronisationsfehler?

<div align="left">wunderschönen Tag allerseits,

Diesen Beitrag musste ich unbedingt mal shnell ins neue Forum kopieren, da ich glaube in das alte schaut keiner mehr hinein Aber ich brauchde dringend Eure Hilfe dazu.:
ich hab ein paar Fragen, die wahrscheinlich nur ein Diletant wie ich stellen kann.:
ich habe eine Sensorensteuerung die unablässig Daten im ASCII Format mit 15200 Baud über die RS232 schickt. Daraus muss ich irgendwie die richtigen Daten herausfiltern. Ein Problem dabei ist, dass ich vorher nicht weiß aus wieviel Bytes der für mich relevante Teil der Daten besteht. Die Daten die ich herausfiltern möchte kommen meist unmittelbar als Anwort auf einen Steuerbefehl. Das passiert meist jedoch so schnell unmitelbar nach dem Absenden, dass mein VI auf einem 500 Mhz P3 unter WinXP wahrscheinlich nicht schnell genug hinterherkommt.
Jede zurückgesendete Antwort auf einen Steurbefehl sollte eigentlich mit der ASCII-Zeichenkette "read" abgeschlossen werden.
Ich hab die Daten schon mal mit einem Terminal ausgelesen. Bei VISA-read kommen sie aber nicht in dieser Form heraus wie am Terminalprogramm, sondern nur als völlig kryptische Zeichen, mit denen ich nichts anfangen kann. Wie kann ich diese richtig umwandeln?
Irgendwie muss ich das Aulesen wohl gleichzeitig zum Senden des Steuerbefehls realisieren. Wie mache ich das am besten?
Egal welche Anzahl der zu lesenden Bytes ich angebe, ich erhalte jedes mal so eine Meldung mit einem "Rahmensynchronisationsfehler" bei VISA-read. Was ist ein Rahmensynchronisationsfehler genau? Wie kommt sowas zustande? Und was kann ich dagegen tun?
ich wäre für nützliche Hinweise unheimlich dankbar.

beste Grüße
SchwindelInside</div>

' schrieb:Die Daten die ich herausfiltern möchte kommen meist unmittelbar als Anwort auf einen Steuerbefehl. Das passiert meist jedoch so schnell unmitelbar nach dem Absenden, dass mein VI auf einem 500 Mhz P3 unter WinXP wahrscheinlich nicht schnell genug hinterherkommt.

Das glaube ich nicht. ich hatte mal eine Notebook mit schlappen 133 Mhz und habe damit auch serielle kommunikationen mit 115200 Bit/sek gemacht.

Zitat:Irgendwie muss ich das Aulesen wohl gleichzeitig zum Senden des Steuerbefehls realisieren.

Das glaube ich auch nicht.
Deine Peripherie antwortet auf einen Steuerbefehl. (Zitat: >>Jede zurückgesendete Antwort auf einen Steurbefehl <<).
Es wartet mit sicherheit auch auf ein "ende"-Zeichen.
Also fängt es erst an zu senden, wenn das Ende - Zeichen angekommen ist. Dann kannst Du doch locker von einer Write auf eine Read Funktion wechseln. Dein Rechner ist schnell genug. Mit Sicherheit.
Und selbst wenn Senden und Empfangen gleichzeitig geschehen WÜRDE, dann sind die Daten ja nicht verloren, sondern im Empfangs-puffer.
Den kannst du ja auslesen, wann du möchtest (vorrausgesetzt er läuft nicht über).

Und sonst: Was spricht dagegen eine VISA-read und eine VISA-write Funktion nebeneinander laufen zu lassen? Ich glaube das müsste gehen.
Habe es noch nicht getestet. Du könnstest einfach den VISA-resource-name an die beiden Routinen kopieren und dann müsste es laufen.

Zitat:Egal welche Anzahl der zu lesenden Bytes ich angebe, ich erhalte jedes mal so eine Meldung mit einem "Rahmensynchronisationsfehler" bei VISA-read. Was ist ein Rahmensynchronisationsfehler genau? Wie kommt sowas zustande? Und was kann ich dagegen tun?

Das bedeutet, dass die Bits, die ja in einem bestimmten Zeitrahmen gesendet werden SOLLTEN, eben nicht in diesen Rahmen passen.
Das kann mehrere Gründe haben:
1. Die Einstelleungen stimmen nicht überein (baudrate, parität, Stop-und Datenbits)
2. Leitung zu lang, nicht genügend geschirmt
3. Störquellen, wie Starkstromkabel, Magnetfelder usw.

Wenn Du den Fehler immer hast, tippe ich auf die 1. Möglichkeit.
Wenn der Fehler nur ab und zu auftaucht, tippe ich auf die 2. oder 3. Möglichkeit.

Ich hoffe es hat dir ein wenig geholfen...
<div align="left"> </div>

<div align="left">danke an diplNisse für die Antwort.

Zitat:Das glaube ich nicht. ich hatte mal eine Notebook mit schlappen 133 Mhz und habe damit auch serielle kommunikationen mit 115200 Bit/sek gemacht.

Vielleicht hab ich auch mein VI zu lahm und uneffizient programmiert.

Zitat:Es wartet mit sicherheit auch auf ein "ende"-Zeichen.
Also fängt es erst an zu senden, wenn das Ende - Zeichen angekommen ist. Dann kannst Du doch locker von einer Write auf eine Read Funktion wechseln.

jedes Commando soll mir einen "Carrage Return" abgeschlossen werden. Dannach erwartet die Steuereinheit je nach Kommando eine ganz definierte Anzahl von Zeichen als Paramter. Sobald das letzte Zeichen abgeschickt wurde, kommt sofort ohne Delay die Antwort zurückgeschossen.

Zitat:Und selbst wenn Senden und Empfangen gleichzeitig geschehen WÜRDE, dann sind die Daten ja nicht verloren, sondern im Empfangs-puffer.
Den kannst du ja auslesen, wann du möchtest (vorrausgesetzt er läuft nicht über).

Und sonst: Was spricht dagegen eine VISA-read und eine VISA-write Funktion nebeneinander laufen zu lassen? Ich glaube das müsste gehen.
Habe es noch nicht getestet.

ich werde mein VI dahingehend völlig umbasteln. Ich hab da schon eine Strategie. Ich werd dann sicherlich noch mal Rückmeldunge geben, wie es funktioniert hat.

Zitat:Du könnstest einfach den VISA-resource-name an die beiden Routinen kopieren und dann müsste es laufen.

Das mache ich immer so.

Zitat:Das bedeutet, dass die Bits, die ja in einem bestimmten Zeitrahmen gesendet werden SOLLTEN, eben nicht in diesen Rahmen passen.
Das kann mehrere Gründe haben:
1. Die Einstelleungen stimmen nicht überein (baudrate, parität, Stop-und Datenbits)

Die VISA-Einstellungen sind die gleichen wie ich sie im Terminal eingestellt habe und da hat das ganze ja funktioniert. Außerdem weiß ich, dass die Steuereinheit des Sensors die empfangenen Kommandos meistens richtig empfängt. Das kann ich an dessen Display ablesen. Die Messwerte die von dieser Steuereinheit unablässig eintrudeln, so lange keine Steuerbefehle vom Computer kommen, kann ich auch ordnungsgemäß auslesen. Nur die Antworten auf die Steuerbefehle sind irgendwie nicht brauchbar.

Zitat:2. Leitung zu lang, nicht genügend geschirmt
3. Störquellen, wie Starkstromkabel, Magnetfelder usw.

ich verwende ein handelsübliches serielles Kabel von höchsten 3 m Länge. Wenn ein Computer mit Röhrenblindschirm, ein paar Messgeräte und ein paar 220 V-Netzkabel schon ernstzunehmende Störquellen darstellen können, dann hab davon hier mehr als genug.

Zitat:Wenn Du den Fehler immer hast, tippe ich auf die 1. Möglichkeit.
Wenn der Fehler nur ab und zu auftaucht, tippe ich auf die 2. oder 3. Möglichkeit.

Ich würde sagen der Fehler taucht fast immer auf.

vielen Dank für die Hinweise.

Grüße
SchwindelInside</div>