Serial - Bytes at Port returns 0

[OU812]

Using: LabVIEW 6.1

I have an application that runs perfectly, nearly every time. Data is properly collected, evaluated, everything.

The problem is an intermittent failure to collect any data at all.

When the problem does occur:
I have verified with a hard monitor that data is indeed streaming to the serial port, but when I use the VISA Bytes at Port property node, it returns zero bytes. Data is there, but bytes at port returns 0. Loop, wait, loop, wait, the property node returns 0 bytes at port every time. If I restart the software and run it the same way again, the property node works just fine. No error is reported out of the property node, nor are there any errors going into the node. The port's VISA Resource Name is a constant fed into the property node, so nothing funky seems likely there. Basically the property node seems to just not work. There are no initialization errors and all initialization parameters are correct for the data coming to the port.

In short: Port initialization had no error, Data IS there at the serial port, and inputs to the property node are correct, yet the property node returns 0 bytes.

Initialization parameters: Enable Termination Character = F, Timeout = 1000, Baud = 38400, Data bits = 8, Parity = even, Stop bits = 1.0, Flow Control = None

Is there any known issue with that property node where it has exhibited that behavior in the past? Perhaps a problem with the drivers in LabVIEW? My searches have come up dry. I am at a complete loss for possible solutions, and the customer never likes to hear the words, "Oh, just restart it, it'll work fine then."

Thanks for any input anybody can give me on this one.

[waldemar.hersacher]

What type of COM port are you using? Is this a USB or ethernet adapter for COM ports? One of my customer tried the same USB2Serial adapter we use here successfully with our machines. He reported me that he has at least one laptop where it doesn't work. He bought some from an other vendor and it works with no problems.

How long does the application run before this effect occurs? After minutes or after hours?

Which LV and VISA-Version do you use. In the development environment or as build application?

He is using a LV 6.0.2 build application with VISA 3.0. I know from him he runs it on exhibitions all day long (at least 6 to 7 hours).

[LoganS]

You might also take at look at the following discussion forum:

Problem in using serial port

The timeout issues mentioned may not be applicable, but the issues of your application possibly running faster than your instrument is sending data may help (first two paragraphs of response).

[OU812]

COM port is: Serial Connector (EIA-RS232D)

I am using:
LabVIEW 6.1
National Instruments NI-VISA(TM) Software for Windows. Version 2.6.

It is built as an application, but I see the same behavior running it off of the source code on the same laptop.

The software runs for a variable amount of time (could be seconds, could be hours) just waiting in a loop until commanded by another system (through TCP) to begin collecting data. It then initializes the serial port and begins collecting data as described above. When commanded to begin data collection, it is verifed (through independant hardware monitor) that data is absolutely on the port.

I don't think it is a matter of how fast I am polling to read the port. If the byte count is 0, it reads 0 bytes, and loops. Eventually it should have data at the port, but when the error occurs, there is always a 0 returned. It will return 0 indefinitely. I have paused it, waited a second, and un-paused, and it still reads back 0 bytes at port. Meanwhile, you can see the data right on that port via the independent hardware monitor.

This is a rare thing when it happens, perhaps one in about 50 times, or so. Most times, it will see data at the port, collect it, repeat. But, if it happens, it will not see data at the port no matter how long you wait. It never starts collecting data because the property node returns 0 bytes at port. In any case, it is verified that data is indeed at the port as expected.

Again, thanks for any help. It's certainly a perplexing problem.

[OU812]

My apologies, I forgot to mention the most basic thing: it is running on Windows 2000.

[tst]

Do you get an error out of the property node or just the 0?
If you close the port and open it again when this happens, does it help?
If it does, you can programmaticaly do this every X time and see if that helps.
It's ugly, but if it works...

[OU812]

In every instance that I observed, there was no error going into or coming out of the property node.

I may try that if it is my last option, but it is policy to run bugs down to their root cause. If it comes down to the native Labview function call as the root cause, and there is no other solution, then I may do things to circumvent the problem within my code... but the justification for that has to be both solid and resonably well-documented.

On another line of thought, what is the newest (best?) NI-VISA version one may use with LabVIEW 6.1 on a Windows 2000 system? It would be very convenient if I could upgrade the driver software and this problem disappeared, or at least happened much less frequently. (I read the release notes for bug fixes and known issues and none of the documented fixes or known issues -seem- to apply, but stranger things have happened)

[tst]

---

@OU812 wrote:
In every instance that I observed, there was no error going into or coming out of the property node.

---

OK. That's a start. It means LV recognizes a problem with your serial comm. What was the error?
You can use the detection of the error to close and reopen the port, like in the attached image.
You should also try logging when the error started. It might give you a clue as to what's caused it.

EDIT
Sorry. I thought you said there was AN error. You mean that you looked when the problem happened and there was no error? If so, ignore the beginning of this post. In any case I would suggest you try logging errors and see if you get anything.

Message Edited by tst on 03-15-2005 10:04 AM

[shoneill]

I do recall reading of a case where the ground potential of a laptop can vary to that of the serial line of the "sending" instrument. This leads to a decrease in the pulse height observed by the serial controller chip which can, in some cases, result in the hardware simply not picking up the signal.

I've never encountered this myself, but I AM aware that serial communication on a laptop can be prone to more problems that with a desktop. Try measuring the ground of the laptop versus the ground of the instrument sending the data. If there is a significant difference, this might be leading to lost data packets. You might also see a difference if the laptop is running from a battery or from the mains (If this is indeed the problem).

Once again, this is just something I've read. No personal experience attached.

Hope this helps

shane.