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

[DavidBoyd]

@Bob_Schor,

VISA is an API layer needed by all LabVIEW applications that interact with hardware by means of VISA Read and Write nodes (which covers USB, serial, GPIB, SOCKET, etc).  NI-SERIAL is their collective term for their driver package for all NI industrial serial hardware (I'm handwaving a bit here).  So if you have NI-branded interfaces, be they USB attached, or Ethernet, or a PXI plugin (I think to include ports built on to their PXI chassis controllers), you'll want NI-SERIAL as a hardware driver.  OTOH, if you havea straight-up PC chassis with FTDI, or Moxa, or (yuk!) Prolific branded USB-serial interfaces, NI-SERIAL is not used.

Dave

[billko]

---

@DavidBoyd wrote:

@Bob_Schor,

VISA is an API layer needed by all LabVIEW applications that interact with hardware by means of VISA Read and Write nodes (which covers USB, serial, GPIB, SOCKET, etc).  NI-SERIAL is their collective term for their driver package for all NI industrial serial hardware (I'm handwaving a bit here).  So if you have NI-branded interfaces, be they USB attached, or Ethernet, or a PXI plugin (I think to include ports built on to their PXI chassis controllers), you'll want NI-SERIAL as a hardware driver.  OTOH, if you havea straight-up PC chassis with FTDI, or Moxa, or (yuk!) Prolific branded USB-serial interfaces, NI-SERIAL is not used.

Dave

---

Don't worry, Bob - I thought the same thing up until someone here told me you it was for NI Serial products.

[JÞB]

---

@bgalfond wrote:

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!

---

I'm going to reiterate the phy layer requirements.   Section 2 of the manual is very clear on the need for proper line termination.  You also need to use hardware flow control of some sort to idle the master (place its output in high Z) when RTS is low.  The Brooks device is probably not going to work well via a USB-RS485 adapter unless you use a MOXA.  It is designed for +/-12V coming from a COM port and does not claim to be 5V compliant.  Without that specific claim in the device manual I would call Brooks to confirm capabilities of the chipset inside their ancient device. 

In NO CASE would I depend on an internal or unpowered USB hub! You will almost certainly want the full 5V@500mA USB power to drive their chipset.

The manual also contains specific advice on slave response timing and modes of communication message failure (and when to attempt retry messaging) late in the manual.  I won't summarize all 106 pages but, you need to read a good portion of them.

[bgalfond]

Yeah, I do think the root of this is a bus power issue. Purely spitballing here, but since it did work on one PC, there may be a step up converter in the USB-RS485 adapter to go from the USB 5 V to RS-485 10V. If the other two PCs had lower power on the USB ports, this may mean it doesn't quite hit 10 V or there is significant enough ripple that the signal is impacted? I'd honestly feel MORE comfortable with this troubleshooting if it had never worked on the other PC.

Either way, I've got some new adapters on order and will try some other PC's too. Unfortunately the NI adapter is on backorder for 3+ months, but never seen MOXA before, will check them out. I realize now the first "moxa" google hit about burning moss for acupuncture is probably not what you meant either, but I'm up to try most anything to solve this now haha.

[JÞB]

MOXA UPort series And definitely open a dialog with Brooks