RS485 Communication with multiple devices problem

[Ben]

Re: the bad device

You should check to docs for that device along with the other ones. RS_485 is intended to be a type of transmission line and for higher speed comm, it is important to make sure you have the right termination resistors in the right places. Too many and you load the signal down and not enough you get reflections that degrade the signal.

If you look at the Wikipedia for rs-485 you will see the electrical spec is not part of the standard. SO whil eall of the device may actually be rs-485, the nature of the cabling may be slightly different for different devices.

Additionally, the bad widget may simply be of a poor design that does not play well with other devices.

Off-topic war story

Spoiler

Re: damage due to 24 Volts.

I used to service mainframe computers back in about 1980. I was just getting started with them and I was still being supervised by more experienced engineers since mainframe computers were mega-buck systems consisting of multiple 19 racks filled with logic.

So while checking the 5 Volt supply on the backplane...

I slipped and shorted the 24V to the 5V buss. I eventually figured out I took out about 4-5 modules. with that slip.

As soon as I saw the arc and realized what I had done, I went my mentor who was in the lunch room reading a news paper and told him "Kevin I think I shorted the 5V to the 24V buss." He looked up from the paper and then back down at the paper and said, "You broke it. You fix it.".

That was very long night.

Ben 

[LV_Pro]

Oh M G, I had forgotten about the wire-wrapped backplanes! Now I'll have nightmares tonight, all of that therapy wasted!

Yes, read the literature for the devices, some actually have built in termination, selected by a jumper or DIP switch.

[JoeWork]

matbeg,

Try twisting your wires for your comm lines.  What speed are you transmitting at and how often are you polling your devices?  Do you have a scope that you can use to look at your comm bus signals?  Does your Tecon temp controller possibly send information on it's own?

I wasn't suggesting a controller for every device.  Just one for each port (baud rate) setting.  But that option just depended on how fast you were polling your devices.

Can you just change the settings each time you need them instead of opening and closing the port?  May save some time in your process.

Read this for protection of RS485.

www.ti.com/lit/an/slla292a/slla292a.pdf

www.mouser.com/pdfdocs/Bourns_RS485_AppNote.pdf

[Andrew_F]

The device itself must have some sort of communication that is not expected.  I was never able to track it down to WHY, but I was able to avoid a very similar situation.  I hope I make the link to my post correctly http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Siglent-Strange-VISA-Behavior/td-p/3356879.

In my situation, I was able to send and receive commands from a particular device, a power supply.  However, I have bashed my head against the wall for the last 7 years or so now with VISA opens and closes.  In short, if I tried the method of 'open port -> perform action -> close port.  My device would hang up after a few communications.  The 'solution' to the problem was one that I was very unhappy with and I would love to figure it out what the true cause was.  The solution was to send a query to the instrument before ultimately closing the port.  For some reason the device was not happy with having its port closed.  It's hard to simplify the details, but maybe you can glean something from that thread a while back.  I tried to show as explicitly as possible my situation.

Termination resistors may be a good step to take next.  It is possible that the device is 'seeing' a command that instructs it to send data onto the bus.  

I would explore talking to that particular sensor and see what conditions (if any) you can come up with that locks up the bus.  The lock-up may depend on the other devices being present on the bus.   You might be able to have it as the only device on the bus and still see it lock up over time.  

Another thing to consider is grounding paths.  In one picture you had connections for the USB-RS485 converter that had a ground connection.  You may want to check to see if any of the sensors are grounded.  If some are grounded while others are not, this may be another source of noise/reflections.

Good luck!

[matbeg]

@Ben: This is so strange that every device is properly working but just one is annoying me. Does this mean that the problem comes from the device itself ? I already asked the supplier three times but he isn't able to solve my problem.. My next idea is to change the temperature controller but I will have to look for a new device. If you know about a good product tell me !

@JoeWork: I wil try to twist the wires more but I don't think that this will change a lot since I built the whole machine the same way. I already checked the speed regarding the baud rate I am using for each device. I put enough time between each polling to be sure they have enough time to receive information and give an answer. As my Tecon device gives an answer one out of three times, I guess there is not so much things to do to make it work. I think I a joining Ben's remark. There must be something wrong inside the device that makes the signal go to the ground or to the +Vcc after an undefined time.

@Andrew_F: If I get what you are telling me.. You did the usual VISA Open -> VISA Write -> VISA Read and then instead of Closing VISA you just did a VISA Write before Closing ? This is something that I tried yesterday without success.

