Hello
I needs PLC for about 96 to maximum about 128 Digital Input and Output, at least 8-12 temperature analog input, and intensive RS485 connection, I just use PLC for input output module, all processing is done in high-reliability computer server through modbus/RS485 connection, I needs maybe at least 100-500 connections per seconds between server
Do you think modbus protocol is enough for my case ?, and do you think Schneider TM251MESE is a good idea ?, or do you have any advise ?

 

I needs maybe at least 100-500 connections per seconds between server

Are you sure you really need that many exchanges per second? That is quite a lot. Over half your data is (assumed 16 bit) temperature data. A typical PLC temperature input card might only sample the input 4x per second. So you would be transmitting redundant information 99.2% of the time if sending it 500x per second.

That is assuming your PLC can actually talk that fast, and your server can listen that fast. Which they almost certainly can't. Especially on the server side, since it is assumed the server is multitasking, not dedicated to just talking to this PLC. On the PLC, logic scan time might be more than 10mS, which means you are expecting more than one transmission per PLC scan even on the low end of your stated requirements, and that's an unrealistic expectation.

Do you think modbus protocol is enough for my case ?

128 digital I/O = 128 bits
(12) 16-bit analog values = 192 bit
Total = 320 bits.
Not accounting for handshakes, headers, etc:
Sending 320 bits 500x per second = 160,000 bits per second. For safety margin i will double this, 320,000 bits per second.
Typical modbus RTU (RS485) devices are not capable of baud rates higher than 115,200 bits per second (9,600 or 19,200 are typically used, 90% of the time).

I would be looking at Modbus TCP. It is modbus protocol over ethernet, much faster*. Depending on what is doing the talking on the server, it should be effortless to switch. When I do this in python, it is just a matter of changing a COM port parameter to an IP address parameter.

do you think Schneider TM251MESE is a good idea ?, or do you have any advise ?

I have zero experience with Schneider PLCs so cannot comment on your proposal other than to suggest you confirm it has native support for modbus TCP. It is an industry standard protocol but some stubborn manufacturers (Allen Bradley) don't have native support for it.

