NI-9871 - which transmit mode for multi-drop RS485 communication?

[jt_fuw]

Ports of the NI-9871 have 4 transmit modes: 4-Wire, 2-Wire DTR with Echo, 2-Wire DTR w/o Echo, 2-Wire Auto.

Which of these modes are suitable for multidrop communication, what advantages or disadvantages each of them has?

Seems 4-Wire is poor: needs more wires, and devices that the NI-9871 port "talks" with all use the same line for sending data to the port, and possibly they are even unable to detect a conflict if many of them transmit simultaneously.

If a program is to turn transmitter on and off, it must know when the action can be done safely - I suppose turning off the transmitter while it sends a data will result in sending a distorted data. And I don't see any signal from the port that can tell whether the transmitter is busy or idle. Is there such a signal that I overlooked?

Some devices need some "idle" time before or after sending anything to them - their behavior is unpredictable if it is violated. I want the program to enforce sufficient "idle" times, but how can it know the RS485 line is idle?

[K C]

Hi,

Not sure what you are trying to tell here or ask.

Do you want to communicate with existing devices, Set-up something new, or ???

Kees

[jt_fuw]

Generally, these are existing devices; maybe some that I don't know, but I will not create any.

Here are results of my tests of NI-9871 C-module port. I used a 3-wire cable (D+, D-, GND) for communication; connections of the DE-9 Male Connector pins: p1=GND, p2=p3 (CTS+,RTS+), p4=p8=D+ (RXD+,TXD+), p5=p9=D- (RXD-,TXD-), p6=p7 (CTS-,RTS-); I tested all modes (including 4-Wire in spite I didn't have 4 wires).

In some modes connecting CTS to RTS aids verification of connections - it is the only way that I know for detecting a lack of power supply, or a disconnected signal cable (e.g. on the DE-9 connector).

Abbreviations: N/S/H mean Flow Control (FC) is None / Software (XON/XOFF) / Hardware (RTS / CTS); 4W/2E/2D/2A mean Transceiver Mode (TM) is 4-Wire / 2 Wire DTR Controlled with Echo / 2 Wire DTR Controlled / 2 Wire Auto; a 5-char symbol specifies DTR State / RTS State / CTS State (each of them is
u = Unasserted or A = Asserted) followed by -|T|R|B and -|E (T = Transmit to line, R = receive from line, B = Both, E = Echo).

The test results are:
N4W: uuuTE, uAATE, AuuTE, AAATE; CTS=RTS, TE
N2E: uuuR-, uAuR-, AuuTE, AAATE; CTS=DTR&RTS, DTR?TE:R
N2D: uuuR-, uAuR-, AuAT-, AAAT-; CTS=DTR, DTR?T:R
N2A: uuAB-, uAAB-, AuAB-, AAAB-; CTS=A, RT
S4W: uuuTE, uAATE, AuuTE, AAATE; CTS=RTS, TE
S2E: uuuR-, uAuR-, AuuTE, AAATE; CTS=DTR&RTS, DTR?TE:R
S2D: uuuR-, uAuR-, AuAT-, AAAT-; CTS=DTR, DTR?T:R
S2A: uuAB-, uAAB-, AuAB-, AAAB-; CTS=A, RT
H4W: uuuTE, uAuTE, AuuTE, AAuTE; CTS=u, TE
H2E: uuuR-, uAuR-, AuuTE, AAuTE; CTS=u, DTR?TE:R
H2D: uuuR-, uAuR-, AuAT-, AAAT-; CTS=DTR, DTR?T:R
H2A: no such a mode, the previous is kept!
(? as in C: DTR?TE:R means TE when DTR=A, R otherwise)

When the signal cable is disconnected, the CTS is u for *4W and *2E modes, DTR for *2D, A for *2A modes. Note: seems some signal changes are delayed!

H2E, H2D modes: if write is done while DTR=u, the data is sent when DTR becomes A (with echo received for H2E); this doesn't keep for their N/S counterparts!

The problem is that NI's documentation doesn't state clearly how do 9871's ports behave: I cannot predict results of using at least some of their modes basing on their documents; I can test a port behavior, but this gives me only knowledge on the behavior tested, not on the behavior the next 9871 - they may change an undocumented concept and in future make 9871-s with ports behaving differently, and a system using a 9871 may stop to work after replacing the original 9871 with a new one.

Attached are programs used for my tests, versions for LabVIEW 2018 and (in the ZIP) for 2010.
For both: Baud Rate, Data Bits, Stop Bits and Parity can be set before running only; Transceiver Mode, Flow Control and Break State can be changed while running; I didn't notice any effect of Break State value; Baud Rate Prescaler and Divider are shown.

ni9871fpga-mt.vi tests "modem signals" in a selected mode for all 4 DSR and RTS combinations and shows CTS after 500µs (note the CTS comes from the port connector and its changes are delayed); I noticed some bug in LabVIEW (2018): when the '4' (i32) and 'F' (bool) constant were outside the While loop, LabVIEW assumed it creates variable-size arrays; the '4' inside While is OK.

ni9871fpga-mt.vi sets DSR and RTS from UI, show CTS, has counters for CTS, CTS == RTS values, and for received data, and sends data (0x58 = 'X') on button pressing; on a PC I have a program (ttyusb0.zip, in Tcl for Linux, for Windows need change the port name which for Linux is /dev/ttyUSB0) that receives and sends data bytes (received data is shown as 2-digit hex value, sending is shown by dot), this setup allows me to test when the NI-9871 sends and receives data, and when it gets echo of the data sent.

I still don't know what the NI-9871 port does if another device on the line is active when it is to send: delays or sends causing a conflict? Using Echo mode allows detection when the data was really sent.

[K C]

Hi, 

Maybe there devices (transceiver IC's) that can see if the line is idle, but I never saw them.

The applications I know is a single master and multiple slaves.

I think what want (multiple masters) will need a single main master that controls the traffic.

In case of the ModBus protocol I would use a ModBus gateway.

What protocol does your application use?

[jt_fuw]

Unfortunately, I have several different devices using different protocols. And I cannot have enough RS485 ports to be able to use only one protocol on each port. Therefore, one of challenges is to find sets of not-conflicting protocols (I don't want a communication with one device to be recognized by another device as a command, like reading a  pressure or temperature resulting in byte sequence causing a valve to open or close...).

[K C]

Without knowing what protocols you use, I think it will be very difficult to solve it with a multidrop.

You can have 255 COM ports (Windows) on your computer.

With additional devices maybe even more.

Will easier than using a multidrop line.

[jt_fuw]

I am asking about general guidelines for NI-9871 usage, not for using it with a specific protocol. And I doubt you would like to read all protocol details for these devices that I am to control.

Manufacturers of many devices provide LabVIEW drivers for them, but they can be used when a port has connected one device, or one kind of devices, and I have many different devices, therefore these drivers are useless for me.

And I cannot use Windows for controlling these devices. A PC that runs Windows has no slot for NI-9871. The program that is to control these devices is required to run in FPGA, not on a PC. I must act within these limitations.