HMI for LOTS of screens and tags

[MarkTTU]

Working on a project that is extremely large and running into performance issues with the C-more that we've been using extensively for a long time. We've got over a thousand tags on a single screen and hundreds of screens in the project. Anyone have recommendations for an HMI that's higher performance than the C-more and can speak Domore symbolic? We're looking for either a headless type solution where we can supply our own large touch monitor or something with a screen that's around 19".

What kind of update rate are you looking for?  Do the tags not on the active screen have to be updated anyway, perhaps for logging?  Some HMI's (not sure about C-More) only poll tags necessary for the current screen or logging.  How many tags are there total?  Hundreds of thousands or is there a lot of overlap?

I've never done anything like that but it wouldn't surprise me if to get the bandwidth you need you might end up streaming data from the source PLC.  Also, I think you'd get better performance if there is a lot of logging beyond the animation-visible tags, if there were a database machine collecting and logging the data, and then maybe the HMI could get animation data from the database server as a secondary process (probably tag writes would still go to the PLC).

PC-based HMI's like DAQ Factory might help.  Many have scripting capability and allow you more control over polling.    Some of them can also be used with OPC servers, which would give you another option to pursue.

Finally, will Do-More act as a E/IP producer?  The response time on E/IP messages is in the microseconds.  Not sure about poll rate, but it has to be pretty good.

We're looking for an update rate that's sub 1s for all objects on the screen; ideally would be sub 0.5s. Right now we're running 2.5-3s on our "home" page. Worth noting that changing to a page on the Cmore that has fewer tags brings the performance back to what we're used to seeing (sub 0.5s).

The Cmore only polls tags on the active screen + trend graphs + logging. We're doing logging in the PLC so the Cmore isn't pulling any tags for that and we haven't made any trend graphs yet so we're only dealing with the tags that are on the active screen.

Total number of tags in the project is just shy of 4k right now, but I expect there'll be another 3-4k before we finish writing the code. Total on the page that's slow is right at 1k.

Not using E/IP at all. Strictly Domore symbolic between the Cmore and the Domore. The Domore is doing a few Domore to Domore and Domore to DirectLogic comms and eventually will also be doing some HTTP_POSTs later, but that part isn't written yet.

[franji1]

Just a thought - you might be able get more throughput if you utilized 2 Do-more symbolic devices, one to the on-board Ethernet port IP Address and one to an Ethernet POM IP Address?

Then on the "home page" put 500 tags on one driver, 500 on the other.  The PLC can process both ports independently.  It may not be double, but I bet it's 1.5x faster?  This is assuming that the C-more can transact tags on different drivers in parallel, not in series (I do not know).  Not sure how easy it is to move a C-more tag from one driver to another (it may not be easy).

[MarkTTU]

I think we're hitting a limit on the Cmore CPU but that's just based on seeing it's CPU sit at 100%. If it can process two different drivers in parallel that might open up a few possibilities.

[Controls Guy]

I was thinking you might be limited by the processing power of the HMI, too.  A PC would give you more flexibility protocol-wise, but might also partially or completely fix the issue just by virtue of being a better platform.   Will respond to your other post tomorrow.

[ADC Product Engineer]

I think we're hitting a limit on the Cmore CPU but that's just based on seeing it's CPU sit at 100%. If it can process two different drivers in parallel that might open up a few possibilities.

It can handle quite a few different devices to the same IP address.  I don't know that we have ever tested it that way to see if there is a speed increase.  Good thought though.

[MarkTTU]

I think we're hitting a limit on the Cmore CPU but that's just based on seeing it's CPU sit at 100%. If it can process two different drivers in parallel that might open up a few possibilities.

It can handle quite a few different devices to the same IP address.  I don't know that we have ever tested it that way to see if there is a speed increase.  Good thought though.

Ok, we tried splitting the tags into two separate devices polling the same Domore IP and it made things worse by about 0.5s. Sounds like multiple devices adds overhead.

[MarkTTU]

PC-based HMI's like DAQ Factory might help.

Never looked at DAQ Factory before, but that could be a possibility. I don't see anything about the Domore specifically, but they do mention if there's a DLL from the manufacturer it should be simple. Do you know if there's a DLL for the Domore ethernet protocol? Asking out of ignorance because it's just always been there in Cmore 

[franji1]

Ok, we tried splitting the tags into two separate devices polling the same Domore IP and it made things worse by about 0.5s. Sounds like multiple devices adds overhead.

If you have an Ethernet BX-POM, try it with 2 different IP addresses, but to the same PLC.

[Controls Guy]

We're looking for an update rate that's sub 1s for all objects on the screen; ideally would be sub 0.5s. Right now we're running 2.5-3s on our "home" page. Worth noting that changing to a page on the Cmore that has fewer tags brings the performance back to what we're used to seeing (sub 0.5s).

The Cmore only polls tags on the active screen + trend graphs + logging. We're doing logging in the PLC so the Cmore isn't pulling any tags for that and we haven't made any trend graphs yet so we're only dealing with the tags that are on the active screen.

Total number of tags in the project is just shy of 4k right now, but I expect there'll be another 3-4k before we finish writing the code. Total on the page that's slow is right at 1k.

