RS232 Serial Device - Damaged port diagnosis, partial return message

[Tex85]

I have a serial device which is not behaving as expected. I have a duplicate device which I am comparing against, which is behaving as expected. My goal is to understand if the device is damaged, and the way in which the device is damaged. I do not have access to an o-scope at this time, but will pursue access in the near future. I am using the exact same VI, serial port and serial cable across both devices.

I've attached the LV program I am using to send a serial command using Visa tools. I am censoring the device manufacturer information below.

With the "good" device, sending *IDN?\r will return:

"DEVICE,V123,25041,v1.27"

With the "bad" device, sending *IDN?\r will return:

"D"

However, sending *IDN?\r\r will return:

"DE"

By adding multiple term chars, I will get an equal number of additional characters from the IDN command with the "bad" device. I've tried different flow control settings, different bauds, \r\n as the term char. At one time, this device was performing as expected. This is new behavior. I am using a full handshake crossover cable.

I realize that by setting the term char in the visa settings, I do not also need to add to the message string. I have found that having term char in both settings and message string does not affect the overall performance of the communication.

Device Specs:

Baud Rate 9600, 19200, 57600 or 115200
Handshake Bi-directional, hardware (RTS/CTS)
Data Bits 8
Parity None
Start/Stop Bits 1
Connector 9-pin Male Dsub
Interface Pinout Type DTE (same as PC computer)
Cable required 9-wire female-female null modem cable, fully wired
Cable Length <50ft (per standard)

[RTSLVU]

What is the device in question? I ask because I have similar issues with California Instruments programmable AC power sources. Units that worked flawlessly for years now occasionally do not respond correctly to the *IDN? command. Usually it is an incomplete response like you are getting.  

I resorted to multiple queries when the first one fails.

[Frozen]

---

@Tex85 wrote:

using the exact same VI, serial port and serial cable across both devices.

I assume you have tried resetting the device to factory defaults?

I would also try resetting the working unit to factory defaults.

You have not mentioned how old the unit is. It might be a device problem, if it is very new or very old.

Good luck.

[Tex85]

I'm not sure why I'm being coy about the device. Its a Vitrek brand V71 hipot device. Device was in use for 8 months, 300+ uses a day, no issues.

[Tex85]

Device is from 2021. We have seen similar issue in units from 2024.

I have set to factory defaults and also reflashed the firmware (from v1.27 to v1.27, not a fw update).

[RTSLVU]

---

@Tex85 wrote:

I'm not sure why I'm being coy about the device. Its a Vitrek brand V71 hipot device. Device was in use for 8 months, 300+ uses a day, no issues.

---

Interesting... It's possible the port was damaged by repeated high voltage pulses induced onto the serial cable. We had a HV surge generator that was remote controlled via RS-232 in our lab. If we didn't use the heavily shielded serial cable that came with it, the pulse would induce a voltage onto the serial cable and crash the computer running it.

[BertMcMahan]

Since it seems like the device is responding to carriage returns, then it appears it's getting info into the internal buffer but just not sending it. Which sounds like a flow control problem to me.

From the user manual, it should default to RTS/CTS flow control by default:

Your code doesn't enable flow control, so I'd guess you somehow disabled flow control on one unit and not the other. Either enable flow control in your LV program, or disable it on the device (not sure if you can or not).

Also, the manufacturer has LabVIEW drivers on their website- have you tried those? (not that mfg. drivers are usually all that helpful... lol)

[BertMcMahan]

Just saw in your top post you did specify the settings, but look at this selection here:

Change it to this:

[rolfk]

---

@Tex85 wrote:

I'm not sure why I'm being coy about the device. Its a Vitrek brand V71 hipot device. Device was in use for 8 months, 300+ uses a day, no issues.

---

A HiPot device, and erratically working serial port!!! Sounds familiar!

Those devices produce extreme voltage transients that even a perfectly engineered device has trouble from preventing to reach the low voltage part with the microcontroller and serial port, network interface etc. Basically we always used an optical isolated serial interface. And no, not the ones that just have an opto isolator built in but actual fiber cable over a considerable distance of the connection!

Anything else tends to cause problems sooner or later. There are many possible problems, even changing the test setup by rearranging the devices can suddenly cause problems.