schreiben auf COM3 macht Probleme

Hi,
ich habe hier ein serielles Gerät.
COM3, 9600,8,N,1 kein Handshake.

Mit Teraterm und ähnlichem läuft es simpel, man sendet "PR SN\r" und erhält als Antwort die Seriennummer "123456\r\n".

Auch mit MAX geht das problemlos, mit meinem VI finde ich den Fehler nicht, die VISA-write Funktion macht Fehler:
−1073807298 Operation konnte aufgrund eines I/O-Fehlers nicht ausgeführt werden.

Wer kann mir hier weiterhelfen, ich verstehe es nicht.
Com3 ist so ein virtueller serieller port von einem USB auf RS232 Umsetzer, aber wenn der in MAX geht, sollte er doch auch im VI laufen, oder ?

Angehängt das VI von mir .
  visatestPR_SN.vi (Größe: 12,61 KB / Downloads: 196)


Werner

Hilft das hier?
http://digital.ni.com/public.nsf/allkb/0...2E006DF187

Gruß, Jens

Hi Jens,
danke für die Hilfe -> ich war schon begeistert... aber das triffts nicht.

In diesem Error gehts zwar, wie bei mir um einen Third Party USB-Serial Adapter mit der gleichen Fehlernummer, aber im VISA Configure Serial Port.vi. Der geht bei mir, mein Fehler tritt erst im Schreiben mit dem VISA Write auf... ich versteh gar nicht wie da überhaupt ein Fehler entstehen kann.

Was ich nicht verstehe, wieso gehts dann mit dem MAX ?

Das beispiel hier aus dem Forum: http://www.labviewforum.de/Thread-RS232-Terminal geht bei mir auch nicht. Es treten auch da Fehler auf, aber ich versteh das teil nicht ganz...

Was ich später eigentlich machen will, ist eine Erzeuger-Verbraucher-Struktur, wo immer dann, wenn etwas aus der seriellen Schnittstelle angekommen ist (abgeschlossen durch ein CR), ein Event ausgelöst wird, auf das ich dann im Verbraucherzweig elegant reagieren kann...

Hätte da jemand vielleicht was Fertiges für mich ?

Werner

Das VI müsste so wie es ist funktionieren, ich sehe keinen Fehler. Grübeln hilft da nicht, da hilft nur Experimentieren mit anderen Ports. Hast Du nicht am PC einen echten COM1-Port? Gehts damit? Oder einen seriellen USB-Adapter mit einem anderen Chip probieren? (Ja, ich weiß - man sieht erst wenn man gekauft hat, was für ein Chip drin ist)
Bei meinem Adapter mit FTDI-Chip, Treiberversion:
   
tritt dein Fehler beim Schreiben nicht auf. Hast Du überhaupt für den COM-Adapter die neuesten Treiberversionen? Das ist doch immer das Erste, was man bei jeder Hotline gefragt wird.

Lucki,
du hast völlig recht. Danke für den Test mit deinem FTDI, auch ich habe diese FTDI-Chips und Treiber hier installiert (eigene Hardware, anderes Projekt).

Leider ist es so, dass dieser virtuelle Treiber sicher der Wackelkanidat ist.
Bevor ich für die Motorsteuerung was mit LabVIEW machen sollte, war das ganze in MATLAB realisiert.
Auch da macht die RS232-Schnittstelle Ärger. Ich kann leider nicht einen anderen USB auf RS232 Umsetzer nehmen, das ist ein fertiges Gerät.
Ich habe bereits in C++ mit dem Teil gearbeitet, und auch da hatte sich dieser virtuelle serielle Port aufgehängt, sogar mein XP abgeschossen (Raid war aufgelöst, remirroring nötig usw.) aber letztendlich geht der mit meiner DLL, mit MAX, mit Teraterm und mit dem Motoreigenen Windowsprogramm.

Kurz: ich muss dieses Teil in Betrieb kriegen.
Was ich nicht verstehe: wieso gehts im MAX mit OpenVisaTestpanel ? Dann müsste es doch auch im eigenen VI so gehen...

Werner

Gut. Dann rede doch nicht so viel um die Sache herum und sauge hier den neuesten VCP-Treiber für Dein Betriebssystem und probiere es aus. Bei mir hatte das bei so einem ähnlichen Problem entscheidend geholfen.

Lucki,
wie ich schon schrieb: ANDERES PROJEKT !

Für die Hardware hier (kein FTDI sondern was komisches...) gibts keine neuen 32Bit Treiber, nur für 64Bit haben die neuere. Damit gehts. Ich brauch aber 32Bit.

Ich habs aber hinbekommen: so gehts     : VISA Set Buffersize und der Fehler ist weg...

Danke fürs mitdenken.

Werner