RS232 Communication for Inficon Leak checker UL3000

[rosh]

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.

[santo_13]

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

[Kyle97330]

---

---

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?

[rosh]

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

[rosh]

Hi Santhosh, 

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

[JÞB]

---

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

[crossrulz]

---

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

[JÞB]

---

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

[Kyle97330]

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

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:

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.

[rosh]