CLX with 50 HMI (Ethernet)

We are planning to migrate an existing solution to a CLX system. There are 50 Embedded PC talking now with an SQL DB (server). We'd like to have these Embedded PC running Windows CE 7 and acting as a standalone HMI (install Indusoft runtime on each unit). Communication will be over Ethernet IP with a 1756-EN2T. Is 1756-L73 good enough for this application? Has anybody tried to connect 50+ HMI to one CPU? We don't have an option to go with a server/client type of application (having only the server talking to the PLC).
Thanks.
CoS

50 is a lot of HMIs. Fifty Indusoft runtime licenses? That will add up.

Are you going to use a dedicated Ethernet card just for the HMIs?

Yes, dedicated Ethernet card for communication. The question I have is if the CPU (processor) can handle 50 HMI. I could add a second EN2T card if needed, there is still room on the chassis.

1756-EN2T card has 128 TCP/IP connections and 256 Logix connections. Not sure which type your HMI would use. I know PanelView opens 3 connections by default (2 read and 1 write) but you can limit it to 1 read and 1 write in the registry.

The 1756L73 controller supports 500 connections, and the EN2T supports 128 connections. As discussed, some HMIs use 3 connections. If this is the case for your HMI (total 150), you will be able to get around it by adding an additional EN2T card, and pointing 25 HMIs at one and 25 at the other.

Just because you can max CIP connections in this way doesn't mean you should do it. The CPU still has to process all the comm requests which will impact logic execution.

I think this is a poor idea, use redundant IO servers to handle the HMI traffic.

Paully's5.0 said:

Just because you can max CIP connections in this way doesn't mean you should do it. The CPU still has to process all the comm requests which will impact logic execution.

I think this is a poor idea, use redundant IO servers to handle the HMI traffic.

Click to expand...

I know this might not be the best approach but we are looking for a solution that will have minimum impact on the existing configuration. Why do you think the communication will affect the logic execution? I thought the PLC has 4 processors - one of them dedicated for communication only. The process is not fast, I'm not concerned about the execution time as long as stays below 100 ms. By the nature of the application any server will have to be redundant and also duplicate - so we will need 4 servers altogether. If we go with IO server solution, all HMI will have to detect when the main pair of IO servers fails and switch to the backup pair of servers automatically. This will be a very expensive and complicated option... The PLC is already in a redundant configuration.
Thanks.

cstca said:

Why do you think the communication will affect the logic execution? I thought the PLC has 4 processors - one of them dedicated for communication only.

Click to expand...

4 processors? That is news to me. To serve up 50 HMIs the CPU would have to dedicate 90% of it's time processing communications requests and 10% of it's time executing logic. Either logic suffers, or comms suffers (HMI lag, timeouts, poor response). Don't forget you still need to be able to get online with the PLC if you want to do any changes.

cstca said:

The process is not fast, I'm not concerned about the execution time as long as stays below 100 ms.

Click to expand...

You would have to explain your process, under 100ms is fast in my world.

cstca said:

By the nature of the application any server will have to be redundant and also duplicate

Click to expand...

Please elaborate, I've never heard of redundancy of redundancy. I'm sure it's out there, but I'd have to believe it's all virtualized.

cstca said:

- so we will need 4 servers altogether. If we go with IO server solution, all HMI will have to detect when the main pair of IO servers fails and switch to the backup pair of servers automatically.

Click to expand...

You would have to explain this further, most HMI software that is capable of redundancy will automatically fail over if configured properly.

By all means, give your 50 HMIs a shot and tell us how it turns out. Perhaps your HMIs are looking at only 10 tags each, so sure that might just work.

paully's5.0 said:

just because you can max cip connections in this way doesn't mean you should do it. The cpu still has to process all the comm requests which will impact logic execution.

I think this is a poor idea, use redundant io servers to handle the hmi traffic.

Click to expand...

+1.

cstca said:

IBy the nature of the application any server will have to be redundant and also duplicate - so we will need 4 servers altogether.

Click to expand...

I don't know your application, but why would you need 4 servers instead of 2? Your PLC is a single point of failure anyway...

I agree with everyone else, 50 HMIs is a lot. I think that gets near the limit for how many clients some SCADA servers can handle, expecting that from a PLC is a recipe for disappointment.

Paully's5.0 said:

4 processors? That is news to me. To serve up 50 HMIs the CPU would have to dedicate 90% of it's time processing communications requests and 10% of it's time executing logic. Either logic suffers, or comms suffers (HMI lag, timeouts, poor response). Don't forget you still need to be able to get online with the PLC if you want to do any changes.



You would have to explain your process, under 100ms is fast in my world.



Please elaborate, I've never heard of redundancy of redundancy. I'm sure it's out there, but I'd have to believe it's all virtualized.



You would have to explain this further, most HMI software that is capable of redundancy will automatically fail over if configured properly.

By all means, give your 50 HMIs a shot and tell us how it turns out. Perhaps your HMIs are looking at only 10 tags each, so sure that might just work.

Click to expand...

The main PLC detects vehicles passing certain points on this location and update info on a separate SCADA system.
If the main building where the servers are located is down (e.g. power lost) the customer wants to be able to continue operating by having another set of servers on a remote location. This is the current solution in place for SCADA - they have duplicate number of SCADA clients, half looking at one pair of servers, the other half looking at the remote servers (virtualized). If the main pair of servers is down, they will use the clients (laptops, WiFi) looking at the second pair of servers.

Each HMI will probably read/write 25 DINT. We already have one CPU and 2 EN2T to handle current communication (redundant PLC). We are planning to add one more CPU and one EN2T for the new HMIs. We have room for one more EN2T, if needed. We can go with L75 if this will speed-up communication.

Thanks.

Paully's5.0 said:

The CPU still has to process all the comm requests which will impact logic execution.

Click to expand...

How? If comm requests are governed by a reasonable system overhead time slice, process logic shouldn't be impacted.

That said, 50 HMIs are sure to keep one busy maintaining them.

50 HMIs can be done.

CIP connections will not be a problem. FTView uses up to 5 CIP connections, BUT just about every other software (3rd party) uses 1 or 2; one for reads and one for writes. Why, is way off topic.

The two areas I think you will want to look at are:

(1) Tag requests per second; keep it as low as possible.
total tags / update rate = requests per second.
25dints * 50hmi / (once per second?) = 1,250 requests per second

Put all 25 DINTs into a single array. If you use 25 scattered tags (ie. not in array) that would be worse.


(2) CLX scan times (system overhead time slice)
Best option, put all of your CLX routines into periodic tasks. It's more work to figure out execution times and adjust the task rates but it will help keep that deterministic (always under 100ms).
Then you can play with the system overhead time slice to deal with your HMI comms.
http://www.plctalk.net/qanda/archive/index.php/t-92523.html

So, You could use an inrack OPC-UA module and direct all the HMIs at that. That would offload the communications from the processor since the OPC-UA module would only have to request each tag once and be able to serve the data up to all your clients. (This assumes your HMI client is ok w/ OPC-UA)

Dravik said:

So, You could use an inrack OPC-UA module and direct all the HMIs at that. That would offload the communications from the processor since the OPC-UA module would only have to request each tag once and be able to serve the data up to all your clients. (This assumes your HMI client is ok w/ OPC-UA)

Click to expand...

Is this module from ProSoft (PC56-OPC)? I have to check if this is compatible with redundant CLX.
Thanks.