I need to know what is the word size & packet size for modbus comm ??

How much data can a ML1400 Read in 1 scan for 25 devices??

how can i increase/decrease turnaround delay ?

Is there a way to speed up the comm ??

 

You've posted this question under at least 4 different topic headings so far. I doubt that anyone is going to come up with a different answer this time. You provide virtually no information about what you want to do (what Modbus commands you executing, how many registers or coils you are reading or writing, what your target polling rate is, etc.), but you want a "quick fix" answer on how to make the hardware you selected "go faster".

If you've already bought and installed the hardware and found out after the fact that it's too slow, there's probably not much that any of us can do. These are the sorts of questions you should have started with before you bought anything.

If you want a more creative answer, then start at the beginning and describe what you are trying to accomplish, what the overall project constraints are, how much data is involved, what options you have considered, etc. In fact I think that if you do that, the answers may even become obvious.

On another thread you asked whether the MVM194 was better than the ML1400. I can't answer that question and I'm not sure that either would do what you want, but you also said that the "MVM194 Cost around 3 times the rate of ML1400. so unless its at least 3 times more efficient, i wont get the worth of my money". If the ML1400 won't do the job, then I don't see how you can call it a better value for your money. What you need to do is to draw up a *solution that will work* using each alternative, and then compare the relative costs. The value is in having a complete working system.

 

Well, you can count the bytes and figure out at what rate the transfer takes place, assume the reply can start in less than 1mS, calculate the time needed for a reply, and that'll be the ideal. But. But every slave operates on its own, so response varies. As the caveat emptor sign says, "your mileage may vary".

To do the calc, you've got to know what kind of data is being transported - coils? floating points? integers? and how many points there are in whatever format.

And you need to know how close data values are to one another in the Modbus slave map to determine whether you can read a large block of data and use what is needed (ignore the rest) or whether multiple reads to the same device are necessary to fetch data at varying sections of memory.

Some devices allow for custom mapping the slave's to Modbus map, to pack it so that it can be efficiently accessed (adjacent, contiguous registers). Others don't.

The format of a Modbus message is public information; the Modbus spec is publicly available.

The 51 page spec, MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b
http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf (take out spaces in URL)
describes in detail how each Modbus function code packs its Modbus message.

Essentially a request message is: address, function code, start address for data, quantity of data, CRC

And the reply message consists of address, function code, quantity of data, data, CRC.

So there's X bytes per message at whatever baud rate you think might be supported with some turnaround time and a reply message.

The maximum number of data bytes a Modbus PDU (message) can hold is 252 bytes. That 252 must include the quantity of data header and the data start address in a master's PDU.

 

>>>how can i increase/decrease turnaround delay ?

You can't really - this is a function of the slave devices. If they insist on a 25msec "dead time" between polls, you are stuck with this. Sending a new RS-485 request out too fast increases the probability of CRC error because of line-reflection noise from the last byte of the last response.

>>>Is there a way to speed up the comm ??

Use 25 serial ports and run 1 dedicated RS-232 or 485 line to each device. If 25 is unreasonable, then try for at least 2 or 4 lines. Splitting 25 devices into 4 strings of 6 (or 7) will give you 4 times better performance, plus reduce the risk that a single hardware failure kills comms to all 25 devices.

 

Thanx griffin ,

I do understand what you're saying , i have not bought any of the hardware yet. its just that so little of information if available on this subject, & whatever is available is not quite clear as well.

as for the other post, i am sorry , actually there was a typing mistake. i am trying to compare MVI94-MCM Modbus Module & ML1400 PLC.

I can mail you the details of the project i am working on, as you can understand i can not post it here.

Thanking you again.
Pranav Sharma
[email protected]

 

Here is a 6 step process you can use to solve your problem:

Step 1: Write down what devices you need to talk to, how may coils and registers you need to handle for each, what target polling rate you require, and what you are ultimately connecting all this to at the other end. Call this the "specification".

Step 2: Go to the Modbus.org web site, and look in their list of vendors for ones that sell "Modbus gateways" or "Modbus concentrators". Review the web sites of these companies to see what they have to offer.

Step 3: Send a copy of your specification to the companies you selected (or their local representatives) in step 2.

Step 4: Wait for their replies.

Step 5: Evaluate each of the replies carefully, making sure that your original specification was clearly understood. Repeat steps 1 to 5 as necessary.

Step 6: Select one of these solutions, purchase the hardware, and then install, commission, and test it.

Done.

On this forum we discuss problems of mutual interest. It's not a free consulting engineering service however, so nobody here is going to put a great deal of work into something that doesn't interest him. One of the companies (or their representatives) that you contact may be able to recommend a reputable consultant in your area who can handle this problem for you.

Lynn August Linse has already given you some detailed advice on how to handle this problem. He works for one of the vendors in this domain (serial communications converters and concentrators), and knows this subject better than anyone else you are going to talk to (including me). Have a look again at what he had to say. If the answers he gave do not sound promising, then there is probably nothing that anyone can do to help you with this.