USB-RS232 dongle problems

[polycarp]

Hi folks!

I know that similar questions surfaced several times here, but I have not seen a real answer. I have a generic noname USB-RS232 dongle (actually several of them from differenent manufacturers). I am trying to communicate with Newport motion controller through it but got stuck with one problem. I installed drivers for the dongle, WinXP recognized them, MAX sees the port. Everything looks fine, I can write commands to the motion controller and it executes them (I use labview 7.0). The problem pops up when I try to read anything from the controller. I send the command, start waiting for the response, and wait until the operation time-outs. Newport sample apps behave the same way - write works, read - does not. The miracle happens when I plug the controller into the motherboard COM port - everything works. Any ideas what's wrong?

[Nick_CH]

Hi,

I think your problem come from the driver version. Look in the MAX which version do you have installed in your platform.

You can download the last version from "drivers and updates" on the NI web site.

I joint an interesting link from the knowledgebase that could be helpful.
USB Instrument Control Tutorial

Best regards,
Nick_CH

[polycarp]

I have version 2.2.0.0310 We have to stick to version 2.2, since we use USB-GPIB-A  adapter on this machine and 2.2 is the only version that supports it. I spoke to Newport support today. They say it should work, but recommended to buy their dongle for $70, but they were not not sure whether it will work. I will try to install the latest version and check if the serial communication works.

I am aware of the tutorial that you had pointed out, but it describes how to talk to a USB device directly. In my opinion, since Windows recognizes the device as a serial port it should be fully supported on the API level and be completely functional in LabView Apps. We have a great deal of code developed for serial devices, and dealing with USB device directly, rather than sending text messages to the serial port, will require a lot of retrofitting work. Am i right?

[pincpanter]

Have you tested your dongle using Hyperteminal? This can help determining if it's OK or not.

[Thomas L.]

One problem I usually see with USB/RS232 Converters is, that as long as they use a standard communication via Windows API they usually work.
A problem arises, when the data is not a real serial communication but the serial port works as a "bit-toggling" device.
Therefore most programmers for microcontrollers, which use this technique (e.g. cheap Atmega8 & Co. programmers), don't work at all with this sort of dongle. A real serial port is needed then.

[Ben]

This sounds like ther is one of two possilbe issues.

1) The recieve line on the dongle is bad. - Do a loop back to test.

2) The is no gnd line in the cable. - When using the mother bd com port the gnd is being realize through another path.

Just guessing,

Ben

[polycarp]

Well, I've been busy for several days on other projects. I tried a loopback test in hyperterminal today - it works just fine. I have also checked the ground connection, it is present. Any other ideas?

[Ben]

Sonds like tis time to look at little closer.

Since you said

1) the loop back works

2) THe vendor code works on built in  port

3) The vendor code does not work on dongle

Then

A) cabel up a serial line analyzer if you have one

B) Build a "Y" cable that routes the transmit from the built in com port to BOTH the intrument and the dongle recieve line. Watch the dongle using NI-Spy and then fire up the vendor app. Then swap the two prt and run again then compare the results.

Ben

[polycarp]

The problem is solved. The solution is simple: if you want to save some $$$ and buy a noname USB-RS232 adapter for use with NI LV, buy one based on prolific chipset. I bought one for $20.00 from local Fry's electronics store (outpost on east coast). If not marked on the package, prolific-based devices usually have the following advertisement blah-blah: "high speed upto 1 Mbps, support wake-up function, etc." Everything works now, after simple replacement of the dongle and driver installation.   

[TCPlomp]

Good Info!

One addition,

we had one time an issue where the incoming direction worked but outgoing was 'dead'.

After a day of debugging we asked the user if he had installed the drivers of the dongle!!!!

uhm. No


Problem solved!

Ton