Random failures to communicate: RS 232 in Labview 2010

[Brendan_C]

Hello,

Upon upgrading to Labview 2010 from Labview 8.2.1, all my serial communication programs have developed a maddening problem: they ignore many of the commands that they are sent.  No error codes are given... the devices just act like the computer never issued them a command.  There doesn't seem to be a clear pattern of when the programs fail (but they fail about 70% of the time), and NI Spy shows no difference (that I can see) between the times the codes work and the times they don't.  Adding time delays hasn't helped anything, but turning on "Highlight Execution" seems to vastly improve the chances of success (if not fix the problem).   

I've found this problem with two setups... USB to NI RS232/4 to a syringe pump and USB>Conrad USB to RS 232 (1 port) cable to another syringe pump (different manufacturer).  I have the most up to date version of VISA, Serial, and DAQmx drivers currently, and Labview's auto-updater recently patched the program (though the problem occurred before this patch). Completely uninstalling Labview 2010 and reinstalling a less recent set of Serial drivers and Labview 8.2.1 (don't have access to my record of which one at the moment) restores functionality.  Unfortunately, I currently only have access to 2010, so I can't continue to use 8.2.1.

I'll attach an example of my code, but I've reproduced this faliure using the Advanced Serial Read and Write and Basic Serial Read and Write example .VI files.

I'm at a loss... does this sound familiar to anyone?

[K C]

Hi,

Strange that you specify a 'termination chareacter' and disable it.

I modified your VI. I think it is better to use the VISA configure VI to setup your com port.

Kees

[Brendan_C]

Thank you for the response and the tip!  I'll give it a try tomorrow, and post here if it improves the success rate of the program.

[Brendan_C]

The problem is solved for now.  

The trick this time was bypassing my USB>Serial connection in favor of a direct Serial to Serial connection.  Browsing the web on this topic on other sites has taught me that USB to Serial converters have a pretty high faliure rate due to the disparity in the voltages used for the two communication protocols.  Perhaps this was the problem, or maybe some un-accounted for delay while converting the signal.

In retrospect, this problem was more closely linked in time to updating my NI Serial drivers than it was to updating Labview itself.  Is it possible that some voltage threshold was changed with the most recent drivers that caused a NI USB to RS232 hub to work less reliably with my instrument?

[Hamid_]

Dear Sir,

I am writing a program to control Kloehn Syringe Pump. I do not know, it is same yours or not.  Is there any thing I should

pay attention on it for this programming or not?

Thanks,

Hamid

[K C]

Hi Brendan,

I don't think the drivers have any influence on the output voltage of the drivers. Sure nowadays many manufacturers use voltages as low as +/- 5V for RS-232 but this is still within the spec of minimal 3V.

What do you mean with 'bypassing my USB>Serial connection in favor of a direct Serial to Serial connection'

When you use the VISA functions you can use the COMx reference to address a port.

Kees

[JasonSmith]

K C is right, in that different versions of NI-Serial will not result in different voltages being used. There have been changes made to the operation of the USB-Serial, in order to resolve outstanding issues and to generally increase performance and reliablity.

If you can provide information regarding which versions of NI-Serial were in use before and after the upgrade, that may shed some light on what may have caused the change of behavior in your application.

-Jason S.

[Brendan_C]

Hello,

By "bypassing USB to Serial..." I mean simply using a serial port on a laptop (with 9 pins and everything) instead of a USB port with a Serial to USB adaptor cable (with associated drivers for the adapator recognized by NI Max and Windows device manager).

I will obtain the driver information off of the un-updated computers and post it here once the computers (and I) return from our separate deployments (should be in a couple of weeks).

Taken as a whole, the full range of observations is even more puzzling  6 computers here... I'm writing this now while it's fresh in my head...

Computers 1 through 3 (Two Dells and a Sony Viao, Windows XP, Labview 8.2.1, older drivers, NI USB to 4-Serial port hub): communicates perfectly unless upgrades to Labview 2010 and most recent drivers are applied in which case communications fail >50% of the time.  Resumes working well upon reverting.

Computer 4 (Acer, Windows 7, Labview 2010, recent drivers, USB to Serial cable): communicates sporadically through USB to Serial cable with >50% faliure rate... still, amost usable with programmatic workarounds.

Computer 5 (Toshiba, Windows 7, Labview 2010 RTE, most recent drivers, USB to Serial cable): total faliure to communicate through USB to Serial using same setup and drivers as computer 1.

Computer 6 (Toshiba, Windows XP, Labview 2010 RTE, recent drivers, has an actual serial port): communicates perfectly through serial port, but faliure to communicate through USB to Serial cables... upon communicating with Computer 6, syringe pump stops communicating with computer 4 (haven't checked with computers 1-3).

[Brendan_C]

Hello Hamid,

Yes, I have been working with both a Kloehn V6 and a Cavro XLP 6000 syringe pump.  Of the various instruments I've worked with, these two syringe pumps have been among the easiest to communicate with (aside from these recent troubles).  As long as the switch on the back of the pump is set to a number that is one less than the number that you are addressing the pump as (recommend setting switch to 0, and addressing the pump as /1 if you only have one pump per serial port), then rest is pretty easy... the .vi that I posted on this site has worked well for me for the Kloehn syringe pumps for awhile if you have access to Labview.  However, as you can see, I'm currently troubleshooting these communications, so my apologies if the code doesn't help!

I have a .vi that I use for interpreting the Kloehn error codes if you are interested.

Best,

-Brendan

[Brendan_C]

Oh, and thank you for the feedback!