04-07-2013 10:05 PM
I've worked with LabVIEW and serial ports a lot but here's the first time I've seen this issue; I'll make it quick:
LabVIEW is reading simple ASCII data coming in at 58.1 Hz using all the standard settings with an "ATEN USB to Serial Bridge".
1. I make a simple VI that uses my simple instrument driver VI to read the data; no problem.
2. I incorporate the simple instrument driver VI into a much larger VI which uses a different brand of serial port (Prolific USB-to-Serial Comm Port), and it consistently drops 34.5% of the data.
3. If I run both VIs together with the larger VI not using the ATEN port, the ATEN in his simple VI stilll drops 34.5% of the data.
4. Restart LabVIEW, then everything works fine either together or separately.
It's still working fine but I am worried it might break again. Any ideas?
04-08-2013 02:53 AM
In my experience USB-to-serial converters are to some degree not predictible because Windows adds a lot of latency. 58 Hz is a fairly high rate for serial and may suffer from these latencies.
You have far less headache by using a genuine adapter (PCI or PCIe) in a desktop or a PCMCIA (PCcard) adapter in a notebook. The DeLock devices work very nicely.
Cheers
Edgar
04-08-2013 08:04 AM
I have to use a laptop for this job, so PCI is not an option. Thanks for that information though; I didn't know that Windows latency thing.
04-08-2013 04:56 PM
Hi bmihura,
I just want to make sure I understand the behavior you are seeing:
When you are building the VIs and substituting your ATEN driver VI for the existing Prolific driver VI, you try to run it and the serial data loss is prevalent (34.5% loss).
When you close everything and restart LabVIEW after you are finished writing the code, the VIs start up and run properly with no loss of serial data.
Is this correct?
04-08-2013 05:18 PM
Wishkebab,
I was not clear about the ports; the Prolific port is used for a different instrument in the bigger VI; I only mentioned it because I thought there might be a confict with the ATEN port, which is the one that occassionnally has the data loss. There is also another USB driver in the bigger VI, but he doesn't show up as a COM port.
The problem happened again this morning, and a simple reboot of the laptop fixed it. This is not the desired solution of course 🙂
04-08-2013 06:05 PM
The Prolific USB to RS-232 devices and drivers have a history of being less robust when used with LV than the FTDI drivers and chips. On the Mac the Prolific parts are almost unusable as general purpose ports and I have heard of people on Windows also having difficulties. I cannot offer specifics as to what kinds of problems occurred. You might search on the Instrument Control Board to see of there are any posts about the topic. I think it was discussed on Info-LabVIEW a while back as well.
Lynn
04-08-2013 06:08 PM
These are all good ideas, will do.