modbus?

[tragically1969]

It IS a good rough 'order or magnitude' approximation to expect about a second for each modbus request/response (each command). To expect anything close to the next faster order of magnitude(100mS)will be disappointing when you start measuring your design's response.

I'm sorry if I wasn't clear that a rough approximation is just that...rough. We do a lot of things in engineeering where we try to approximate within an order of magnitude when we are considering a design. The closest order of magnitude when roughing out modbus speed is to figure around a second per request/response and you will be in the ballpark.

The beauty of modbus is its incredible simplicity. The trouble with modbus is its incredible simplicity. It is a shared communication bus with absolutely no provisions to determine the speed of masters and slaves: there is no holdoff algorithm to change delay in case of collisions or slow slaves so devices usually take a fairly pessimistic view in terms of the amount of time they wait between a request and a response. And keep in mind absolutely EVERY command is a request/holdoff for the slaves to see the command and bus to settle/response.

Hence the delay in each request/response on the order of hundreds of milliseconds. And that applies to each request/response. So if it takes a couple/three commands to perform a logical operation (very common), you are up at a second for a logical operation.

In terms of 'order of magnitude' rough approximations, you will be hard pressed to find a modbus system that can request/respond faster than 100mS reliably. The majority are in the hundreds of milliseconds by my experience. The only time I've seen around 100mS is for proprietary systems that knew the physical topology (short wiring + fast real-time OS slave command parsers + proper termination of every wire) and had custom drivers with very short times to allow the bus and all receiving devices to get off the bus for the slave response. Its much more common to be in the hundreds of milliseconds since device manufacturers have to expect slaves with typical OS ioctl times (100mS or longer) for the command parsers and long transmission lines that are not optimally terminated. Command parsers for the slaves are difficult to write without a context switch and context switches are notoriously expensive.

At one point in my career I designed protocol analyzers for three years; designed the hardware, wrote the drivers (including modbus), and tested across many, many brands. I've written and debugged modbus code in C, perl, assembly. I've had oscilloscopes stuck on many brands of modbus implementations including much of the Allen Bradley and GE PLC product lines.

So I'll stick with my assertion that 1 second is the closest order of magnitude to expect for a full request/response cycle for each modbus command - you will likely do better, but certainly not by an order of magnitude.

Thats all very well and informative, but you have still neglected to tell us which PLC and any real world data about you application\hardware you are talking about.....

 

[KalleOlsen]

@tragically

I have limited modbus experience (once in a blue moon), but a couple of months ago I was interfacing some different equipment using a Vipa 315 as RTU master. The slaves were a net analyser, earth fault monitor, gas analyser a few cos-phi controllers. Different makes.

There were limitations on the slaves according to the tlg.length, the 'worst' was 28 bytes, and for one other the poll rate was also restricted to 1000ms. This was read from the manuals.

So if you want quickest possible scan times, you should keep your motor control bus clean and be careful to add other units.

Kalle

 

[tragically1969]

@tragically

I have limited modbus experience (once in a blue moon), but a couple of months ago I was interfacing some different equipment using a Vipa 315 as RTU master. The slaves were a net analyser, earth fault monitor, gas analyser a few cos-phi controllers. Different makes.

There were limitations on the slaves according to the tlg.length, the 'worst' was 28 bytes, and for one other the poll rate was also restricted to 1000ms. This was read from the manuals.

So if you want quickest possible scan times, you should keep your motor control bus clean and be careful to add other units.

Kalle

Again, informative and concise, but we are talking PLC here, i dont even know what a Vipa 315 is.

All i was trying to do was ascertain which PLC the guy was using that was talking to 8 drives with such poor performance.........he has not offered this.......i dont know why.

 

[TurpoUrpo]

Again, informative and concise, but we are talking PLC here, i dont even know what a Vipa 315 is.

All i was trying to do was ascertain which PLC the guy was using that was talking to 8 drives with such poor performance.........he has not offered this.......i dont know why.

Vipa 315 is a PLC.

 

[Clay B.]

Just some info on S7-200

I use the S7-200 alot. Modbus is something I have done a little. Here is some info along with what others have pasted that may help you. It comes from the Siemens Help web site which is real handy for stuff like this.

http://www.sea.siemens.com/us/Produ...ps_and_Tricks/S7-200/Pages/S7-200-Tip-41.aspx