Not using E/IP at all. Strictly Domore symbolic between the Cmore and the Domore. The Domore is doing a few Domore to Domore and Domore to DirectLogic comms and eventually will also be doing some HTTP_POSTs later, but that part isn't written yet.

OK good, so only 8K tags total, and more importantly, only 1000-1500 concurrent.  I think you can probably do this with Modbus/TCP, at least on the Do-More end.  I thing the C-More may be limiting things, and a PC might do better, with more processing power first, and more control over polling second.

I mentioned E/IP as a possible alternative because the response time (and hopefully polling rate) is good.   I know how table-based protocols work, and have written AB drivers for DF1 and old version AB-Ethernet (PCCC, the one the software calls ABETH), which is basically just DF1 over Ethernet....but I have very little knowledge how tag-based comms like E/IP or Do-More symbolic work under the hood.   Seems like it would be very inefficient if you have to either transact the tags individually or transmit the entire list of tag names you want every time you poll.  Maybe the "producer/consumer" model means whatever you subscribe to, the producer creates and remembers a virtual table, so it sends it all burst mode and avoids the performance hit of you having to enumerate all the tags every time.

[Controls Guy]

Never looked at DAQ Factory before, but that could be a possibility. I don't see anything about the Domore specifically, but they do mention if there's a DLL from the manufacturer it should be simple. Do you know if there's a DLL for the Domore ethernet protocol? Asking out of ignorance because it's just always been there in Cmore 

No, DAQ Factory doesn't have a Do-More driver built in.   It can do K-sequence and Modbus/TCP, and anything you can find an OPC server for (I think maybe Kepware has an OPC driver for Do-More).  I've done many many projects with DAQ Factory and Do-Mores, but I always use Modbus/TCP.  Knowing this in advance, I just design the PLC program with anything that needs communicating to the HMI in the MHR/MC, etc., registers.

No, there's not a Do-More protocol DLL available.  The protocol definition is not yet widely available (soon I hope).   Now that's not necessarily a huge problem for me because I tend to like to "black box" apps anyway, rather than use a manufacturer-specific protocol, because I don't WANT to tie the HMI and PLC that tightly together.  I hear Siemens push "Totally Integrated Automation" and shudder, for example.  I even use generic protocols when I'm using a hardware HMI that actually has a driver for the PLC in question.  I even do that when the PLC and HMI are the same brand (and not Modicon).  Modularity and indirection are good things IMO.

[ATU]

Not knowing what your setup is, one other thing to consider is how you have your data organized. Can it be arranged in groups and only update the group when data changes in that group. I let the PLC update the HMI. That has worked well for me when there is a lot of data involved.

[MarkTTU]

Ok, we tried splitting the tags into two separate devices polling the same Domore IP and it made things worse by about 0.5s. Sounds like multiple devices adds overhead.

If you have an Ethernet BX-POM, try it with 2 different IP addresses, but to the same PLC.

Ordered one yesterday, but they're on back order. Soon as we get it we're going to try this for sure. We've keen known to use 3 ECOM100s in a 205 base before to increase comms speed so wouldn't be the first time we've done multiple ethernet links to one PLC.

[MarkTTU]

Never looked at DAQ Factory before, but that could be a possibility. I don't see anything about the Domore specifically, but they do mention if there's a DLL from the manufacturer it should be simple. Do you know if there's a DLL for the Domore ethernet protocol? Asking out of ignorance because it's just always been there in Cmore 

No, DAQ Factory doesn't have a Do-More driver built in.   It can do K-sequence and Modbus/TCP, and anything you can find an OPC server for (I think maybe Kepware has an OPC driver for Do-More).  I've done many many projects with DAQ Factory and Do-Mores, but I always use Modbus/TCP.  Knowing this in advance, I just design the PLC program with anything that needs communicating to the HMI in the MHR/MC, etc., registers.

No, there's not a Do-More protocol DLL available.  The protocol definition is not yet widely available (soon I hope).   Now that's not necessarily a huge problem for me because I tend to like to "black box" apps anyway, rather than use a manufacturer-specific protocol, because I don't WANT to tie the HMI and PLC that tightly together.  I hear Siemens push "Totally Integrated Automation" and shudder, for example.  I even use generic protocols when I'm using a hardware HMI that actually has a driver for the PLC in question.  I even do that when the PLC and HMI are the same brand (and not Modicon).  Modularity and indirection are good things IMO.

Good to know. We're trying to build our program to be modular at the program level so lots of user defined memory blocks in the BRX and that's been the driving reason to use the Domore symbolic protocol; so we can talk to those custom memory blocks. Might be something that's not worth paying the performance price for doing though if it turns out the protocol itself is causing drastic inefficiencies. So far I haven't seen much that trips up a BRX performance wise, but heaven knows we're throwing a lot at it with this project.

[Controls Guy]

I think you could choke the C-More before the BRX.

[pbw]

Working on a project that is extremely large and running into performance issues with the C-more that we've been using extensively for a long time. We've got over a thousand tags on a single screen and hundreds of screens in the project. Anyone have recommendations for an HMI that's higher performance than the C-more and can speak Domore symbolic? We're looking for either a headless type solution where we can supply our own large touch monitor or something with a screen that's around 19".

Are you using a EA9 Cmore?
I have noticed those are slower to respond to touch and refresh rates than the EA7s, even if the project and the amount of tags on it aren't that huge.