NI PXI-8421/8 (RS485), 4 ports not working, 4 ports are fine

[Ariel]

Hi,

Changing only the physical connection, and the COM port number (COM3, COM4, ... Com10) for ports 1-8 on my octopus cable, I get ports 1, 4, 6, and 8 working fine. And ports 2, 3, 5, and 7 not working at all.

As in, they don't recognized the RS485 signal being sent, get no bytes at the port. I'm looking at the bytes on the o-scope for all these ports (sequentially) and the signals are fine, a start bit, 8 data bits, a stop bit, at the proper frequency (9600 baud) and 7Vpp.

When I add an extra 200' of cable, none of the ports receive any bytes, though again, the signals on the o-scope are fine.

They signals travel through through twisted and untwisted sheilded pairs, drained to the LV chassis ground. There is one instrument communicating with each port, it has a 120 ohm termination resistor.

Why oh why is this happening? why no characters with the longer cables? why only some ports work?

Thanks-

[JoshuaP]

Do you have 120 termination resistors at both ends of the cable or just at one end of the cable? In order to transmit that far you will need to have a 120 ohm termination resistor at both ends of the cable. In addition, what wire mode are you using? (2-wire auto, 4-wire, etc.) If you are using 4-wire mode you should have a total of 4 termination resistors (two on each side of cable for the RX and TX pairs) on your cable. Check out the serial user manual. It has some good diagrams. After you have built the cable you should be able to ohm it out with a meter and read roughly 60 ohm between each +/- pair.

I hope this helps out.

Josh

[Ariel]

Thanks Josh,

I've terminated the one end, but the LV end, according the the NI website already has terminating resistors.

In an RS-485 network, because each differential pair of wires is a
transmission line, you must properly terminate the line to prevent
reflections. A common method of terminating multidrop RS-485
network is to install terminating resistors at each end of the
multidrop network. If you daisy-chain several instruments together,
you should use terminating resistors at the first and last instruments.
The National Instruments DB-9 terminating connector contains
embedded terminating resistors for easy termination of your RS-485
network and devices.

I'm in 2 wire auto TX/RX on all ports.

Any more suggestions? I'm pretty stumped on this...

Thanks-

[Ariel]

Josh,

Have more info now. Everything works just dandy on port 1. When I switch to port 2, it's picking up some extra noise or something because it's munching my start byte of AA. It's receiving 3540 (0011 0101 0100) instead of (1010 1010). Quite similar except for the leading 1 in 3540. Also, it inserts an extra 00 between the end of the 'end of TX' byte and the next 'start byte'.

Why is port 2 picking this up where port one was not???

I've gone over the grounds/sheilds repeatedly.

Is there something about needing to configure the ports *differently* so they don't share IRQs? so the software interrupts to bump?

Thanks for any help...

[JoshuaP]

Hey Ariel,

"The National Instruments DB-9 terminating connector contains embedded terminating resistors for easy termination of your RS-485 network and devices." This statement is talking about an optional connector that you can purchase (PN 182844-01). There are no termination resistors on the RS-485 card. Only bias resistors. This is probably one of your problems. I would suggest you purchase the terminating connector or add the termination resistor to your cable.

The second issue that you may be running into is the bit munching or bit flipping as I like to call it. I am not sure what you are using to send the string, but be aware that hyperterminal has a known bug that will sometimes cause the most significant bit to get flipped. I would suggest using NI-VISA when communicating with the serial port or the VISA Interactive Control in MAX for testing.

I hope this helps out.

Josh

[JLS]

Hello,

If possible, can you replicate the issue with a shortened network, and/or can you try sending and receiving 0xFF's only. The reason I ask, and I admit that I am reaching here, is that 0xAA = 10101010 which is causing "more" of the highest possible frequency component to exist in your frame (the frequency corresponding to your baud rate), whereas 0xFF = 11111111 does not force "as much" of this frequency. In general, those components should be most susceptible to transmission line effects. Taken together, I think shortening the network to reduce transmission line effects and/or sending "lower frequency data" would be interesting experiments to do given the nature of the phenomenon you observe.

I'm interested in any repost!

Thank you,

JLS

[Ariel]

Thanks, I'll try this this morning and get back to you.

Do you know if NI has biasing resistors on the 485 lines? a pull up on line B, and pulldown on line A?
I just got off the phone with a very helpful Mike Fahrion at B&B Electtonics who suggested verifying this.

[Ariel]

wait, now I've noticed that either line will work, but only when the other is stopped. They will not both work at the same time because extra zeros get received/dropped. I'm assuming the extra byte of zero is a "spike" on the line that get's interpreted as the stop bit of a byte of zeros. Why wouldn't these both work at the same time?

[Ariel]

---

@jls wrote:
Hello,

If possible, can you replicate the issue with a shortened network, and/or can you try sending and receiving 0xFF's only. The reason I ask, and I admit that I am reaching here, is that 0xAA = 10101010 which is causing "more" of the highest possible frequency component to exist in your frame (the frequency corresponding to your baud rate), whereas 0xFF = 11111111 does not force "as much" of this frequency. In general, those components should be most susceptible to transmission line effects. Taken together, I think shortening the network to reduce transmission line effects and/or sending "lower frequency data" would be interesting experiments to do given the nature of the phenomenon you observe.

I'm interested in any repost!

Thank you,

JLS

---

Thanks very very much. This did help tremendously. It didn't actually fix the problem though. I still have 4 ports that work (much better, much fewer problems with the 0x66 as the start byte) but I have 4 ports that don't work. They return errors of an I/O error or a framing error. I look at the data it received and it's munched.

I'm going to try and check just the ports now, take all my hardware entirely out of it. Any suggestions for a good port checking peice of code?

[craigherdman]

Ariel,

One suggestion that JoshuaP had was to use NI-VISA and the VISA Interactive Control in MAX to test your 485 ports. If I understand correctly each port will work as long as the adjacent port is not in use correct? I would try to simplify the testing of these ports by making at least two loopback cables that we could use to test various combinations of ports (by the way are you using LabVIEW, LabWindows/CVI, or something else?). This would help us determine whether or not the issue is with the 485 network or your ports. Framing errors are caused when the serial paramaters that the instrument expects and the serial parameters that the PC is using do not line up (baud rate, data bits, stop bits, parity, etc need to match up both in Windows and in MAX). I would recommend making these changes in MAX as they will then be reflected in the Windows Device Manager.

Also what are the precise error codes that you are seeing? Do you have a single device connected to each port or are you implementing a multidrop setup where some ports have multiple devices connected?

Craig H.
NI Applications Engineering