Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich habe folgendes Problem mit meinem Programm (siehe Anhang).
Der Datenstring, den ich vom COM-Port einlese, sollte eine konstante Länge in meinem Fall von 1000 Bytes haben. Die Stringlänge schwankt total und dadurch werden die Graphen völlig ruckelig. Das berechnete Frequenzspektrum ist nicht richtig und schwankt extrem. Nur bei einem Testsinussignal von genau 80 Hz kommen die Daten teilweise so an wie ich es will (siehe Bild 10 Hz; Bild 80 Hz).
Aber wenn meine Daten nur positiv sind, also mit Offset, dann funktioniert es eimwandfrei (siehe Bild 10 Hz positive Werte).
Ich weiß nicht mehr weiter, ich habe schon so viel probiert und nichts klappt.
du hast das TermChar auf der Standardeinstellung gelassen.
Enthält dein zu lesender String evtl. EOL-Zeichen? Dann bricht der Lesezugriff natürlich an dieser Stelle mit dem Warten auf weitere Zeichen ab...
danke für deine schnelle Antwort. Mein String enthält wahrscheinlich ein EOL-Zeichen, aber ich habe in der VISA Configuration Serial Port das "Enable Termination Char (T)" auf "OFF" also disable eingestellt. Somit ist das Terminatinon char ohne Bedeutung das auf 0xA steht, oder??? Und immer wenn ich es ändere, steht nach dem "Run" das 0xA wieder drin.
(28.08.2012 16:33 )BEng Thomas schrieb: danke für deine schnelle Antwort. Mein String enthält wahrscheinlich ein EOL-Zeichen...
Heißt aber, dass du kein explizietes Temination Char in deinem Datenstring hast, oder?
(28.08.2012 16:33 )BEng Thomas schrieb: ...aber ich habe in der VISA Configuration Serial Port das "Enable Termination Char (T)" auf "OFF" also disable eingestellt. Somit ist das Terminatinon char ohne Bedeutung das auf 0xA steht, oder???
Genau, wenn an dem Eingang ein False angeschlossen wird, wird auf ein Termination Char nicht reagiert.
(28.08.2012 16:33 )BEng Thomas schrieb: Und immer wenn ich es ändere, steht nach dem "Run" das 0xA wieder drin.
Was änderst du? Das TermChar? Wo steht das nach dem Run? Im String? Das ist ja klar, da es ja mit übertragen wird.
Beste Grüße,
NWO
9 von 10 Stimmen in meinem Kopf sagen: Ich bin nicht verrückt,
die andere summt die Melodie von Tetris.
NI schrieb:To use the abort button is like using a tree to stop a car!
Dein gepostetes VI erklärt das Fehlverhalten vollständig:
Da an Visa Config nichts angeschlossen ist, ist standardmäßig die Stringende-Erkennung mit "x0A" aktivert. Immer, wenn im Datenstring ein Byte mit dem Dezimalwert "10" vorkommt, wird diese Byte als Zeilenendezeichen interpretiert, und damit Visa Read vor Erreichen der 1000 Byte beendet.
Wenn Du aber nur positive Daten mit Werten >10 sendest, tritt das nicht auf: HighByte ist 0, LowByte ist >10, es kommt also in keinem Byte jemals der Wert 10 vor.
Deine nachgereichte Aussage, Du hättest TermChar nicht aktiviert, ist unglaubwürdig: Das gepostete VI sagt genau das Gegenteil, und die "Versuchsergebnisse" beinhalten genau das, was von diesem VI zu erwarten ist.
Zitat:ich habe in der VISA Configuration Serial Port das "Enable Termination Char (T)" auf "OFF" also disable eingestellt. Somit ist das Terminatinon char ohne Bedeutung das auf 0xA steht, oder??? Und immer wenn ich es ändere, steht nach dem "Run" das 0xA wieder drin.
Anscheinend sind dir Grundbegriffe der LabVIEW-Programmierung, wie das Einstellen von Standardwerten bei Bedienelementen, unbekannt... Wenn du im geöffneten subVI-Frontpanel irgendetwas einstellst und dann das subVI vom HauptVI aus aufrufst (ohne dort Parameter vorzugeben), werden automatisch wieder die voreingestellten Standardwerte benutzt! Im Fall von InitSerialPort heißt das: TermChar enabled und auf 0x0a gesetzt - so wie es in der Kontexthilfe steht. (Und die sollte man als Anfänger immer offen haben!)
(28.08.2012 19:03 )Lucki schrieb: Wenn Du aber nur positive Daten mit Werten >10 sendest, tritt das nicht auf: HighByte ist 0, LowByte ist >10, es kommt also in keinem Byte jemals der Wert 10 vor.
Hier muss ich mich selbst korrigieren: Bei einer 12byte-Zahl im Wertebereich 0...4095 bzw. -2048..2047 hat man in insgesamt 272 Zahlen Werte, bei denen entweder das High- oder das Low Byte den Wert 10 annimmt. Die Gefahr lauert also auch im nur positiven Bereich überall.
29.08.2012, 09:32 (Dieser Beitrag wurde zuletzt bearbeitet: 29.08.2012 09:34 von BEng Thomas.)
Manchmal sieht man den Wald vor lauter Bäumen nicht. Hab den Termination Char von außen auf "OFF" also ne False-Konstant angelegt und jetzt funktioniert es eimwandfrei!!! JUHU!!!
Für besonders professionell halte ich die Lösung trotzdem nicht. Wenn ein einziges Byte mal nicht richtig gelesen wird - und damit muss man bei seriellen Übertragungen rechnen - dann kommt nur noch Datenssalat an, wenn dann High-Byte und Lowbyte bei der Auswertung immer vertauscht sind.
Ein Lösung könnte z.B. sein, die 12 Bit zu je 6 bit auf beide Bytes gleichmäßig zu verteilen. Dann könnte man die 2 höherwertigen freien Bits dazu verwenden, High- und low- Byte als solche zu markieren.
Dieser ganze Krampf gilt natürlich nur für den Fall, dass Du auf ein hohe Übertragungsrate angewiesen bist. Der Normalfall ist: Übertragung der Daten im ASCII-Hex-Format mit Trennzeichen zwischen den Werten. Es würden dann allerdings 4 statt 2 Byte pro wert gebraucht:
3*Ziffer "0..F" (=12bit), 1*"x0A"
/
VISA Read - Stringlänge schwankt extrem
Ich weiß nicht mehr weiter, ich habe schon so viel probiert und nichts klappt.
Hab den Termination Char von außen auf "OFF" also ne False-Konstant angelegt und jetzt funktioniert es eimwandfrei!!! 
JUHU!!!
