Hallo liebe LVF- User!
Ich habe ein Problem bezüglich Ansteuern eines Gerätes mittels Serieller Schnittstelle und zwar funktioniert das Programm bei RS232 Schnittstellen einwandfrei, aber bei RS232 USB Convertern nicht mehr.
Das Gerät besitzt eine RS232 Schnittstelle, die ich auch ohne Probleme ansteuern kann (Read/Write), nun ist es aber so, dass der Laptop an dem das Programm mal laufen soll, keine RS232 Schnittstelle hat. Ich wollte das Problem mittels RS232 USB Converter lösen, doch beim testen des Programmes wird im "Read" Baustein immer ein Fehler ausgelöst und es kommen immer nur kryptische Zeichen raus bzw. hängt sich das angesteuerte Gerät auf. Ich habe auch schon mehreren RS232 USB Converter probiert doch es ist immer wieder das selbe Problem.
Nachdem ich in LabView noch nicht allzuviel Erfahrung habe, wollte ich fragen ob mir wer helfen könnte?
Hier noch ein paar Daten:
Die RS 232 Schnittstelleneinstellung für das Gerät sind:
Übertragungsart: asynchron
Baud Rate: 9600
Datenbit: 7
Stoppbit: 2
Parität: gerade
Als Ablaufsteuerung verwende ich DTR/DSR
Der RS232 USB Converter wird vom Computer erkannt und als COM Port angegeben (z.B. COM10).
Der Fehler der immer auftritt ist:
NR.: -1073807253
"Während der Übertragung ist ein Rahmensynhronisations- Fehler aufgetreten"
Ich hänge noch das VI an Lab View 8.0 Version
Schon mal danke im voraus.
lg PMG
[
attachment=40405]
Hi,
ich hab die Erfahrung gemacht, dass diese USB-Serial-Converter einfach mehr Fehler produzieren als Schnittstellen, die z.B. auf PCI basieren. Hatte auch eine Kommunikation mit einem Peltier-Treiber, die immer schief lief - PCI-Karte gekauft, dann gings, lag also am Logitech-Converter...
Ich meine, hier gab's mal einen Thread, wo m.E.n. auch ein USB-Converter empfohlen wurde - hab ich aber gearde nicht griffbereit. Vielleicht wirst Du da ja fündig...
ch
(26.06.2012 10:19 )PMG schrieb: [ -> ]Hier noch ein paar Daten:
Die RS 232 Schnittstelleneinstellung für das Gerät sind:
Übertragungsart: asynchron
Baud Rate: 9600
Datenbit: 7
Stoppbit: 2
Parität: gerade
Als Ablaufsteuerung verwende ich DTR/DSR
Der RS232 USB Converter wird vom Computer erkannt und als COM Port angegeben (z.B. COM10).
Der Fehler der immer auftritt ist:
NR.: -1073807253
"Während der Übertragung ist ein Rahmensynhronisations- Fehler aufgetreten"
Die rot markierten Dinger sind nicht sehr RS-232 Standard und die Chance besteht dass viele billige USB Converter diese gar nicht oder fehlerhaft unterstützen. Im Zusammenhang mit dem aufgetretenen Fehler würde ich auf 7 Datenbits und/oder 2 Stopbits tippen.
8 Bit, 1 oder 2 Stop Bits geht meist gut. 1 1/2 Stopbits wird bei sehr vielen Adaptern oft gar nicht unterstützt kann aber je nach Gerät auch noch mit 1 oder 2 Stopbits gut gehen.
Hallo rolfk,
um die Konfiguration
Datenbits: 7
Stoppbits: 2
komm ich nicht herum, die sind vom Hersteller für das Gerät festgelegt, bin gerade auf der Suche nach RS232 Convertern, hab auch schon den Hersteller angerufen (meinte er klärt das mit dem Converter ab und gibt mir Bescheid). Mal sehen was dabei raus kommt.
Die Ablaufsteuerung hab ich selbst gewählt da diese nirgends angegeben war, hab aber vorher alle anderen durchprobiert (XON/XOFF usw.) die funktionierte für das Gerät am Besten. Welche Ablaufsteuerung würdest du empfehlen, vielleicht liegts ja wirklich daran?
Ich schau mal obs mit dem Converter vom Hersteller geht, trotzdem Danke für die Hilfe
Bei Dir sind Ungereimtheiten im VI:
Wenn Du Flußsteuerung DTR/DSR hast, wozur dann XON/XOFF konfigurieren? Falls Du kein Originalkabel für PC-Anschluss vom Gerätehersteller hast, würde ich Fußsteuerung "Keine" nehmen. Damit das Geräteseitig funktioniert, müssen dort DTR/DSR am Stecker miteinander verbunden werden. Dem Gerät wird damit DTR/DSR-Steuerung vorgegaukelt.
Der Empfang kann so nicht funktionieren, auch nicht mit einem Nicht-USB-Port. Bei Dir funktioniert es so:
Nach "Bytes an Ports senden" sind die Bytes erst mal im Sendepuffer. Das Gerät hat da noch nichts empfangen, geschweige denn hat es schon geantwortet. Die Antwort auf die Abfrage der Bytes im Empfangspuffer ist also immer "0" (Es sei denn, es sind noch alte Botschfften im Empfangspuffer, die aber dann keine Passenden Antworten auf den zuletzt gesendeten Befehhl sind).
Das Programm ist sehr viele einfacher als Du es gemacht hast, ich habe das schon mehrere Mal gepostet, und die Beispiele sind eigentlich immer gleich.
Zum Rahmen-Synchronisationsfehler:
Da gibt es z.B. zwei Ursachen:
1. Falsche Konfiguration (Baudrate, Parität, ... )
2. Wenn das Gerät dauered von selbst sendet, und man hört den Empfang zu einem beliebigem Zeitpunkt ab. Dann passiert es, dass man erst mal mitten in ein Byte hineinhört, bevor es zur Synchronisation kommt. Kann eigentlich bei Master-Slave Konfigurtion (Gerät sendet nur nach Kommando) nicht auftreten.
Es lohnt sich auch, die neuesten VCP-Treiber zu saugen, z.B von der Homepage von FTDI, wenn der Chip von FTDI ist. Dort gibt es auch genaue Datenblätter, wenn es darum geht, was der Chip macht und was nicht.
Hallo,
Hab die Lösung gefunden!!!
Aber zuerst zu meinem Programm, das mit XON/XOFF war noch übrig von den Versuchen die passende Ablaufsteuerung zu finden und deshalb hab ichs noch drinnen gelassen
Das Problem lag nicht im Programm, sondern in der Verbindungsleitung zum Gerät, denn das Gerät verlangt, dass man es mit einem Nullmodemkabel betreibt. Bei dem vom Gerät mitgelieferten Nullmodemkabel wurden aber nicht alle Leitungen der SUB-D 9polig ausgeführt, somit kamen die Signale nicht zum Converter, der dann das Ganze als Blödsinn erklärt hat und somit die Fehlermedlung auftrat.
Jetzt hab ich die Ablaufsteuerung, auf anraten von Lucki (besten Dank dafür), auf "Keine" gesetzt (ging mit dem anderen Kabel trotzdem nicht) und das Kabel getauscht (vollständig ausgeführtes Nullmodemkabel).
Nun funktioniert das Programm gleich wie bei der RS232 Schnittstelle, nur der Timout zwischen den Befehlen muss etwas erhöht werden (Grund: Converterverzögerung).
Nochmals vielen Dank an alle
liebe Grüße PMG