RS485 Communication with multiple devices problem

[matbeg]

Dear all,

I have been working on creating a software to communicate with multiple devices with RS485 protocol. I have created my own VIs to only use VISA Open, VISA Write, VISA Read and VISA Close and no additional driver.

As the devices require different configurations (Baud rate, Parity, etc.), I need to open and close the COM Port each time I want to send or read something. Everything seems to work fine but after a random time of execution (may be 5 minutes, 15 minutes, 20 minutes,...), the line seems to be busy and no device can then give a positive answer until I turn off everything and restart.

I am using a temperature sensor (Tecon), two pressure sensors (Keller), one MFC (Bronkhorst), one gauge (Pfeiffer) and eight RS485 Relays and I am running a loop every 2 seconds to make measurements.

I will try to insert an error detector in each device's VI but if someone has already experienced such an issue, I would be very glad to hear some advice !

Thanks in advance for your answer !

Bests

Mathias

[Andrew_F]

Upload either the vi's you are using, or take upload a picture of the block diagram(s).

I have found that most of the time when communications break down it can be caused by a few things:

-  Electrical noise in the system can cause COM ports to become 'lost' on your computer.

-  The device you are talking to is sent a query and does not have enough time to respond with the message.  The VISA read times out and an error is generated.  This error if propagated through can cause the VI's to stop performing any operations.

There are many things that can cause a breakdown in communications.  Without seeing code or more descriptions it is hard to give more insight into what is going on.

[RTSLVU]

It could also be a hardware problem, multiple devices on RS485 can be tricky.

Guidelines for Proper Wiring of an RS-485 (TIA/EIA-485-A) Network

[JoeWork]

I would suggest that you just get a USB to RS485 communication module for each of the different bus configurations you need to create.  They aren't that expensive.  They can be all connected to a USB hub.

[Ben]

---

@JoeWork wrote:

I would suggest that you just get a USB to RS485 communication module for each of the different bus configurations you need to create.  They aren't that expensive.  They can be all connected to a USB hub.

---

There is a lot of wisdom in that suggestion. Hardware is too cheap to not consider it as an option. One of the few times I have had to "tough it out" and make it work, it was because there would a bunch of test stations that all needed the same solution. Multiplication of the cost is what drove the single adapter approach.

Have you considered setting all of the devices to a common baud rate etc.?

Ben

[Andrew_F]

I would also offer that, adding 8 more adapters might not even solve the original problem.  It also does not address a common problem that occurs even when only ONE device is being communicated with.  Sometimes ports just 'dissappear' for many different reasons.  It is more helpful to understand what the cause of the problem is rather than suggesting alternatives.  

In my experience it usually is a query to a device that causes the communication channel to become locked.  Sometimes it is a command that was issued to the wrong device (due to a coding mistake that allowed it to happen unintentionally).

I do like the suggestion on 485 bus topology which is a good suggestion.  There may be poor termination on a device that is introducing noise into the system.

I'm not aware of the time that is required for a port to change its settings when you set things like baud rates, timeouts, or parity.  You may need a small amount of wait time before trying to use the port after changing these settings.  You may not even need to close the ports at all during your routine since you are nearly continuously communicating.  Look into property nodes for port settings.  You can change these on the fly rather than closing the port and opening it again with new settings.  

When issuing a request for data, you may need to add a small amount of time before issuing the read command.  I like to generate a running log of all communications in all of my software so that I can see if errors are appearing during a read or write operation.  And, be sure to catch errors and attempt to handle them as they occur.  It could be as simple as issuing a VISA Clear after each read operation to be sure there isn't 'junk data' on the bus.  

There are lots of possibilities without resorting to brute force such as having 13 ports open.  It might not even be 'possible' if for instance it is a requirement of the design to operate off of one port.

[Ben]

Another suggest that may help in the event the problem is tracked down to parallel threads accessing the port at the same time and stepping on each other...

An Action Engine that wraps all of the I/O operations into autonomous actions will protect the shared resource "serial port" and ensure that the process of setting the port settings, sending the query, and fetching the results, are performed in the right order.

Ben

[RTSLVU]

---

@Andrew_F wrote:

I do like the suggestion on 485 bus topology which is a good suggestion.  There may be poor termination on a device that is introducing noise into the system.

---

It's not so much noise as too many improperly terminated devices on one bus can bring the total bus impedance down so low that devices may not be able to drive the logic levels high enough for reliable communication.

[LV_Pro]

And yet another comment: A few years ago I had a RS-485 port that would "go missing". When I subsequently would look in MAX (or Device Manager) my original port (a USB to RS-485 adapter) would have suddenly changed from "COM3" to "COM13" or some other number. A wonderful NI engineer took the time to research the issue and called me to tell me that the HP motherboard had a history of "glitchy" USB ports. When a glitch would occur Windows would see the USB port disappear, then one appear, and would assign it a new COM#. The solution, in this case, was a plug-in USB card. So, before brute forcing, see if you can get more symptom information.

[matbeg]

Hi everybody,

Thanks a lot for all your suggestions.

@Andrew_F: I have been testing one device that wasn't working so well with a completely new USB to RS485 converter and it worked perfectly. Then I think that the quality of the converter is something not marginal. Maybe some of you know a reliable manufacturer for such a product ? For your information, I am using this one from Digitus and I also tried this one from Spectra as I live in Switzerland. It could also be a wiring problem because I did a "simple wiring" to test the device (see attached pictures). I think this is not a matter of time between query and response because I tried to run the program with a waiting time between both of 1000ms and it still crashed.

@RTSLVU: Yes it could be a problem of wiring because I didn't put a terminating resistor anywhere. This is something new for me, do you think I should try with it ? As I am using RJ45 cables to bring the signal to each device, I do have Twisted-pair wires.

@JoeWork: I won't get a converter for each device because I would need 13 of them... The idea of using RS485 protocol is to keep the system modular and having just one cable out of the computer to the machine.

@Ben: Same remark as I said to JoeWork. Then I didn't try to set every device to a common baud rate etc. because they all have different possibilities but not the same one for each device. What I did instead of that is to just open the port once at the beginning, then just change the property node before talking to a particular device, and close it at the end. It works fine but there is still this problem of line being busy after a random time.

@Andrew_F: Thanks for the good remark, it is better that way, not to close an open the port each time you need to communicate !

@Ben: Thanks for the Action Engine suggestion but I already thought about it and I used the "rendezvous" VIs which is a really good way not to write or read something without having the right to.

@LV_Pro: This is not a problem of missing or changing COM port because it never happened, but thanks for the information anyway.

@all: I have finally found that if I remove one particular device (the Tecon temperature controller), everything works fine for an undefined time without ever crashing. When I put it back on the line, the line starts to be busy again after a while. So I know now where the problem comes from but how can I solve it ? Is it a matter of termination resistor, knowing that the network works fine without this "Tecon" device ? Or is the problem coming from my USB to RS485 converter ? Last question: I already broke 2 converters by accidentally touching one RS485 line with 24V. Is it possible to protect the converter with any kind of mounting ?

Thanks a lot for your replies.

Regards,

Mathias