Modbus periodic update interval "problem"

[Meeg]

Hello

I am using modbus RTU Reading two sensors. Modbus ID = 1 & 2 respectively. From each sensor i read two values, one 16bit and one 32bit float. Baudrate = 9600.

When I activate communication using "Active periodic" bit any one of the sensors (only) I can set my update interval at 100ms without having failures.

The "funny" things occur when  when i activate both:

If I set my update interval at 400ms: It updates values from both sensor for a few Seconds (at 400ms rate), then it stops completely updating the reading/values from ID2. But the  "success" Counter continues to count. And the values from ID1 continues to at 400ms rate.

If I set my update interval at 500ms: It updates values from both sensor for a few Seconds (at 500ms rate), After a few second the  ID2 values are updated at 50% rate (1s). ID1 continues to update 500ms.

If I set my update interval at 1000ms: It updates values from both sensor at 1000ms without any problem.

Any tips on why this happens and how to solve it?

In my Application I need as fast update rates  and would have thougt that beeing able to read one sensor at 100ms, I should be able to read 2 sensors at 200-250ms.

Thanks for a super Product!

Meeg

 

[Joe Tauser]

100 ms updates are quite fast for 9600 baud.  There's a lot of overhead involved with generating a Modbus frame and the time you've selected is not realistic.  My experience has been 1 second updates are about the best you can do, as you've proven.

Have you tried dialing up the baud rate to 115K?  Are your devices capable of it?

Joe T.

 

[dierkens]

3 hours ago, Joe Tauser said:

100 ms updates are quite fast for 9600 baud.  There's a lot of overhead involved with generating a Modbus frame and the time you've selected is not realistic.  My experience has been 1 second updates are about the best you can do, as you've proven.

Have you tried dialing up the baud rate to 115K?  Are your devices capable of it?

Joe T.

 

This is exactly what I was going to ask.  Your update rate will always be limited by the speed of your serial port and how much data you're getting from the devices.

Crank up that baud rate on both ends and see what happens.

[hotwires]

Just a thought: you could try aperiodic ladder trigger on sensor #1, compare for increment of RTU#1 sessions STRUCT integer, that in turn triggers Aperiodic RTU#2, compare detect session STRUCT advancement, in turn triggers RTU#1 again, LOOP.  In THEORY this should alternate MODBUS commands between sensors at the rate each MODBUS slave STRUCT count advances. Would be analogous to the MODBUS "function in progress" bit in vision. The system would tell you when it had completed a MODBUS operation, that being the cue for the next.  

Never tried this exact scenario. I have used session counters to detect a complete cycle of periodic MODBUS exchanged and toggle heartbeat bits.

Assuming:

The request packet for the Slave address (1 byte) + Function code (1 byte) + Offset (2 bytes) + Number of Regs (2 bytes) + CRC (2 bytes) = 8 bytes.
The response packet length will be: Slave address (1 byte) + Function code (1 byte) + Byte Count (1 byte) + Data (2 bytes) + CRC (2 bytes) = 7 bytes.
The number of bits will depend on the serial setup (e.g. parity, data bits etc.).
Assuming 1 start bit, 8 data bits, 1 parity bit and 1 stop bit = 11 bits per byte.
So total number of bits = 15 bytes * 11bits/byte = 165 bits.
Now the bit time must be calculated = 1 / baud rate.
Taking 9600 baud as an example, bit rate = 9600 / 1 = 104 micro seconds per bit transmitted
Giving a total transaction time of 104 micro seconds * 165 bits= 17.16 milliseconds per MODBUS handshake

Now there is some internal overhead in CPU to chew it up and spit it out. What part am I missing that makes less than 1 second polls feasible?

One thing I'm not factoring in is the response turn around time in the slaves. That would have to be measured or found in spec sheet.

[Joe Tauser]

@hotwires - 

You're forgetting that Modbus is not a data broadcast, but a query/response protocol.  The COM activities are serviced at the end of the scan, so communication is not instantaneous.  And there has to be two.

I don't know the exact reason for why Modbus isn't faster than it is - your calculations are a good and show why it should be.  But my personal empirical data has shown that it isn't.

A good exercise would be to get my Modbus simulator fired up and have the PLC hammer the simulator at different baud rates to determine the speed thresholds.

You'll note in Meeg's post that he had partial success at 500 ms.  If I had to guess I'd say that the UART buffer for the PLC serial port is filling up and the PLC CPU is having a hard time unloading it.  You have to remember that a PLC CPU is not in the same league as a graphics card and it's prime directive is to solve the program logic and execute I/O operations. 

Joe T.

[hotwires]

11 hours ago, Joe Tauser said:

@hotwires - 

You're forgetting that Modbus is not a data broadcast, but a query/response protocol.  The COM activities are serviced at the end of the scan, so communication is not instantaneous.  And there has to be two.

