RS232 Communication for Inficon Leak checker UL3000 (2024)

rosh

Member

I am having difficulties trying to establish RS232 Communication with an Inficon Leak Checker - UL3000. I am able to send commands via Hyper-terminal but I can't communicate via Labview.

A few of the commands I was able to send using Hyperterminal was "*start", "*stop", "*read?"

I got this information from their programmer's manual: "In ASCII protocol any command starts with « * » (ASCII code 42dec/2Ahex) and isfinished with the end sign CR (ASCII code 13dec/0Dhex). There is no differentiationbetween upper and lower case."

I am using the "Simple Serial.vi" from the Labview examples (19200 baud, 8 data bits, no parity, 1 stop bit). I tried the commands with \n and \r at the end and still no luck.

Any help would be greatly appreciated.

0Kudos

santo_13

Trusted Enthusiast

Please share your VI (in v20.0 or older) and attach the instrument programmer's manual.

0Kudos

Kyle97330

Trusted Enthusiast

I used a UL1000 before which I believe uses the same protocols. It was about 4 years ago so while I still have my code, it's not fresh in my mind.

This was my VISA initialize:

This is part of the subVI I made to send queries to the device:

I don't have access to the device to try to find out why the "Simple serial" example modified wouldn't work while these did.

Do you just get a timeout error on the"Simple serial" example or is it something else?

0Kudos

rosh

Member

I am getting this error "Error -1073807253 occurred at VISA Read in Simple Serial.vi
Possible reason(s):
VISA: (Hex 0xBFFF006B) A framing error occurred during transfer."

I modified the vi to match yours and still getting the same error.

What's the syntax of the command/query you use? I am trying these commands *start, *stop, *read?.

0Kudos

rosh

Member

Hi Santhosh,

I am unable to upload any files from my work computer. My program is identical to the picture posted byKyle97330

0Kudos

JÞB

Knight of NI

@roshwrote:

Hi Santhosh,

I am unable to upload any files from my work computer. My program is identical to the picture posted byKyle97330

That might be the problem.

Kyle wrote some obfuscated code. First the term char constant on the init really should be showing the radix (right-click show radix) so we can see that "13" is 0x0D. Then, since the default is to enable sending the term char, adding another EOL constant will send <EOL><CR> that's two terminations, (of course a framing error!) Lastly, <EOL> is platform dependant and may be CR,LF or CR .

0Kudos

crossrulz

Knight of NI

@JÞBwrote:
Then, since the default is to enable sending the term char, adding another EOL constant will send <EOL><CR> that's two terminations, (of course a framing error!) Lastly, <EOL> is platform dependant and may be CR,LF or CR .

An incorrect termination character will not cause a framing error. A framing error is at the hardware level, meaning the UART frame for a single byte was wrong. This points to a setting error, typically the Baud Rate.

0Kudos

JÞB

Knight of NI

@crossrulzwrote:

@JÞBwrote:
Then, since the default is to enable sending the term char, adding another EOL constant will send <EOL><CR> that's two terminations, (of course a framing error!) Lastly, <EOL> is platform dependant and may be CR,LF or CR .

An incorrect termination character will not cause a framing error. A framing error is at the hardware level, meaning the UART frame for a single byte was wrong. This points to a setting error, typically the Baud Rate.

Tim, Those devices "Step on their own toes" when receiving multiple term Characters. Just as the silly Firmware Engineer wrote the code to do. Been there Done that when you were in diapers (at least you were really young)

The second term char raises an interrupt and the serial port just plain hangs for moment, even in the middle of writing a character. Nasty thing.

0Kudos