Interesting Modbus Library Behavior with RS-485 RTU Serial

[rhenderson]

RS485 Isolated Common per this document https://www.ni.com/docs/en-US/bundle/crio-9030-feature/page/rs-485422-dte-serial-port.html is connected to my RS485 common on both my devices.

Measured my resistance of loop across my first resistor and read 54.5 ohms. Have 110s inserted at both ends for lack of 120s on my desk. I have an oscilloscope as well as a logic analyzer I can attach and see what I can get. Will also try to add "time" between each write to read. Suppose it seems to happen most often after a write to a read.

[K C]

Hi,

All the stuf about terminators is very important if you have long lines. If it is a test set-up on your desk with 1 or 2 meter of wire I should not worry about the terminators. Attached a PDF of what we use. The value are different but the line value is still ~120Ohm. This was defined over 30 years ago for our products with a  network at 250.000 baud and is still in use (Less different resistors value available at that time) 

For the line the there is no difference between the ModBus read or write. So I still think it is something at the master or slave side that is causing this. With an oscilloscope you could see the time between end of data and release of the RS-485 line of both master and slave.

Catching the error moment on the oscilloscope will be rather difficult unless you stop the communication directly after a fault..

Kees

[JÞB]

---

@K C wrote:

Hi,

All the stuf about terminators is very important if you have long lines. If it is a test set-up on your desk with 1 or 2 meter of wire I should not worry about the terminators. Attached a PDF of what we use. The value are different but the line value is still ~120Ohm. This was defined over 30 years ago for our products with a  network at 250.000 baud and is still in use (Less different resistors value available at that time) 

For the line the there is no difference between the ModBus read or write. So I still think it is something at the master or slave side that is causing this. With an oscilloscope you could see the time between end of data and release of the RS-485 line of both master and slave.

Catching the error moment on the oscilloscope will be rather difficult unless you stop the communication directly after a fault..

Kees

---

No, the bus is double terminated.   The Master just has a slightly stiffer drive.  

I don't know why I said 285 ohms.  I should have Googled it.  Probably disremembering the RF impedance of air for a C band Doppler system.

[rhenderson]

I think I could be convinced it might be device specific with not releasing the line in a timely fashion. I can absolutely smash the line if I'm only addressing a single device reads and writes. No errors with continuous, fast activity at all with 120ohm terminations on both ends and common connected even with the other drive on the line still. Current test plan is to swap modbus devices to 2 others from different manufacturers and see what I get. Will also add ability in vi to specifically target the delay times between devices to allow the lines to "settle or release". Third option would be to make a triggered "oscilloscope" with a cDAQ to get highspeed data I can only record the data immediately prior to an error. Thanks again for riding this one out.

[rhenderson]

Almost feel like assuming modbus is going to be bulletproof and not just very close to that is a bad assumption.

Added two devices to replace the ones on the desk of a different type. This is a Y setup again that is un-terminated. Modified the VI to be able to enable/disable the read, write, read, write train and add certain delays prior to their action if required. Still getting read errors with different devices. 

NEW DEVICES at 19200 and only READS

It does seem likely the issue is with swapping between two different slave addresses at least with the original units. If I disabled my reads, I could start getting faults on writes when it was just write, write which I usually only get them on the reads when we read, write, read, write. Adding delays before reads doesn't really seem to help too much.

Almost believe at this point we should assume we will have failures and deal with them quickly as they happen.

[K C]

Can you describe the actual error.

I see a picture in your first post but I don't exactly see what is wrong.

Do you get a time-out error or wrong data. 

If it is not a time-out:

If you have a spy or data monitor connected can you post a data dump of the communication data. Or simply use a VI that captures all data from the line.

Ignore the failure as you say in your last post is not an option (yet)

Kees

[rhenderson]

It's a timeout error I believe. I will confirm that though. It's been a while.

Picture to me shows a couple of instructions being sent in a chain before the device has a chance to respond. Maybe some partial instructions being sent and then not-interpreted causing a timeout?

I did hook up a logic analyzer to it today, and some interesting pictures from that experience. Having trouble with the protocol conversion on that one, but might not be too far away from a true line spy capture.

[rhenderson]

The ones I have been seeing when looking for them have all been Error 56.

[K C]

The lower two signals look normal to me as a RS-485 line

But what are the upper two signals ?

Can you post the VI from the first message here ?

[rhenderson]

The top two signals are the digital conversion of the bottom two analogs. Have not used this version of Saleae's Logic software specifically, so tuning the A2D might not be working as expected. I would agree the bottom ones look normal, but it was sort of surprising for me to see that each device type drove the lines to to different levels. Neat that it can do and handle that.

Current VI and support VIs attached.