Executable with RS485 communication works on some, but not all PCs?

[bgalfond]

Hello! Bit of a moonshot, as I'm not even sure this a LabVIEW issue. I am trying to communicate with a Brooks MFC and using their sample library. The only edits made are the device ID. On one laptop (Win 10) communication succeeds and everything works perfectly. On another laptop (Win 10) and a desktop (Win 7), the communication fails ~80% of the time.  The two errors I get are "-11, Device Did Not Reply" (~40%) and "-15, CheckSum Error on COMs Error Message" (~40%).

Same vi's and executables. Same COM port settings in device manager (Baud, parity, etc). Same drivers. Behavior the same with two different USB-to-RS485 adapters from different vendors. I tried reducing the baud rate thinking that maybe the other laptop and older PC are too slow, but that didn't solve anything. Any Ideas on what the issue is or even what I could test next? Thanks!

Baud: 19200

Data bits: 8

Parity: Odd

Stop bits: 1

Flow Control: none

[ZYOng]

You can Test Communication with VISA Interactive Control

If you are unsure what command to send, you can Performing a Good NI I/O Trace Capture for Debugging/Troubleshooting

[Bob_Schor]

It might help us to help you if you attached the code that handles the COM port, including initialization.  Please note we are much happier when VIs are attached, and many of the "experienced" Forum users (myself included) are not using the latest version of LabVIEW -- doing a "Save for Previous Version" and specifying LabVIEW 2019 should reach (almost) all of them.

I'm curious about the RS-485 settings.  One thing that Brooks doesn't mention in the manual I downloaded was Parity --- N-8-1 (where N = No parity) might be preferable to Odd (or Even) parity ...

Bob Schor

P.S. -- I was going to say "Have you tried testing it with MAX", but I see @ZYOng beat me to it.

[DavidBoyd]

Ditto on what @Bob_Schor said about the character formatting...specifying eight data bits and ANY parity (rather than "none") results in a character that is just a bit too long to be customary; I generally only see even/odd with a (now rare) 7-data-bit selection.  But, whatever Brooks specifies (if they bother to).

However, RS-485 is just one more wrinkle in this setup.  You haven't really mentioned anything about whether it's two-wire or four-wire.  If two-wire, you really do need to make sure your port driver is configured to use the setting where the transmitter is gated on/off during sending while the receiver is simultaneously disabled. Frequently this is labeled as something like "TxAuto" or "TxReady" (varies with serial driver nomenclature).  Polarity is another variable (RS-485 is a balanced line), but since you're telling us you get results back 20% of the time, I'm inclined to think, polarity of wiring is right, but perhaps transmitter driver isn't being gated on/off, and is stomping on the MFC's reply.

Best regards,

Dave

[JÞB]

David is getting close here according to the magic 8-Ball. 

RS 485 requires a balanced pair phy layer.  That also means that a specific characteristic impedance must be set.  

~~~Oh, magic 8-Ball...does the system have the correct termination resistors installed correctly?~~~

"It is uncertain."

Go check the physical layer of the RS 485 coms and the device manual.

[DavidBoyd]

