nowbotgogo

• Labview Download

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 / handshaking2) Time delays between reads functions or write functions or read/write3) Asynchronous vs Synchronous settings for the VISA modes4) Re-initializing port periodically?5) Any other suggestionsThanks,Tim. 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. 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). 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.

Labview Download

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, 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. 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: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 ). 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. 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. 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.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.

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. Does anyone have a recommendation on a reliable USB to RS232 converter?TimIf 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. 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. 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.