+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Instrument IO & VISA (/Forum-Instrument-IO-VISA)
+---- Thema: Serielle Kommunikation (/Thread-Serielle-Kommunikation)
Serielle Kommunikation - labuser2010 - 08.07.2010 15:54
Ich habe eine Schaltung zur Datenerfassung zusammengefügt.
Ein Mikrocontrollerprogramm schickt immer wieder bytes über die serielle schnittstelle. über terminalprogramme wie putty kann man die bytes auch beobachten. also das sollte gehen.
nur in LabVIEW bricht der Datenempfang immer wieder ab. ich weiß nicht warum.
Als Fehler wird immer ausgegeben:
fehler in xxxx.vi
xxxx name meiner Schaltung. kann aber nicht genau feststellen wann und wo der auftritt.
Vielleicht wisst ihr ja woran es liegen könnte.
Ich möchte dass alle Bytes aufgenommen werden und dann nach einer verarbeitung angezeigt werden.
Serielle Kommunikation - eg - 08.07.2010 16:04
Hi!
Welche bytes? Was ist mit dem Abschlusszeichen?
Serielle Kommunikation - labuser2010 - 08.07.2010 18:27
' schrieb:Hi!
Welche bytes? Was ist mit dem Abschlusszeichen?
habe ich schon probiert. also schon mehrere ausprobiert. bei 8 Bit können es ja nur werte zwischen 0 und 255 sein. hatte die mal variable geändert.hat aber keinen erfolg gebracht
Serielle Kommunikation - jg - 08.07.2010 19:20
@labuser2010:
http://www.LabVIEWforum.de/index.php?act=boardrulesBeiträge im SMS-Stil ohne Punkt, Komma, und (fast) alles klein geschrieben ist hier im LVF nicht gerne gesehen.
Zu deiner Frage: Vielleicht solltest du mal den TerminationChar bei der Schnittstellen Kommunikation auf FALSE stellen? Nur so eine Idee.
Gruß, Jens
Serielle Kommunikation - labuser2010 - 09.07.2010 08:49
Habe das mit dem "Termination Char" probiert. Dies brachte aber meines Erachtens keinen Unterschied.
Was könnte es noch sein?
Trotzdem vielen Dank schonmal!
Serielle Kommunikation - jg - 09.07.2010 11:35
' schrieb:Als Fehler wird immer ausgegeben:Ist die Fehlermeldung von LabVIEW wirklich so unspezifisch? Oder ist die ausführlicher, dann her damit.
fehler in xxxx.vi
' schrieb:Habe das mit dem "Termination Char" probiert. Dies brachte aber meines Erachtens keinen Unterschied.Schön, dass du einen Screenshot vom Configure-VI hochlädst. Hast du jetzt am Eingang des Configure-VI ein FALSE angeschlossen?
Dann noch was anderes:
Du wertest grundsätzlich nur die ersten 4 Bytes deines empfangenen Strings aus. Soll das wirklich so sein?
Gruß, Jens
P.S.: Vielleicht mal VI hochladen und den empfangen String als HEX-Code. Dann noch Hintergrund-Infos, was rauskommen soll.
Serielle Kommunikation - labuser2010 - 09.07.2010 13:21
So ich gebe das Ganze jetzt als Anhang bei.
Über den Bus kommen die Bytes an. Dann sollen diese darauf überprüft werden, ob ihr MSB == 1 ist.
Wenn dies der Fall ist, soll das aktuelle Byte und die nächsten drei folgenden Bytes verarbeitet werden. Diese werden dann zusammengefügt und in zwei Signalverlaufsdiagrammen ausgegeben.
Das Ganze soll nach Möglichkeit kontinuierlich erfolgen.
Nun ist es momentan so, dass die Verbindung immer nach ein paar richtigen Werten abbricht. Der Kontrolltext gibt die richtigen Werte aus. Diese werden allerdings auch noch nicht richtig verarbeitet. Was das nächste Problem ist.
Zum Test werden immer Folgende 4 Bytes übertragen.
0X87 -> Wert1
0X7F -> Wert2
0X6D -> Wert3
0X66 -> Wert4
Nach der Umrechnung sollte ADC1 = FFF und ADC2 = 6E6 sein.
Vielen dank schon mal!
[attachment=27746]
Serielle Kommunikation - GerdW - 09.07.2010 13:43
Hallo labuser,
"Diese werden allerdings auch noch nicht richtig verarbeitet."
Wir hatten hier doch schon mal einen Thread, wo wir genau diese Auswertung schon mal durchgekaut hatten, oder?
Edit: Nachdem ich meinen Beitrag aus jenem Thread nochmal durchgeschaut habe und mit den jetzt vorhandenen Beispiel-Werte gefüttert habe, kann ich dir sagen, das der eine Faktor von 64 auf 128 geändert werden muss. Aber da du ja eh selbst testen solltest, war dir das sicher schon aufgefallen...
Serielle Kommunikation - Y-P - 09.07.2010 14:47
Bitte LabVIEW-Version des hochgeladenen VIs mit angeben! (LVF-Regeln
)Kann es sein, dass Du schon LabVIEW 2009 hast? Dann bitte auch im
!Gruß Markus
' schrieb:So ich gebe das Ganze jetzt als Anhang bei.
Über den Bus kommen die Bytes an. Dann sollen diese darauf überprüft werden, ob ihr MSB == 1 ist.
Wenn dies der Fall ist, soll das aktuelle Byte und die nächsten drei folgenden Bytes verarbeitet werden. Diese werden dann zusammengefügt und in zwei Signalverlaufsdiagrammen ausgegeben.
Das Ganze soll nach Möglichkeit kontinuierlich erfolgen.
Nun ist es momentan so, dass die Verbindung immer nach ein paar richtigen Werten abbricht. Der Kontrolltext gibt die richtigen Werte aus. Diese werden allerdings auch noch nicht richtig verarbeitet. Was das nächste Problem ist.
Zum Test werden immer Folgende 4 Bytes übertragen.
0X87 -> Wert1
0X7F -> Wert2
0X6D -> Wert3
0X66 -> Wert4
Nach der Umrechnung sollte ADC1 = FFF und ADC2 = 6E6 sein.
Vielen dank schon mal![attachment=56482:SeriellPC1_VISA0907.vi]
Serielle Kommunikation - eg - 09.07.2010 19:26
Man sollte nicht nur alles irgendwie lesen und dann irgendwie verarbeiten. Zuerst sollte man verstehen, was das ganze soll.
Deine Kommunikation ist binär, und nicht ASCII, das spielt eine große Rolle. Bei binären Protokollen schaltet man normalerweise das Abschlusszeichen ab, weil es normalerweise keinen Abschluss am Ende des Pakets gibt (wie bei ASCII das Zeilenende), sondern ein Syncbyte am Anfang des Pakets.
Am einfachsten Stellt man sich Schritt für Schritt den Ablauf vor. Zuerst also ein Byte lesen und schauen, ob es den Anforderungen entspricht (in deinem Fall, laut deiner Beschreibung ist es ein Byte, in dem MSB gleich 1 sein soll). Wenn es stimmt, dann liest du drei weitere Bytes und hast somit deine 4 Bytes zur Umwandlung in Daten. Wenn es nun nicht der Fall ist, dann nichts weiter machen und von Anfang gehen.
Die Wartezeit sollte man am besten auch entfernen, weil VISA Read automatisch solange warten wird, bis etwas da ist und deine Schleife in dieser Zeit sowieso steht. Ansonsten kann es zum Pufferüberlauf kommen.