I don't know the exact reason for why Modbus isn't faster than it is - your calculations are a good and show why it should be.  But my personal empirical data has shown that it isn't.

A good exercise would be to get my Modbus simulator fired up and have the PLC hammer the simulator at different baud rates to determine the speed thresholds.

You'll note in Meeg's post that he had partial success at 500 ms.  If I had to guess I'd say that the UART buffer for the PLC serial port is filling up and the PLC CPU is having a hard time unloading it.  You have to remember that a PLC CPU is not in the same league as a graphics card and it's prime directive is to solve the program logic and execute I/O operations. 

Joe T.

@Joe Tauser

I didn't forget the architchtural structure of MODBUS. I used terminology like: " request packet / response packet" and "exchanged".  No data communication is instantaneous (maybe quantum computer would be closest thing I can imagine). I also remember JT qoute: "empirical data is the best data" and wholly agree. My time calculation figured in the send and reply packets (approximations)  but NOT: UART, CPU, or ladder execution times. 17 mS is still a far cry from over 500mS.

I don't have an intimate understanding of physical PLC processing architecture, however I assume (dangerous word, I know) that it's fairly parallel to PC's and embedded uC or uP  (with external chips) control devices (like DMX lighting control consoles and BASIC stamps). Unitream has two CPU's? correct? Panel and CPU, then RS-232 module has UART with CPU that is on a com bus back to the main brain.

If I ever get some spare time I'll try to setup a Unistream RTU master to Vision RTU slave and try to measure min time between successful RHR exchanges.

[Meeg]

Hello,

And thanks to both of you for good answers.  You are obviously a lot more experienced with Modbus than I am.

Unfortunately the sensors can only communicate at 9600baud. Trying aperiodic is probably a good idea. But  maybe using a timer rather than the  session Counter?  Refer 2) below, the session counter will count even if the variable is not updated with a new value.

You are reffering to UART, CPU, or ladder execution times to slow things down. To me this sounds strange as it must also be able to handle much higher baudrates and amounts of data?

So what I still do not understand is:

1. If I  activate communication on ONLY ONE sensor, communication works fine at 100ms. But when activating communication on TWO sensors, I need to slow the update rate to more than 500ms (it works at 600ms) to get it working. I would have expected 200-250ms.

2. Also a bit strange that at 400ms rate the "success" counter on ID2 continues to Count, and the "fail" counter does not count. But still it does not update the values read from the sensor. Did Unistream receive a value from the sensor (hence the "success") but not transfer it to the variable?

 

 

[Ausman]

I'm not into Unilogic at all, but I'll throw in my thoughts.  In Visi I only ever use 9600 and have the read at 700ms, and some of the slaves send info to fill a vector of 40 MIs.  I have long been going to trial a system that counts a given number of scans b/n the various success flags so that I could find the absolute minimum time that still gets everything ok.....but this falls into the "if it ain't broke, don't fix it" thinking!  So I simply have never got around to it, given that I would have to play remotely with sites that have to work 24/7 and I might end up with a big disaster.  

And incidentally, in Visi I only ever get consistent reads at 9600, and most of the gear I use has only 2 settings anyway, 9600 & 19200.  I get missed reads at 19200, even with a big time, but 9600 is fine.

cheers,

Aus

[hotwires]

Unistream's  periodic mode internal sequencing logic (no idea what it is) may have something to do with erradic operations when adding a second slave. I have a program that polls four RTU (RS-232 over RF) slaves and polling order is RTU 1,3,2,4 not 1,2,3,4.  

Thought this was odd. I poll once every 45 seconds. The RF modems add up to 500mS latency. Offsite pump control doesn't demand high speed updates. 

[Ausman]

5 hours ago, hotwires said:

polling order is RTU 1,3,2,4 not 1,2,3,4

Maybe this is the issue here?  Maybe the system only does a sequential count and yet this odd sequence means the system is trying to poll a unit 3 before it gets to unit 2, and there are timeouts happening on the failed read to compound things?  Meeg, can you perhaps try changing your Modbus IDs and program around a bit to try this theory out?

cheers,

Aus

[Ausman]

Read my post directly above before this one! Out of curiousity I've just had a quick look at how Unilogic handles Modbus RTU.  Am I correct in that it seems that you have 2 choices of how it polls, one is where you set up your own sequence of calls, and the other is where it will do a sequential one all on it's own, which appears to be Hots odd sequence system.  So again, Meeg, vary the program and IDs a bit and see what happens.

And Hots, I assume you discovered the odd sequence through observing that things were not being updated in the order you expected?

cheers,

Aus

[hotwires]

@Ausman

i stacked HMI numeric displays od MODBUS RTU STRUCT INT: sessions, success, fail for each of the four RTU's. Incrementation was not sequential in regards to order of slave ID's