Errors in VISA read using RS-232

[martin.berg]

Hi,

I am working on setting up a continuous reading of data from a neutron detector that automatically send messages every 2 seconds using RS-232. The problem I'm having is that the received messages contain many errors as observed below:

 ´0rn8!w×~/h`000.0 uSv/h
<00.v ÿSv/h
00p.0,uSv/h
°0p.0!uSv/h"002/2!uSv/h$°8°®0 uSv/i!000.1 õSvoj
040.°"}Sv/è(204n0`uSv/è

I get, however, messages of the correct nature using another terminal software for the RS-232 interface (Termite 3.3) using the exact same serial settings (baud rate, parity, flow control, stop bits, data bits) as in the labview program: 

000.0 uSv/h
000.0 uSv/h
000.0 uSv/h
000.0 uSv/h

When comparing the actual bits of the received messages from Labview and termite there seem to be random bit errors resulting in the wrong ascii code.

I have tried using both Labview 16 and 13 (attached) 32 bit on Windows 10 64 bit. I am using a MOXA uPort 2410 as a serial-USB interface between the PC and a neutron monitor. Does anyone have any insight into this type of error or any suggestion on how to proceed. Any help is much appreciated. 

[Blokk]

Read the manual of that Neutron detector. What is the termination character you need to use? 99% of the cases, the "Bytes at Port" approach is the wrong way to do communication from LabVIEW.

So try to use the specified termination character, and delete that "Bytes at Port" property node. Set a large enough (that any msg fits into it) byte count intput for the VISA Read. Also delete that 500 msec Wait from the While loop. Beside, you mentioned your detector sends data at every 2 seconds. So you need to specify a somewhat larger Timeout for the VISA Configure Serial Port, see the snippet below, I set 4000 msec value for it.

[Borjomy]

The presence of other symbols in the message indicates a poor quality of communication at the wire level. somewhere bad contact (there may be problems with connecting to the ground), or guidance.

[Blokk]

---

@Borjomy wrote:

The presence of other symbols in the message indicates a poor quality of communication at the wire level. somewhere bad contact (there may be problems with connecting to the ground), or guidance.

---

This does not explain why he gets proper data in that terminal software, using the same wires...

[Borjomy]

In this case, something is wrong with the speed (for example, the actual transmission speed is slightly different from the settings). This happens if you use a board that allows you to more flexibly adjust the speed, not just standard sets. As already written blokk, the function "Bytes as port" when using the terminal symbol is used incorrectly. Take it away. The read function itself reads the string before receiving the terminal symbol. The maximum size of a string is specified by "byte count".

[Borjomy]

What is your samplerate? And specify the parity parameters after all. It can also be that a specific bit is used (the parity bit is normally off, set to "N"). But manufacturers of specific equipment can use non-standard settings.

[Bob_Schor]

Some of us have enough grey hair to remember wiring DB25 and DB9 connectors for serial communication.  We also remember that "parity" is an important concept, as is the number of data bits.  When you get some characters that "look correct" and some that look strange, it is often an incompatibility between Sender and Receiver on whether they are sending/receiving 7-bit or 8-bit characters, and whether the Parity is Off, Even, Odd.

Finally, check to be sure that both sender and receiver agree on the number of Stop bits (the usual number is 1).

Bob Schor

[martin.berg]

Thanks for the response and the information regarding the use of the "Bytes at Port" node. The manual for the neutron detector makes no mention of the termination character, but I did look found a Carriage return when studying the received bytes in the Termite terminal program. I changed accordingly, including the earlier suggestions, but the same type of messaging errors remain. 

[martin.berg]

I use the baud rate of 9600 but I have also tried 4800 and 1200, changing both the com port settings in windows, Labview and the tool. For the setting I've gotten to work in the Termite software is:

Baud rate: 9600

Data bits: 8

Stop bits: 1

Parity: none

Flow control: none

These setting should then work in Labview as well but maybe there is something else in the message that is filtered out in Termite. I will look closer on the received message in Labview and see if I can figure it out. 

[billko]

---

@martin.berg wrote:

Hi,

I am working on setting up a continuous reading of data from a neutron detector that automatically send messages every 2 seconds using RS-232. The problem I'm having is that the received messages contain many errors as observed below:

 ´0rn8!w×~/h`000.0 uSv/h
<00.v ÿSv/h
00p.0,uSv/h
°0p.0!uSv/h"002/2!uSv/h$°8°®0 uSv/i!000.1 õSvoj
040.°"}Sv/è(204n0`uSv/è

I get, however, messages of the correct nature using another terminal software for the RS-232 interface (Termite 3.3) using the exact same serial settings (baud rate, parity, flow control, stop bits, data bits) as in the labview program: 

000.0 uSv/h
000.0 uSv/h
000.0 uSv/h
000.0 uSv/h

When comparing the actual bits of the received messages from Labview and termite there seem to be random bit errors resulting in the wrong ascii code.

I have tried using both Labview 16 and 13 (attached) 32 bit on Windows 10 64 bit. I am using a MOXA uPort 2410 as a serial-USB interface between the PC and a neutron monitor. Does anyone have any insight into this type of error or any suggestion on how to proceed. Any help is much appreciated. 

---

Some USB to RS-232 adapters don't play well with LabVIEW.  Try using an adapter with an FTDI chipset.