I need a little guidance. specifically about the capabilities of using a micrologix 1400 for modbus comm.

i want to connect to around 50 devices using 2 no.s of ML1400 & then would need to transmit this data to Controllogix controllers through Eth/IP. i wanted to know what is the max. no of devices i can practically use with a ML1400.

how can i calculate the speed, delay & the rate of data transmission??

[email protected]

 

The Eth/Ip side of it is PDQ. Much faster than the Modbus side.

For the most part, you can make some good guesses about the response time for the polling by figuring out how many bytes will be in each message, figure 8 bits per byte at whatever baud rate you are using, add up all the individual values, and then add up all the individual delay times for each device. It is not real hard, but it can be time consuming. In the end, it may or may not be real close to what you actually have, because you probably miscalculated a bunch of the delay times, because they can be confusing the way they are stated.

The hard limit to the number of devices is the 8 bit address scheme of Modbus, so it is 256 less the addresses reserved. I forget how many are reserved. less than 10 IIRC.

There are some physical limits to RS485 or whatever you are using as the physical link to the devices. RS485 limits you to 32 devices, although you can extend that with repeaters, and it is not really a hard limit, in that it will work with 32 devices, but not with 33. That's just the bare minimum it is required to work with.

I had a Modbus network that took over 15 seconds to poll all the slaves. It was quite acceptable for what it was doing.

If the data is real time critical, Modbus is not a good choice. It is relatively slow. Without knowing how much data you require from each device, and what baud rate you plan to run at, it is not possible to give you any idea what your polling cycle might be.

--
Bob

 

Thanx for replyin bob ,

but i'm an amateur & thus was not quite able to process the whole info provided by you ,

for example, i don't know what exactly you mean by " The Eth/Ip side of it is PDQ. Much faster than the Modbus side."

what is PDQ & how can i use it in my case..also how to implement it & how faster it is?

you said "I had a Modbus network that took over 15 seconds to poll all the slaves. It was quite acceptable for what it was doing. "

how many devices were in that n/w & of what nature...it'll help me calculate relatively...,

Also , i don't know how to increase or decrease the 'Response & Request time', as in how can i configure these ?

Thanx again for taking time out for replying...

Pranav Sharma.
[email protected]

 

You're not going to be able to do more than make a good guess at the speed of a serial network without actually setting it up and testing it. The bottlenecks will be:

1) the speed of the serial transmission itself (how many bits per second),

2) the length of time between a request being received, and the field device responding to it,

3) the delay times between polls,

4) the time the ML1400 takes to process each message and get on to the next one.

You can figure out #1 fairly easily from the baud rate and how much data you need to send (plus add a dozen bytes or so for protocol overhead).

#2 is usually very hard to get from device specs. You may have to contact the device manufacturer for details.

#3 will often depend on installation dependent factors that no one can predict.

#4 is going to depend on what is happening in the PLC.

What you should do is start on the problem from the other end. Figure out what rate your application needs, and then make some rough guesses as to whether you can meet that based on the above factors. If your estimates show you should have lots of margin (e.g. the network is several times faster than you need), then you are *probably* OK. However, you should still set up some sort of small scale test to confirm it.

If your estimates come out close to the requirements, then there is a very good chance you will have a problem and you will really only know for sure by actually setting up a network and testing it.

 

PDQ = pretty darn quick. I probably should have said the ethernet side of it is several orders of magnitude faster than the modbus side so that should not be an issue.

I do not recall how many slaves I had that took 15 seconds to poll. It might have only been two of them, but it was reading a lot of registers (1000s).

I also set it to run pretty slowly (9600 baud if I recall) since the data rate was not critical and these kind of things tend to run a lot more reliably at lower baud rates.

Most slaves have delays that can be set to whatever you want, although some are fixed or semi-fixed. A couple I have run across the numbers in the settings were multiples of bits, so if you put in 1 the delay was 1 bits worth of delay. Others were in milliseconds, and others I never figured out what they were in. I just set it by trial and error.

The advise to set up a network of a couple devices and see what it ends up being is pretty good advice though.

If your data is time critical you would not have selected Modbus in the first place. With 15 devices, 9600 baud, and one message each way, I would expect a cycle time to poll all 15 slaves in the under 5 seconds range. It may take some tweaking and reading of manuals to get there though. Or some chats with tech support for the slaves.

Some VERY rough calculations

9600 baud is about 10,000 bits per second

say you are reading 25 registers from each device so maybe 500 bits

each poll request to a slave is maybe 10 characters - call it 100 bits

so a complete poll cycle is maybe 15,000 bits or 1.5 seconds

if you have 50 millseconds of delay between messages the delay for 30 messages is 1.5 seconds total delay

--
Bob

 

Thanx alot Bob ,

this does gives me a good idea for speculation. I hope i can always ask if i have some query again...thanx for the help, its highly appreciated.

Pranav Sharma.

 

Thanx for the guidance griffin...

I think i got your point & would now try to calculate.

But i was wondering, as replied by bob above, the delays are significant even for a couple of devices. Now i have to use around 25 devices per controller. what rough estimate can you provide for it...??

Thanx for the help again..

Pranav Sharma.
[email protected]

 

I think that Bob Peterson gave a pretty good estimate above. I will reiterate it, but keep in mind that we have no idea of the details of what you are trying to do. All I can do is give an example based on a hypothetical situation.

1) Let's assume you are reading 25 holding registers from each node, and that is all you are doing. 25 registers * 16 bits = 400 bits. Lets add another 100 bits for the message overhead, plus the original request. That gives us a total of 500 bits. 500 / 10,000 bits per second = 0.05 seconds.

2) The field device will need some time to "think about" its response before replying, so let's allow 0.05 seconds for that. This also gives use a message delay between the request and the response.

3) The PLC will have some sort of delay between each set of messages while it processes each message, so let's add another 0.05 seconds delay for that. This also effectively gives us a message delay between the response and the next request.

So far, we are up to 0.15 seconds per field device.

4) There are 25 field devices, so 25 * 0.15 = 3.75 seconds. We could probably state this as 4 or 5 seconds.

So what we can say is that for this very hypothetical situation, we might be able to performa a complete polling cycle in 4 or 5 seconds. If your target was 60 seconds, then you would probably be OK. If your target time was 5 seconds then I would say there is not enough margin to rely on an estimate, and you would need to set up the actual network and test it. You are going to have to put your own numbers in here though, we can't do this engineering for you.

If you are really concerned about speed, then you should be looking at either splitting the network so you have fewer nodes per PLC, or else looking to see if you can use Modbus/TCP (with Ethernet) instead of Modbus/RTU. Serial networks are not meant for high speed except over very short distances under ideal conditions.