Trouble reading RS-232 output from a Granville-Phillips 358 Micro-Ion Gauge using a serial to Ethernet converter.

[MilesT]

I've been attempting to read output from a Granville-Phillips 258 Micro-Ion Vacuum Gauge Controller in LabView. I am using a StarTech RS-232 Serial over IP Ethernet Device Server to send serial communication over Ethernet. Serial output comes from the Micro-Ion Gauge out of a DB25S connector. I have a wire running from that into the DB9 port on the serial to Ethernet converter. From there it runs into the computer. The serial to Ethernet converter comes with software called VCOM that i'm using to create a virtual COM port. I then use NI MAX to recognize the COM port. In LabView, I have a VI thats identical to the "Simple Serial" tutorial program that NI provides. In my VI I configure the serial port with all defaults except for the control flow, which is set to RTS/CTS. The Micro-Ion Gauge is set to a command-response system by default, so as per the manual, I send "DS CG1 \r\n" in a string constant over the virtual COM port. This should have the gauge send the reading on its display. The program waits 500 ms before using the bytes at port property node and reading that many bytes at the COM port. Every time I run the program zero bytes are read. The serial to Ethernet converter is recognized by the computer and VCOM program. The lights on the converter indicate that data is being sent to the ion gauge, but none is being received. I am using LabView 2019.

Attached is a picture of the VI.

Sorry for the sloppy VI and the wall of text, and thank you for any help!

[MilesT]

Note: When I replace the read at bytes property node with a constant, I get the error -1073807339 (read timed out)

[MilesT]

It appears that the manual was unclear about input formatting. Issue solved.

[BertMcMahan]

Might not be a bad idea to record what exactly you did to fix it for future Googler's.

[GenTek]

I have the same issue trying to read data back from a Granville Phillips 358 gauge controller.  Your post mentions that the manual was unclear on how the unit is expecting input (ie. com settings).  Can you reply with your fix?

Thanks

[MilesT]

Hello,

unfortunately I have still not found a fix for this problem. I have been talking to MKS support of quite some time about the issue, but to no avail. Most recently one of their engineers suggested switching the RX and TX lines on the input cable. It didn't work for me, but its something you could try. 

[OregonGumby]

You should simplify your setup to identify where the problem lies.  Connect straight to a PC with rs232 port and see if you can communicate.  Once you have that working, you can try to implement the rs232 to ehternet.

[MilesT]

Already tried that unfortunately. 

[jimmybull20]

Any luck getting this instrument to respond? I have the same issue. I have been trying all possible setting and modifications. I cannot get any data back. 

[rolfk]

---

@MilesT wrote:

The Micro-Ion Gauge is set to a command-response system by default, so as per the manual, I send "DS CG1 \r\n" in a string constant over the virtual COM port.

---

The most common problem is, that the string constant is set to Normal display mode. The \r\n is the usual escaped way to indicate <carriage return><line feed> characters. But if your string control or constant is in normal mode, you are literally sending \r\n (4 characters) to the device instead of <carriage return><line feed> (2 characters).

Most devices are implemented in a way that they only start to parse the incoming string once they see either the <carriage return> or <line feed> character, or both. And since you are not sending that it sits waiting, ... and waiting, ... and waiting .... ⏲

Right click on that constant and select '\' Codes Display. Correct the string to only have one backslash each instead of the double backslash you will most likely see now.

Right Click again and select Visible Items->Display Style. Now a glyph appears that indicates the display mode of the string constant or string control, so nobody (including yourself when you look at this program again in a few weeks) has to guess if you are using the right display mode.

Since the OP only showed an image, instead of the actual VI, nobody can know if the right display mode was used and suggest to correct it but we have to guess that that might be the problem. And other users will carefully copy the image and run into the same problem!