My choice would be AutomationDirect Productivity 1000 PLC for cost effectiveness, ease of ordering (if you're in the USA), and availability.

I would encourage you to reevaluate your needs with respect to comms cycle time. Most applications only really demand exchanges once every second or so.

*EDIT: expounding my claim that modbus TCP is much faster than modbus RTU. Assuming a direct connection from PLC to server. If it is on a switch with other devices, then it is subject to network traffic. Depending on other devices, RTU can be faster despite much lower bitrate.

 

Are you sure you really need that many exchanges per second? That is quite a lot. Over half your data is (assumed 16 bit) temperature data. A typical PLC temperature input card might only sample the input 4x per second. So you would be transmitting redundant information 99.2% of the time if sending it 500x per second.

That is assuming your PLC can actually talk that fast, and your server can listen that fast. Which they almost certainly can't. Especially on the server side, since it is assumed the server is multitasking, not dedicated to just talking to this PLC. On the PLC, logic scan time might be more than 10mS, which means you are expecting more than one transmission per PLC scan even on the low end of your stated requirements, and that's an unrealistic expectation.


128 digital I/O = 128 bits
(12) 16-bit analog values = 192 bit
Total = 320 bits.
Not accounting for handshakes, headers, etc:
Sending 320 bits 500x per second = 160,000 bits per second. For safety margin i will double this, 320,000 bits per second.
Typical modbus RTU (RS485) devices are not capable of baud rates higher than 115,200 bits per second (9,600 or 19,200 are typically used, 90% of the time).

I would be looking at Modbus TCP. It is modbus protocol over ethernet, much faster*. Depending on what is doing the talking on the server, it should be effortless to switch. When I do this in python, it is just a matter of changing a COM port parameter to an IP address parameter.


I have zero experience with Schneider PLCs so cannot comment on your proposal other than to suggest you confirm it has native support for modbus TCP. It is an industry standard protocol but some stubborn manufacturers (Allen Bradley) don't have native support for it.

My choice would be AutomationDirect Productivity 1000 PLC for cost effectiveness, ease of ordering (if you're in the USA), and availability.

I would encourage you to reevaluate your needs with respect to comms cycle time. Most applications only really demand exchanges once every second or so.

*EDIT: expounding my claim that modbus TCP is much faster than modbus RTU. Assuming a direct connection from PLC to server. If it is on a switch with other devices, then it is subject to network traffic. Depending on other devices, RTU can be faster despite much lower bitrate.

On server side there is not a problem, that server is very reliable and dedicated to PLC control and software interface related to PLC control only, also it's a high-availability server, means it's actually two server used, one running and one standby, if one is failed or under-maintenance another one will automatically take-over, it's also a server with very high computation power used 32 core EPYC and dedicated GPU, I will sure it's have enough computation capability for PLC purpose, even maybe overkill

Yes, of course I mean modbus TCP, server will use two network cards dedicated to PLC and connected directly

Do you think it's not good idea to have too much data exchange ?, I will use it for smart building system, for door access control, temperature monitor, power transfer switch, security systems and more..., for example it's will be response will PLC get signal from door micro switch and another, and then communicate with surveillance camera for face recognition, and take actions,...

Do you think how many much connection I can use per seconds ?, for better reliability

Some task that needs very frequent communications like for power switching it can be handled by PLC instead by server then intervened by server if needs only, so I can reduce comm needs

 

What sort of application requires such a high communications rate? What is the process??
I have built several systems that used PLC I/O and a computer for control. Never needed a data rate nearly that fast. A sjngle Ethernet line was adequate.
Or is this a project where some customer has a list of requirements but will not share any information???

 

I think it is best to have a distributed control system such that

On server side there is not a problem, that server is very reliable and dedicated to PLC control and software interface related to PLC control only, also it's a high-availability server, means it's actually two server used, one running and one standby, if one is failed or under-maintenance another one will automatically take-over, it's also a server with very high computation power used 32 core EPYC and dedicated GPU, I will sure it's have enough computation capability for PLC purpose, even maybe overkill

Yes, of course I mean modbus TCP, server will use two network cards dedicated to PLC and connected directly

Do you think it's not good idea to have too much data exchange ?, I will use it for smart building system, for door access control, temperature monitor, power transfer switch, security systems and more..., for example it's will be response will PLC get signal from door micro switch and another, and then communicate with surveillance camera for face recognition, and take actions,...

Do you think how many much connection I can use per seconds ?, for better reliability

Some task that needs very frequent communications like for power switching it can be handled by PLC instead by server then intervened by server if needs only, so I can reduce comm needs

I think it is best for low level control to be carried out by low level control devices. Not by the server. The server should be for monitoring and high level control. I don't know ow what this means for you, with building automation. I am not familiar with that area. My area of expertise is control systems for industrial machines. But maybe I can provide an example to illustrate.
Motion sensor in a hallway. This is usually directly tied to a light, but maybe in a more advanced application it will go to a PLC that in turn switches the light, and also sends a signal to a PTZ camera to look in the direction of the detected motion. The server should not be responsible for sending those signals IMO. It is too time-critical. The detection of motion and sending of command to the PTZ camera should happen locally and be pretty much instant, not waiting on reply from the server to do any action. The PLC might send a signal to the server at the same time so that server can log the motion event with a timestamp, but that's it.

 

I think it is best to have a distributed control system such that

I think it is best for low level control to be carried out by low level control devices. Not by the server. The server should be for monitoring and high level control. I don't know ow what this means for you, with building automation. I am not familiar with that area. My area of expertise is control systems for industrial machines. But maybe I can provide an example to illustrate.
Motion sensor in a hallway. This is usually directly tied to a light, but maybe in a more advanced application it will go to a PLC that in turn switches the light, and also sends a signal to a PTZ camera to look in the direction of the detected motion. The server should not be responsible for sending those signals IMO. It is too time-critical. The detection of motion and sending of command to the PTZ camera should happen locally and be pretty much instant, not waiting on reply from the server to do any action. The PLC might send a signal to the server at the same time so that server can log the motion event with a timestamp, but that's it.

That's good idea too... but in my case server is still needs process face recognition by GPU methods... in my Client's camera can't support direct signal from sensor... any possible scenario for this will be GPU server do face recognition all the time and PLC will send signal to server in even of detection, two task running separately...

 

What sort of application requires such a high communications rate? What is the process??
I have built several systems that used PLC I/O and a computer for control. Never needed a data rate nearly that fast. A sjngle Ethernet line was adequate.
Or is this a project where some customer has a list of requirements but will not share any information???

Yes, that's my Client's requirements... it's for security system, door access system, power transfer switch, and more...

 

What do you think @strantor ?, it is better to use lower end class 3x independent Zelio Logic SR3 with lower computation capacity or 1x Modicon TM251 with rich features ?, cost is equivalent

 

What do you think @strantor ?, it is better to use lower end class 3x independent Zelio Logic SR3 with lower computation capacity or 1x Modicon TM251 with rich features ?, cost is equivalent

That would depend on installation cost then, and I would assume the smaller ones would be cheaper because they can be installed closer to the sensors they are responsible for.

 

Here we have again an individual seeking engineering device for inclusion in their engineering business decisions. Effectively seeking fairly complex engineering evaluations for free.
Does anybody else see a problem with that??

 

Here we have again an individual seeking engineering device for inclusion in their engineering business decisions. Effectively seeking fairly complex engineering evaluations for free.
Does anybody else see a problem with that??

You get what you pay for, and I make the (probably bad) assumption that everyone understands that. If a [prescribed by some rando on the internet based on fractional information] solution is all that the application demands, then I guess why would you go to the expense of consulting a local firm who has a portfolio of relevant experience?

That's only partially sarcasm. As it applies to this thread, almost entirely sarcasm. As it applies to some others, less so.

 

Does anybody else see a problem with that??

Hi Bill,
I don't have a problem with that.

You or any other member are not obliged to respond to any post, if they choose not to do so.

One of the functions of the Forums is to help others seeking advice with their specific project.

E