I tried to open the device and see the resistors. Instead of two pull-down/pull-up resistors of 620 Ohms, they put two of 560 Ohms. Then they put the famous one of 120 Ohms between both + and - wires. How do I know that this is the good configuration ? Can I measure something to find the right value for the resistors ?

I tried something else yesterday too. I tried to let the "lock-up" appear after a while (15 minutes this time) with every device connected and then I just turned off my Tecon device. Then I let the program continue to run and it started giving me data back, meaning that the communication was running again. When I turned my Tecon device on, it also started working again. I guess that the problem is really coming from the device itself but even trying another one didn't work. Do you think that there is something that could be done from my side ? Should I tell the supplier to fix the problem ? Or should I just give up with him and try another one ?

Thank you all for taking time to try to help me 🙂

Mathias

[Andrew_F]

matbeg,

Not a VISA Write before closing the port but the solution to my communications problem was to send a VISA Read as the last action.  I never understood WHY this worked, but it did.  Very unhappy with that.  But, basically sending a VISA Read allowed the device to remain in a good state.  I was not actually sending any command that would request data, so I basically set the VISA timeout to a very small value and then discarded the timeout 'error' from the VISA read vi.  This is in essence what I did below in the snippet.  Basically "Command" is a command, not a query.  What I mean is that I'm not asking for data in this little bit of code.  Yet, to keep the device functioning properly, I ask for a response.  I put the timeouts in there so that I can change the timeout to a small value and then return it to the original value after the VISA Read.  I am not doing anything with the read response in this snippet becuase I'm expecting the data to be meaningless (which in my case there never is a returned string).  Also, I did not include the error capturing of the timeout that is expected to occur.

As far as different sensors.  What exactly is the sensor you are currently using?  And what are the requirements of the sensor?

[matbeg]

Andrew_F,

Now I understand what you mean. Unfortunately this is not helping me since I already do a VISA Read in my program to collect data from the device. With every device I send a frame and wait for an answer, even if it is just sending back the same one. This is done to be sure that the device is working properly. I posted my "Tecon" VI so you can see what it means even if you don't understand everything that is sent.

I must say that I really think that something is wrong inside the device. When I ask for help to the supplier, they tell me "try to remove that resistor", "try to add that", etc. It's like they understand that something is wrong with their device but they don't really know what they are doing. This is the device I am using. Unfortunately their website is only in German.

http://www.tecon.ch/produkte/industrieregler/mehrzonenregler/show/t231a

I need two input for two thermocouples (Type K), two output relays to heaters and of course the differential inputs for RS485. This is not rocket science but the communication with this device is the hardest part of my work...

To be continued...

Mathias

[Ben]

NI IO Trace will let you eves-drop on what is happening on the wire. It will show everything that the port THINKS it sees.

I would suspect you will have to d a differential measurement (set scope for math Channel 1 - Channel 2) but you could check the signal levels and signal quality both with and without that questionable widget.

Are you just working at your desk or are you possibly talking about long runs of wires? There is a limit to how long the wires are affecting faster speeds more than slower speeds.

Ben

[matbeg]

Ben,

Thanks for the advice. I'll try with a NI IO Trace. I'll also try to find a way to measure the signal quality but it the mean time I am trying to find another supplier because I am tired of this...

For your information I am working at my desk. I am building a quite small machine and I'm using 0.5m RJ45 cables to link all the devices. Most of the time I even cut the cables so there are not long runs of wires.

Regards,

Mathias

[matbeg · Accepted solution]

FINALLY !!!

I found where the problem was coming from by accident ! I was testing the line with a scope and for that I needed to disconnect one of my devices. I unplugged the Pfeiffer device to take the line from here and I noticed that everything was working fine, although I had my Tecon device on the line.

Then, after a little bit of thinking, I understood that the Pfeiffer device is sending an error message every time he sees a message ended with the famous carriage return "\r". As there is only the Pfeiffer Protocol and the Tecon Protocol that requires that special character at the end of the message, this is why I thought that the error was coming from the Tecon.

I asked Pfeiffer if there is a way to cancel this error message but it is not possible. This means that whatever device is on the line, if I send any message ended with "\r", it will send the error message "\15". It's a little bit annoying but at least I found my problem. I think I will have to divide my RS485 with a USB Hub to create 2 COM-Ports.

Thanks everybody for your answers. Hope this could be helpful for somebody else in the future.

Bests,

Mathias