RS-485: PC can send/receive data from PCI card, but LabVIEW can only send to card.

[Tim359]

I have a master/slave setup with a 2-wire RS-485 connection via a StarTech PCI2S485 card  http://www.startech.com/product/PCI2S485-2-Port-PCI-RS-422-485-Card-with-DB9.  A Vista PC running LabVIEW 2010 is acting as the master to 6 slave devices.  I am running a driver VI supplied by the company that made the slaves. 

I've used a terminal program called Termite to monitor the ports during operation and have concluded that both the PC and the slaves are sending correct data packets (i.e. correct protocol and reasonable data).  Termite indicates that the slave's response is being received by the PCI card, but the problem is that LabVIEW simply isn't reading the response from the card.  Each time the driver VI is run it returns a "timeout waiting for slave to respond" error.  

The VI and slaves I am using are designed for both RS-232 and 485 communication.  I've verified the VI to run in 232 mode on a different COM port.  I also wrote a simple VI using the VISA functions to test the ports on the PCI card, but I've had the same results.  Hardware connections have been looked over carefully, but the fact that the card actually sends a correct message and receives a correct message indicates a different problem.

Any idea why LabVIEW can talk to the PCI card but can't hear it?  Is there anything I can do about this, or does LabVIEW generally not like StarTech's PCI2S485 cards?

Thanks,

Tim

[RavensFan]

Since the card has two ports, an interesting experiment would be to wire the two ports to each other.  Then create a LabVIEW VI that writes out on one port and reads in from the other.

This should narrow down the troubleshooting to probably as tight as you can be, the card, LabVIEW, and some relatively simple wiring in between.

You might want to run NI-Spy while you are running your LabVIEW VI's to see if that shows you anything of interest and if it is anything different from your Termite program.

I'm interested in hearing about what you find out.  I have a couple Startech RS-485 cards.  One 4-port model seemed to work fine the last time I used it.  Another PC has a 2-port model (I'm not sure if it is exactly the same as yours, but it should at least be similar).  I tried to get that working, didn't have much time, so I went back to the other method I was using.  Ultimately, I want to use that card in my application.

One thing I do remember with the 4-port card, and I'm not yet sure if I need to do it with the 2-port card, was that I had to create a special adapter that did some tying of the RX and TX pins together at the card side.

[Tim359]

Thanks for the suggestions.  I already tried wiring the two ports together, but LabVIEW was using one port and the Termite program was using the other.  I'm interested to see if anything changes with LabVIEW using both ports.

About the 4-port card, did you make an adaptor that just short the RX and TX pins together, or was it more elaborate than that?  Also, do you recall what kind of results you were getting before using the adaptor?

[RavensFan]

Yes.  The pair of Rx pins were tied to the Tx pins.  I also had a Gnd wire that passed through.  I'm pretty sure it did not work in one direction or the other without it depending on which pins (Tx vs. Rx) my wire pair was connected to.  I thought the instructions even said in so many words that the pins had to be tied together, but it has been a few years since I was sorting out the communication wiring for the application that needed the 4 port card.

For the port to port, I mean just have LabVIEW reading on one port and writing on the other.  Don't use the Termite program at all.  How are you using this termite program?  I thought it was some sort of port spying program.  Are you trying to use this at the same time as your LabVIEW program?  How are you monitoring the communication?  Do you have some sort of Y adapter joining the two ports? 

[Tim359]

I'll make sure to try tying the Rx and Tx pins together after the weekend.  As for Termite, it's basically a port spying program as you guessed.  It reads messages sent to the port and can send its own messages.  The interface is a lot like instant messaging or "chat" programs.  It does lock the port it's looking at, so I could only use it when the two ports on the card were connected with a short cable (basically a makeshift Y adapter).

To monitor the communication I had LabVIEW running on one of the ports and the Termite program monitoring the other port.  Besides simply using Termite to monitor I also tried LabVIEW writing to the port it was monitoring and then other way around.  Only the first way worked.  When I get a chance I'll see what happens using LabVIEW to connect to both ports.

