LabVIEWForum.de

Beim auslesen eines COM-Ports erhalte ich folgenden Fahler (Beschreibung von NI.com):

1073676294 VI_SUCCESS_MAX_CNT The number of bytes transferred is equal to the requested input count. More data might be available.

Wenn ich mir das mit einer Sonde anschaue, liegen genau 0 Bytes am Port.

Ich verwende keine NI-Hardware, schreibe aber trotzdem mal kurz auf, was ich so angeschlossen habe:
(Die Hardware ist komplett vom polnischen Hersteller SENSOR Electronic)

Direkt am USB-Port angeschlossen ist ein "SensoBee USB receiver". Dieser sollte über Funk von einem "SensoBee485 transmitter" Daten erhalten. An dem Transmitter sind drei "SensoAnemo transducer" angeschlossen. Damit sollte es möglich sein, Temperaturen und Strömungsgeschwindigkeiten zu messen.

Verwende ich die mitgelieferte Software AirSpeedSys5000 (Version 1.0) erhalte ich zumindest Temperaturwerte (ändern sich auch beim anpusten). Dabei erhalte ich aber auch einen Kommunikationsfehler (mehr Infos gibt die Software nicht her). Lese ich den COM-Port manuell aus, passiert gar nichts außer dem genannten Fehler.

Die Sensoren habe ich an einem anderen Prüfstand ohne die Funkstrecke positiv testen können. Ich würde nun gerne alles auf die Funkstrecke schieben. Aber ich erhalte ja Temperaturschwankungen über die original-Software.

Hat irgendjemand einen Hinweis was ich evtl falsch gemacht habe?

LG
Torsten

Das ist kein Fehler, sondern nur ne Warnung, oder?

Darüber gab's hier schon ne hitzige Diskussion, ist aber schon länger her..."das darf nicht sein, da machst du was falsch...du musst mit "BytesAtPort arbeiten"...etc.pp...das mache ich ja immer und trotzdem: Das tritt regelmäßig bei mir auf, wenn ich aus LV am RS232 lese...ich sehe inzwischen drüber hinweg, es macht nämlich rein gar nichts!

Gruß
Achim


EDIT: Post #3000....STRIKE!

' schrieb:Das ist kein Fehler, sondern nur ne Warnung, oder?

Darüber gab's hier schon ne hitzige Diskussion, ist aber schon länger her..."das darf nicht sein, da machst du was falsch...du musst mit "BytesAtPort arbeiten"...etc.pp...das mache ich ja immer und trotzdem: Das tritt regelmäßig bei mir auf, wenn ich aus LV am RS232 lese...ich sehe inzwischen drüber hinweg, es macht nämlich rein gar nichts!

Gruß
Achim
EDIT: Post #3000....STRIKE!

Ja es ist eine Warnung. Aber ich habe eben das Problem, dass ich genau 0 Byte als Antwort bekomme. Und das ist mir zu wneig. Ich erwarte ca 22 Byte. Und ich finde es eben erstaunlich, dass die Originalsoftware immerhin einen Temperaturwert bekommt.

Achso...du kriegst gar nichts...hm...kann es sein, dass du mit deiner Probe zu spät guckst? Mach mal direkt nach dem Read nen Breakpoint und bei BytesAtPort ne Probe!

Ich habe jetzt folgendes:

Visa öffnen mit dem richtigen COM-PORT
Visa konfigurieren (TimeOut: 500; Baudrate: 115200)
Visa schreiben (Befehl "#120") hab ich aus der Doku und hab auch schon alle anderen Befehle getestet
Bytes at Port liefert danach 0
50ms warten
Bytes at Port liefert immmer noch 0
Visa lesen (doof weil Bytes at Port = 0 angeschlossen ist)
Bytes at Port liefert immer noch 0
Visa schließen

Hast du nach deinem Befehl ein CarriageReturn programmatisch angefügt? LV macht das nicht automatisch, das HyperTerminal z.B. aber schon...vielleicht fehlt deinem Empfänger ja noch was?

Auch das hab ich schon hin und her probiert.

Hier mal ein Bild von meinem Standard-VI zum schicken eines Befehls und Antwort auslesen.

[attachment=17375]

okay ein fortschritt: ich habe an den Befehl noch die chacksumme angehängt, die laut doku optional ist. nun bekomme ich eine venünftige antwort ">+21.01+00.000+00.00001D"!!!

Jetzt kann ich mal schaun was ich damit anfangen kann. Danke für alle Tipps bis hierhin!

' schrieb:okay ein fortschritt: ich habe an den Befehl noch die chacksumme angehängt, die laut doku optional ist. nun bekomme ich eine venünftige antwort ">+21.01+00.000+00.00001D"!!!

Jetzt kann ich mal schaun was ich damit anfangen kann. Danke für alle Tipps bis hierhin!

Optional kann bei bestimmten Geräten bedeuten, dass Du sie als NULL schicken kannst aber nicht unbedingt weglassen. Protokolldokumentation ist immer ein ziemlich tricky Business und ohne minimal Pseudo-Code Beispiele oftmals eine einzige Raterei.

Rolf Kalbermatter