LabVIEW RS232 Serial Read Write Application Com Port Freeze Up / Stuck

[Tim888]

Hello,

 

I'm working on an application that requires constant reading and writing through the Serial Port, and the application needs to be running continuously.  The issue that I come across is that the port get "stuck" at random times.  Sometimes it can run for minutes to 12 hours before the port freeze up.

 

I am wondering if anyone has experience with this and have advise for this situation.

 

Possibly related to:

1) Best coding practice for this set up / handshaking

2) Time delays between reads functions or write functions or read/write

3) Asynchronous vs Synchronous settings for the VISA modes

4) Re-initializing port periodically?

5) Any other suggestions

 

Thanks,

Tim

[hooovahh]

Generally you open once, do your work, and close once.  Generally you use Synchronous messaging so that you don't need to worry about time delays in reads or writes it just returns the data when it is ready.  Not all protocols support this, but most end with a return character making it relatively easy.  If you are questioning LabVIEW, try writing a simple serial VI that opens, reads/writes and closes then run it for hours to check your sanity.

[infinitenothing]

I'm not sure I've ever seen a port freeze on my dev computer but I know I've heard of freezes in the field. I tell them to call IT.

 

The only timing issue I've had is with flush and what happened was that flush was clearing data from a prior visa write..

 

Are you using NI serial ports? I'm guessing that's going to be more reliable or at least give you a better outlet for troubleshooting.

 

I open the port at the beginning and close at the end. That's never been a problem. I use both sync and async read/writes.

Edited October 8, 2015 by infinitenothing

[LogMAN]

The issue that I come across is that the port get "stuck" at random times.  Sometimes it can run for minutes to 12 hours before the port freeze up.

 

What exactly do you mean by getting stuck/freeze?

Do you have any error message you could post?

 

Also, check if there is any other application or service running that could access the serial port. The MS printing service for example screwed me over a couple of times. Experience might also change depending on your serial device (USB to serial converter, on board controller or PCI(e) cards).

[ned]

