I am implementing the modbus protocol for TCP/IP. Per the TCP/IP implementation guidelines, I understood that a slave can handle upto 16 connections simultaneously. I believe this can be implemented using multithreading concept. But can a slave device (for eg: a PLC or embedded controller) handle 16 such threads in parallel without any issues? And another question, is there any other way to implement this without multi-threading concept?

 

Some can, some can't, some can't even handle one connection decently. Back to back packets will upset some. But, TCP/IP itself handles a lot of the issues. For the threading, etc. issues, I suggest you look at any number of OSS tools and implementations to see how this is handled in a more or less standard fashion. It's pretty much cookbook stuff and it's a bad idea to go rogue. Many, many examples to look at.

Regards,
cww

 

If by "implementing" you mean rolling your own, I would first ask "why"?
All slave devices are not created equal, so do not count on 16 channels on every one that you end up with. A lot of slave devices have limited processing power and will choke, stall or die if you attempt to read/write too fast.

Yes, if it supports 16, that means 16 simultaneous, but I would recommend that you set up your 'Master" device to use fewer. Normally 1 for reads and 1 for writes, 1 for data-grams, if needed.
Only look at multi-threading if you MUST have the extra speed and then use it on demand if the slave can handle it.

 

There is nothing to stop a Modbus/TCP server (slave) from handling as many simultaneous connections as it wants. The limitations of any particular PLC will be due to the internal software and resource limits. Some PLCs can only handle 4 connections at a time. If the Modbus/TCP server is a program running on a PC, there is no reason why it couldn't handle as many connections as the operating system will allow.

The thing to keep in mind is that as far as communications is concerned, the PLC is handling "connections", not "threads". Each client (master) would make one connection to the PLC. The client would send a command, wait for a response, send the next command, wait for a response, etc. It would then normally wait some period of time (the polling rate) before repeating the sequence of commands. As far as the communications is concerned, there should only be one request or response in the pipeline between each client and the server.

As far as implementing the software is concerned, you can do it synchronously, threaded, or asynchronously. However, keep in mind this is an internal software implementation and does not affect how the messages go out on the wire (other than how many simultaneous conversations you can keep going).

Synchronous software is for where you need the simplest possible implementation and don't need multiple simultaneous conversations (e.g. between a client and a couple of servers).

As far as threaded versus asynchronous is concerned, asynchronous has less overhead but threaded software is more common because that is what most programmers are familiar with.

All you have said about your application is that you are implementing the protocol. It is difficult therefore to go into much more detail. If you want to say what you are doing (client or server, embedded or on a computer, how many connections you want to be able to handle, etc.) then we can talk about it more if you wish.

 

Is this really necessary ?
Modbus TCP is already available as Open Source.

We have this:
http://pvbrowser.de/pvbrowser/sf/manual/rllib/html/classrlModbus.html

The Modbus class is part of
http://pvbrowser.org

The rllib library can also be downloaded sepately. The license is LGPL.
http://pvbrowser.de/pvbrowser/tar/rllib.tar.gz

 

Hello,

> Is this really necessary? Modbus TCP is already available as Open Source. <

Sure it is; some possible reasons.

#1 Maybe the guy wants to learn how to program for this problem because the next time there might not be any 'Open Source' implementation.

#2 He has in-house coding standards that must be adhered to.

#3 He is using a different language from the 'Open Source'.

#4 He is a programmer and wants to program.

#5 He is under contract and can not use any 'Open Source' code.

#6 He looked at the 'Open Source' code and did not like the format/structure/naming/etc.

I could go on.

Cheers,

Mark
http://www.peakhmi.com/

 

Thanks a lot for you suggestions and ideas. I would like to implement the master in a PC and Slave - an embedded board using TCP/IP as a communication medium. I would like to build stacks for both master & slave. How many simultaneous connections are possible in a slave? Also please guide a way to proceed on this..

 

A slave (server) can have as many connections as you want to support. That is all a matter of computing resources. Some PLCs support as few as four connections. I wrote a server that ran on a PC that I tested with more than 150 connections.

What you have to do is to design your software and see how much you can do. The more connections the better. The problems you will have will be related to how much RAM and speed you have available. Presumably, this thing needs to do more than just process Modbus messages.

I would suggest getting the code for constructing and interpreting messages working on a PC first. Then when you know that part is working, figure out how this can fit in with whatever else the server is doing (whatever its main function is).

Once you have it working there, you need to start doing some code benchmarking to see what it is capable of in terms of speed. There will be some limit to how many messages per second you can process based on how fast your board is and what other tasks have to be run as well. There is no point in allowing 100 connections if your board can only realistically process the polls for 4.

You also have to look at what your resource limits are. You said you are running it on an embedded board. Are you running it on the bare metal? If so then you will need a third party TCP/IP stack, as writing your own is usually too much work to be practical (Modbus/TCP runs on top of TCP/IP). In that case, what are the limits of the TCP/IP stack?

Are you running it on top of an embedded OS? If so, then are there any OS limitations?