LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

RS232 Communication for Inficon Leak checker UL3000

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 is finished with the end sign CR (ASCII code 13dec/0Dhex). There is no differentiation between 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.

0 Kudos
Message 1 of 17
(553 Views)

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

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 2 of 17
(541 Views)


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:

Kyle97330_0-1721862147301.png

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

Kyle97330_1-1721862331682.png

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?

0 Kudos
Message 3 of 17
(504 Views)

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?.

0 Kudos
Message 4 of 17
(473 Views)

Hi Santhosh, 

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

0 Kudos
Message 5 of 17
(466 Views)

@rosh wrote:

Hi Santhosh, 

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


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 .

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 17
(461 Views)

@JÞB wrote:
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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 17
(457 Views)

@crossrulz wrote:

@JÞB wrote:
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. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 17
(446 Views)

Per the documentation, the default setting for termination character on serial writes is to do nothing:

Kyle97330_0-1721952937705.png

 

If you look at the block diagram of "VISA Configure Serial Port (Instr).vi" you can see in it that it doesn't set the End Mode for Writes property, just the one for reads:

Kyle97330_1-1721953044650.png

As such, running this code shouldn't be sending two termination characters.  Even if it did, it shouldn't get a "framing error" as the problem.

 

For the actual framing error issue, using the wrong baud rate is the most common problem, yes.  You said you got this to work with Hyperterminal, can you confirm that both it and LabVIEW are set to 19200?  Hyperterminal defaults to 9600 if I remember right, so if you didn't set it there then it could be that someone manually reconfigured the UL3000 to use 9600 baud.

0 Kudos
Message 9 of 17
(420 Views)

Hyper Terminal Port Settings.pngHyper Terminal ASCII Setup.pngHyper Terminal Programming.pngHyperTerminal - Settings.pngSimple Serial 2.pngSimple Serial .png

0 Kudos
Message 10 of 17
(393 Views)