I had an application that would stop reading from the serial port (I'd get a timeout, not a "freeze", but I reduced the default timeout time) that was fixed by switching from asynchronous to synchronous, or vice versa. The reads were relatively infrequent (once per second or so) and switching modes had no effect on performance. This was with a cheap USB-to-serial adapter.

[ensegre]

cheap usb adapters are known precisely for that problem, and I run into every now and then. The only cure known to me is to unplug/replug the usb, or reboot the computer. I remember long shaming threads on ni fora, on the topic "but VISA write should timeout". "No, it's not NI's responsibility, it's the driver function". "yes but" and so on.

 

ETA: for instance http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/VISA-Read-hangs-Get-Resetting-VI-dialog-on-abort/m-p/2004797#M53616

Edited October 9, 2015 by ensegre

[hooovahh]

Oh and there is the Windows power settings you may want to check.  Windows can choose to turn off USB ports seemingly randomly to save power.

[Tim888]

Thanks for the replies!

 

This application has been running for the last 18 hours now without issue, so it is confusing. 

 

Currently I am using a "cheap" USB to RS232 converter for development.  I wonder if that has to do with the port getting stuck like a comment mentioned above. 

 

Does anyone have a recommendation on a reliable USB to RS232 converter?

 

To answer a comment above, what I meant by the port freeze/stuck is that it will not respond anymore.  It doesn't seem to be timing out since I'm not seeing lags in the program.  When write commands are sent nothing seems to be processing, and I won't be getting a feedback either.  When I exit the application, it will process through a VISA Clear and VISA Close vi, and they both error out.  I will have to unplug the USB adapter and re-plug it in to get the port to reset.

 

Also does anyone know of a program that can monitor a serial port and possibly diagnose when the port gets stuck?

 

Thanks,

Tim

[ensegre]

Another potential factor is EMI. Supposedly interference may set those chips in odd modes, so improving grounding and shielding might help. But all together, I think the cheapest and fastest option is to try out different usb-232 dongles.

[hooovahh]

Is this cheap USB also plugged into some kind of hub?  I can't remember the details but I know I had some kind of issue where trying a different USB configuration helped on a few small setups using a laptop where we didn't have many options like adding a PCI RS-232 card.

 

As for programs there are several on the net that basically monitor, and log data seen on a COM port.  I haven't personally used this one, but looking at the screenshot it looks similar to others.  This is usually a higher level debug tool, just looking at the messages going back and forth, and probably won't tell you anything about a driver crap out situation.

[LogMAN]

Currently I am using a "cheap" USB to RS232 converter for development.  I wonder if that has to do with the port getting stuck like a comment mentioned above. 

 

Does anyone have a recommendation on a reliable USB to RS232 converter?

 

RS232 is a very old standard, so even the cheapest devices are quite reliable. For long-term acquisitions however USB is a bad coice. Rather go for on-board or PCI(e).

 

If you really have to go with USB, try one of the NI interfaces. They are well made but quite expensive: http://sine.ni.com/nips/cds/view/p/lang/en/nid/12844

In your case however I doubt any of the USB devices will solve the issue.

 

To answer a comment above, what I meant by the port freeze/stuck is that it will not respond anymore.  It doesn't seem to be timing out since I'm not seeing lags in the program.  When write commands are sent nothing seems to be processing, and I won't be getting a feedback either.  When I exit the application, it will process through a VISA Clear and VISA Close vi, and they both error out.  I will have to unplug the USB adapter and re-plug it in to get the port to reset.

 

It sounds to me that the issue is related to the USB connection rather than the device itself. ensegre and hooovahh already mentioned some very likely causes. Such issues might also occur sometimes when connecting another USB device to the same computer.

 

Try to run the application on a computer with on-board RS232. The issue will very likely be solved (if you actually use the on-board RS232 that is )

[MarkCG]

 

 

Does anyone have a recommendation on a reliable USB to RS232 converter?

 

 

usconverters.com

RS232 is a very old standard, so even the cheapest devices are quite reliable. For long-term acquisitions however USB is a bad coice. Rather go for on-board or PCI(e).

 

 

Several times I have worked with folks decide that the way to build a data acquisition or even machine control system is to take a generic windows PC, install the LabVIEW dev system,  and hook up a new and Ebay-ed variety of virtual RS-232 , virtual RS-485, and GPIB device, and maybe a cDAQ chassis to it. Educating them on why this is not a good idea, most of the time, is a never-ending battle which I am not sure I want to even fight anymore.

Edited October 9, 2015 by MarkCG

[Rolf Kalbermatter]

RS232 is a very old standard, so even the cheapest devices are quite reliable. For long-term acquisitions however USB is a bad coice. Rather go for on-board or PCI(e).

 

RS-232 may be an old standard, and pretty hard to do wrong, that can't be said about the USB controller in an USB-to RS-232 converter. They almost all use the same two types of chips and the according chip manufactorer has drivers released that do work (most of the time). But these drivers aren't really industrial quality and are more a reference design that the OEM actually should improve and stress test before releasing a product with that driver. However most no name manufacturers compete on price, not on stability of their product and they release the product as a copy paste design from the reference design of the chip manufacturer with the standard reference design driver. Their only added value to the whole is a more or less fancy casing around the chip and plug.

 

And then you have the manufacturers who actually use a copycat silicon in their products. Their is no guarantee that this product is working the same under all circumstances. EMI and other environmental influences require specific considerations that are not really any concern of those copycat manufacturers. The only thing that counts is to sell as many chips as possible with as little expenses as possible. There is no brand name that can be damaged since their operation only works in the shadows anyways and they have no intention of coming out with their own name for those products as that would be admitting their IP theft and after who the original IP owner needs to go.

 

USB communication can be made pretty reliable but that requires knowledge about both electrotechnical and electromagnetic matters as well as how to write a reliable device driver for any modern OS. And of course about logic design of the chip itself but that is another story.

[Phillip Brooks]

When searching for a USB-RS232 adapter, look for those that use an FTDI chipset. If it has a Prolific chipset, it is probably more like epic ( fail that is  )

 

I recall reading that the Prolific chip is often counterfeitted in China and ends up in the cheaper devices.

 

http://stackoverflow.com/questions/32087482/how-to-diagnose-visa-rs-232-communication-failure-in-labview/32134821#32134821

 

 I've purchased the 6' Sabrent CB-FTDI from Amazon (~$15 US) many times and never had a problem with it.

Edited October 12, 2015 by Phillip Brooks

[Rolf Kalbermatter]

When searching for a USB-RS232 adapter, look for those that use an FTDI chipset. If it has a Prolific chipset, it is probably more like epic ( fail that is  )

 

I recall reading that the Prolific chip is often counterfeitted in China and ends up in the cheaper devices.

 

http://stackoverflow.com/questions/32087482/how-to-diagnose-visa-rs-232-communication-failure-in-labview/32134821#32134821

 

 I've purchased the 6' Sabrent CB-FTDI from Amazon (~$15 US) many times and never had a problem with it.

 

FTDI also gets counterfeited regularly. They had even a pretty bad issue when they released a driver through Windows Update that had specific code in it to clear the USB PID/VID of a chip. For genuine FTDI chips that did nothing since those locations were not writable, for counterfeit chips it cleared the PID/VID and made the chip unusable, although with some low level tools one could fairly easily reprogram them back to a working state, at least if you used a Linux computer for that, On Windows it was more complicated and generally beyond most users ability.

 

People got really mad at FTDI, with many promising to never again buy anything that contains FTDI chips, which is strictly speaking a bit hilaric since they didn't buy anything containing real FTDI in the first place already. 

 

That the real culprits really are the copycats who sell cheap chips with the FTDI logo and saving engineering costs by making the chip use the original FTDI device driver is of course another story that is hard to sell to the average computer user.

[OlivierL]

We ran into a situation many months ago when a new device was added to a system and communication was done through a cheap FTDI interface chip. We ended up having BSOD at random intervals ranging from minutes to hours. It was easy to troubleshoot and we replaced the adapter with an industrial grade USB-Serial device (Moxa) before switching to a PCIe card (because it was cheaper.)  That simple change fixed everything. We'll never know what the driver was doing but there are many things that might go wrong with Prolific/FTDI, including the counterfeit parts that others have mentioned.

 

I'm definitely bookmarking this thread for future discussions with clients who don't like to invest for quality hardware. It seems like most of us have had our share of stories with cheap USB-Serial interfaces.

 

Tim, all this being said, if you have en error on your VISA Close, there may be something that needs to be addressed in your code. If you can post it, there will likely be someone looking at it and provide you with a better feedback. Finally, if you can mention the error codes that you are seeing, it makes things easier to troubleshoot and helps other find this thread if they face the same problem.

[bublina]

Does anyone have a recommendation on a reliable USB to RS232 converter?

 

 

Tim

 

If reliability is the #1 factor, I recommend Advantech ADAM serial device server. It basicly converts your rs 232 device into an ethernet one and you can use native labview ethernet functions. I have had many issues with serial comms and LabVIEW including hangs, bluescreens (even on w7), all kinds of weird behavior etc.

 

The device is quite costly, I think something around 150 euros, but I only have sane experience with it.

[Rolf Kalbermatter]

If reliability is the #1 factor, I recommend Advantech ADAM serial device server. It basicly converts your rs 232 device into an ethernet one and you can use native labview ethernet functions. I have had many issues with serial comms and LabVIEW including hangs, bluescreens (even on w7), all kinds of weird behavior etc.

 

The device is quite costly, I think something around 150 euros, but I only have sane experience with it.

 

I would questions someones engineerings abilities who finds 150 Euros to be expensive for something which can make the difference between a properly working system and one which regulalry looses communication and/or trips the computer in a blue screen of death. If an engineer has to spend two hours to debug such an error caused by a noname serial port adapter then the more expensive device has paid itself already more than once. And two engineering hours are just the top of the ice peak, with lost productivity, bad image towards the customer and what else not even counted in.

[OlivierL]

I would questions someones engineerings abilities who finds 150 Euros to be expensive for something which can make the difference between a properly working system and one which regulalry looses communication and/or trips the computer in a blue screen of death. If an engineer has to spend two hours to debug such an error caused by a noname serial port adapter then the more expensive device has paid itself already more than once. And two engineering hours are just the top of the ice peak, with lost productivity, bad image towards the customer and what else not even counted in.

Rolf, I agree with you but some managers seem to really like the gamble of the 10 Euros one which has 90% chances of working just fine, especially if a system failure has little consequences. For the times where we can't convince the clients to get the better one from the start, we keep a few reliable devices on hand and swap them at the first sign of trouble and we no longer spend time debugging until the devices have been swapped. That seems to a strike a good balance that pleases everyone.