Welll-ll-ll-l, Jay, I might have to agree-to-disagree slightly with you here.  For the typical wiring lengths and glacially slow baud rates (57.6kbaud and below, I'll stipulate) that I encounter, termination resistors are completely unnecessary.  You just can't get big enough signal reflections to worry about on unterminated pairs under those conditions.

But ask the m8b if one of the OP's PCs doesn't have its 2-wire configuration setup correctly and I think it'll say, "almost certainly"... 😀

The Brooks manuals I ended up consulting last night show that 2-wire is how they're connected - a pair of pins are designated Tx and Rx for RS-232 option, but for RS-485 option, that's bidirectional plus and minus.

Dave

[bgalfond]

Here is the library, direct from Brooks. It is made in version 6.1, so I think all can open it haha. I've been testing just with "ReadFlow Example" though the same behavior is found in any vi's tested, including "ReadTAG Example" which is the simplest one involving communication. I'm not entirely sure how to dig deeper into the dll to see what is happening - is that possible or is it like an exe that can't be deciphered like that again?

The physical RS485 components are the same on all three computers - all connect to the PC via usb. So I don't think it would be a terminal resistor issue if it works flawlessly on one PC and not the other two? Perhaps it is because these are bus powered adapters? I'll try and find an RS485 adapter with dc power adapter.

One adapter is a DTECH DT-5019. With that driver, there is no specific Tx options. It does still work on one PC, not the other two.

The second adapter is a Quatech ESU2-400.It has more options, and is set to Half-Duplex Auto Toggle; Receiver Active: Only when not transmitting. Iterative testing of all other combinations of operating modes (RTS or DTR control instead of Auto Toggle; Receiver Active Always) failed to work on all PCs. There is also a low-latency mode toggle, though this did not solve the issue.

I did Odd parity bit because of what I read in this Brooks manual, section 3-3, though I did try with None and Even. Odd is the one that worked.

Thanks again for all the tips!

[K C]

Hi,

No terminators should no problem with short cables and one device. 

One 'stupid' question: Are all computers connected at the same time ?

0V connection could be a problem. RS-485 is a balanced line but it has a 0V level. In some cases the voltage of the line could be outside the common mode range. 

If this is running on Windows, maybe you could try to set the handshake mode in the device manager. This to switch on and off the transmitter.

Kees

[DavidBoyd]

bgalfond,

Well, you've confirmed for me that on the Quadtech adapter, at least, you have the interface correctly configured to toggle the transmitter on/off and disable the receiver while the transmitter is active.  That's essential for a two-wire interface where you have bidirectional communication.

I'm a bit mystified by how the DTECH interface "just works" (or at least, is expected to) if there are no options on its Windows driver interface to configure it for two-wire.  How can it know your requirements?  I downloaded the manual PDF from their website and find no mention of driver installation/configuration.

*** All the further troubleshooting I discuss below is on an assumption that for the DTECH, wire mode settings ARE NOT an issue and are magically right! ***

I didn't install their Windows driver, but I did inspect it a bit.  It appears to be an FTDI VCP driver from a 2016 release, which seems old.  You *may* be able to get a newer driver from FTDI, but much would depend upon the hardware identifiers (VID & PID) matching up.  Or you can download the new VCP driver and try to force Windows to choose it for your adapter and hope for the best.

One problem I encountered with FTDI VCP drivers back several years ago was their "latency timer" default value upon installation (like, 50 milliseconds) - it really wasn't appropriate for any modern baud rates (like, 300 baud and higher!) with short message lengths between devices.  You may be able to change it either in a port configuration dialog (down to a number like 2 millisec), or worst case, add/edit a Windows registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FTDIBUS\{Device VID, PID and serial number}\0000\Device Parameters\LatencyTimer

I realize this is really getting into the weeds.

The only other solution I'd suggest is to spend money and buy a set of NI USB-485/1 cables, which are supported by NI's own NI-SERIAL driver package; for me over the years, at least, they've always worked.

Dave

[Bob_Schor]

---

@DavidBoyd wrote:

The only other solution I'd suggest is to spend money and buy a set of NI USB-485/1 cables, which are supported by NI's own NI-SERIAL driver package; for me over the years, at least, they've always worked.Dave

---

David,

     Does this mean that all these years I've been installing LabVIEW and making sure that I had VISA as one of the Drivers, that "NI Serial" was not needed for standard RS-232 (maybe I should call them "old-fashioned RS-232") devices?  Actually, I haven't been including Serial recently, and everything seems to be working.

     I just look at my installed LabVIEW (2019 SP1), which shows a "Serial" entry under "Instrument I/O", which is where the VISA Serial function is saved.  If I open NIPM, it doesn't show NI-Serial (but does show NI-VISA) unless I uncheck "Products Only" (or something like that), then NI-Serial appears.  Hmm, I'm probably "overthinking" this ...

Bob Schor