Serial Port Read hang in Labview DLL read by Visual Basic

[N30N_Days]

Hello,

I maintain a program written in Visual Basic that makes use of Labview DLLs, which handle serial port communication with our hardware.

Recently, the Visual Basic sofware (which reads and feeds data from and to a database) was updated; everything stayed the same, except for the read/write server location. There are XML files for each computer with the serial port configuration settings, and these stayed the same too. When the updated program was released, all computers on-site worked.

In the past, we would receive an error from the VB software, which handled error messages from the DLLs. The error occured when the software unexpectedly failed to receive databits from the hardware. This would be solved with a restart.

An off-site location is now receiving this error, on all computers. Restarts haven't affected it. If the computers revert to the old software, everything works. I've never changed the Labview DLLs; they were built long before I inherited the software.

When attempted to monitor the serial port, it experienced a Read hang.

These computers have not been updated in some time, unlike the ones on-site that are currently working. Is this a driver issue? The serial port configuration hasn't changed.

I've tried disabling the port and reinabling it to fix the hang, but this didn't appear to work. I didn't restart afterwards though.

We'll hopefully hire in a contractor for this issue, but I'm looking to gather as much information as possible. Any similar examples are welcome.

I'll return to the forum with information on our computers' version(s) of Windows tomorrow morning. What are some common Windows serial port and Labview communication errors, and their causes? Would updating NI-Visa fix the issue, even though their computers' version haven't changed between our software updates?

[RTSLVU]

---

Would updating NI-Visa fix the issue, even though their computers' version haven't changed between our software updates?

---

Maybe... I have seen serial comunication isses crop up when the development machine has a newer version of NI-VISA than the target machine.

Updating the target machine VISA to the same or newer version as the development machine fixed it.

[N30N_Days]

I installed Portmon, and monitored the port while accessing the hardware via the program.

The program 

The first section composed of Read/Purge/Write/Buffers is the program moving the hardware to its target area. The large section of red is when the program Reads data from the hardware, and then graphs it. It's all labeled as successful; however, the hardware will either not move far enough, or it will continue moving, and the program fails to graph.

[N30N_Days]

It should also be noted that the program's installer does not install the program itself; it installs an executable that will copy all needed files from a server location.

Also, all computers with this issue are configured for French. 

[N30N_Days]

More information:

I swtiched the computer's language settings from French to English.

The program appears to be writing correctly.

I'm not sure if this a configuration, or a driver issue between languages. Any ideas?

[rolfk]

Most likely your LabVIEW code in the DLL doesn't use an explicit decimal point but rather relies on the system decimal point. Different languages use different decimal points, often the comma in many European locales.

LabVIEW string functions by default will honour the settings of the system locale. You can however force them to use a decimal point. Alternatingly you can place an ini file in the application folder with useSystemDecimalPoint=false or something similar in it to force ALL string functions to use the decimal point by default. However I'm not sure about the location nor the Format of that ini file for LabVIEW DLL's.

Best however is to use the Format and Scan from/to String functions and prepend the Format string with %.; in front.