VISA Serial: Setting DTR State and RTS State to "Unasserted" solves RS232 communication issue; why?

[onnodb]

Over the past few days, I've been struggling to get a pair of Zaber linear actuators to work with LabVIEW after a computer and LabVIEW upgrade. The Zabers communicate over the serial port (RS232), which worked perfectly fine on the old (but deceased) XP computer with LV 8.6. With a Win7 PC with LV 2010SP1, this suddenly didn't work anymore. To add to the puzzle, the native software provided by the manufacturer did work correctly.

Using the Microsoft/SysInternals PortMon software, I was able to peek into the serial communication (highly recommended debugging tool, btw). There were some differences between my LV software and the native software, so I tried many things in LV to try and fix the issue.

In the end, the change to the code that made the communication with the Zabers work is shown in the image below. The part in the enabled Diagram Disable structure fixes the serial communication with the Zabers; disabling this code breaks it.

Now my question is: I don't have the faintest idea why this would fix it. If I understand correctly, this property node manually turns off the DTR and RTS lines on the serial cable; is it common for apparatuses like this to be sensitive to those channels? I've been reading up a bit on RS-232 communication, but does anyone here have a simple explanation for what might be going on?

Thank you very much in advance!

[MoReese]

There is no pic attached.

[Wayne.C]

Image is missing.

Quite the echo this AM 

[onnodb]

Oops, my apologies. I was sure it was there in the Preview when I posted it... Anyway, thanks for the heads up 🙂

[MoReese]

I'm not exactly sure.  But since you are not using flow control, it shouldn't matter what your handshake lines are doing.  Are both unasserts required, or will it work with just DTR?  How is your DCE setup?  Does it have flow control disabled?  Check your communications setup on your Zabers no ensure they match the Visa setup.  It may be your Zabers are looking for a handshake signal.

[Henrik_Volkers]

---

@onnodb wrote:

Now my question is: I don't have the faintest idea why this would fix it. If I understand correctly, this property node manually turns off the DTR and RTS lines on the serial cable; is it common for apparatuses like this to be sensitive to those channels? I've been reading up a bit on RS-232 communication, but does anyone here have a simple explanation for what might be going on?

Thank you very much in advance!

---

Most likely because the RS232 driver in your device is powered by the DTR and/or RTS line. That way they avoid the +-10-15V powersupply they would need to build to correctly drive the Tx line.  This is a quite common hack 😉 but should be noted in the manual.

Shure that the old program /setup/OS didn't set it?  Also possible, that the old PC was more tolerant about line levels...

[onnodb]

---

@MoReese wrote:

I'm not exactly sure.  But since you are not using flow control, it shouldn't matter what your handshake lines are doing.  Are both unasserts required, or will it work with just DTR?  How is your DCE setup?  Does it have flow control disabled?  Check your communications setup on your Zabers no ensure they match the Visa setup.  It may be your Zabers are looking for a handshake signal.

---

Thanks for sharing your thoughts on the matter!

It's hard to say what exactly the Zabers are expecting — I've strictly followed all the available documentation. Also, there's no way to configure the Zabers: it seems that the whole thing is pretty much 'hardcoded'. In any case, both unasserts are required; if I have only one of them, the Zabers don't respond to any commands.

[onnodb]

---

Henrik Volkers wrote:

Most likely because the RS232 driver in your device is powered by the DTR and/or RTS line. That way they avoid the +-10-15V powersupply they would need to build to correctly drive the Tx line.  This is a quite common hack 😉 but should be noted in the manual.

Shure that the old program /setup/OS didn't set it? 

---

Now that's an interesting thought! Indeed, the manual describes that the Zabers can optionally be powered by the serial cable. The strange thing is, though, the all the time an external power supply has been plugged in. Maybe the Zabers are programmed to try and use the DTR/RTS power if available, even if an external power supply has been connected? That's what my guess would be then... And then unassigning the DTR + RTS lines forces the Zabers to switch to the external power supply.

---

@Henrik Volkers wrote:

Shure that the old program /setup/OS didn't set it?  Also possible, that the old PC was more tolerant about line levels...

---

Yes, positive! But the old PC had an on-board serial port, whereas right now we're using a USB-to-serial converter (it's nigh impossible to find modern PCs with on-board serial ports). That might explain the whole thing.

Thanks a bunch, I feel this may explain a lot!

[MoReese]

Then this information should be in the user manual for the Zabers, as Henrik stated.  But it does sound like the Zabers are doing something different with those lines.

Edit: Woops!  A bit late on my reply.

[onnodb]

I completely agree. I will contact them, and get back to this topic when I get a reply from them!