[Tim359]

I tried tying the Rx and Tx pins together, but it does not seem to change anything.  When I tried making a test VI to communicate with both ports on the card at the same time, I was able to send a message from the first port and receive it on the second port, but going the other way didn't work.

I've given up on the card for now and am using a USB-RS485 adapter which seems to be working well.

[RavensFan]

Perhaps something is wrong with the card.  Double check the jumpers settings on the card.  But beyond that, perhaps the card is damaged.

[paracarro]

---

Tim359 ha scritto:

I have a master/slave setup with a 2-wire RS-485 connection via a StarTech PCI2S485 card  http://www.startech.com/product/PCI2S485-2-Port-PCI-RS-422-485-Card-with-DB9.  A Vista PC running LabVIEW 2010 is acting as the master to 6 slave devices.  I am running a driver VI supplied by the company that made the slaves. 

I've used a terminal program called Termite to monitor the ports during operation and have concluded that both the PC and the slaves are sending correct data packets (i.e. correct protocol and reasonable data).  Termite indicates that the slave's response is being received by the PCI card, but the problem is that LabVIEW simply isn't reading the response from the card.  Each time the driver VI is run it returns a "timeout waiting for slave to respond" error.  

The VI and slaves I am using are designed for both RS-232 and 485 communication.  I've verified the VI to run in 232 mode on a different COM port.  I also wrote a simple VI using the VISA functions to test the ports on the PCI card, but I've had the same results.  Hardware connections have been looked over carefully, but the fact that the card actually sends a correct message and receives a correct message indicates a different problem.

Any idea why LabVIEW can talk to the PCI card but can't hear it?  Is there anything I can do about this, or does LabVIEW generally not like StarTech's PCI2S485 cards?

Thanks,

Tim

---

---

RS232 interface consist of 2 indipendent communication crossed lines between 2 devices (9DSub connector: Pin 2-RX  Pin 3-TX pin 5-Gnd)

RS485 interfaceis a bus, shared between 2 or more devices. (like ethernet or CAN Bus)

This means that an incorrect use of the bus can lead to a "packet collision" if 2 or more devices try to send a message on the bus at the same time or at least their messages, partially "overlap"

About 10 years ago I have used a PCI 2 RS485 port: I remember  that I have to change the status of RTS serial control line to switch between transmit and receive mode.

This can be done using the serial VISA property:

Serial Settings --> Modem Line Settings --> DTR State

or using the VI

<LabVIEW dir>\vi.lib\Instr\_sersup.llb\serial line ctrl.vi   (LV 8.6.1)

The result was that the slave device connected, send me the response after few nanosec. causing the lost of the answer.

because LabVIEW use more than some  nanosec. to change RTS property after sending message on the 485 bus calling a VISA Write.

So for me there was 2 possibilities: 

- use 2 RS485 port (1 for transmit 1 for receive echo transmit included)

 - use this converter  

         http://www.advantech.com/products/ADAM-4521/mod_2E78D425-8B08-43F6-81B0-1B924E53E075.aspx

 this converter, after sending a message on the bus, electronically switchs back to receive mode without losing a byte.

-.-.-.-.-.-.-.-.-.-.-

But the question is :

what does it means

"RS-485 mode supports Auto Transceiver turn around (ATTA)"

of your card?

bye

---

[Tim359]

paracarro,

ATTA means that the PCI card automatically controls the RTS, so I don't have to worry about this in code anywhere.  I also tried communication with ATTA disabled (in other words, RTS is controlled programmatically and not by the card) and the slaves didn't get the message that LabVIEW sent.  I couldn't tell if the card was receiving because there was no response to receive.

[Tim359]

Ravens Fan,

At this point it seems like something is probably wrong with the card.  I also tried a few dozen differnt combinations for jumper settings without any different results, except that turning ATTA off meant no communication.