Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: MarkTTU on August 20, 2019, 03:45:29 PM
-
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".
-
Not sure if anyone else speaks the symbolic protocol. I know Red Lion has a driver, but I don't know if it is the older driver (I think it is), or the newer symbolic protocol.
Might look at Indusoft SCADA. They have a Do-more driver.
-
Thanks, will check them out. Do you know if their driver is the old one or the newer symbolic one?
-
One thing nice about the Redlion is that you can setup a Modbus Communications block and update the HMI at your own timing using the Modbus Write Instructions in the BRX.
-
ModBUS is an option for sure, but there'd be a lot of copying back and forth to that memory block in the BRX given the number of tags we're working with.
-
Not sure Mark. I want to say Indusoft may have the symbolic, but I don't remember.
-
Not sure Mark. I want to say Indusoft may have the symbolic, but I don't remember.
Ok, thanks. Hopefully we'll find a way to squeeze a little more performance out of the Cmore; that's my first choice if we can make it happen.
-
Doubt that this is any faster, but... You've always wanted a bigger display option.
https://www.automationdirect.com/c-more/headless-hmi
-
Doubt that this is any faster, but... You've always wanted a bigger display option.
https://www.automationdirect.com/c-more/headless-hmi
That's actually what we're working with. It's a great little box, and talk about fun hooking it up to a 65" TV, but I don't think it's any faster than the 12" and 15" screens.
-
Man. I can't surprise you with anything cool anymore. ::)
-
Man. I can't surprise you with anything cool anymore. ::)
Oh I bet you can... but not on a public forum :-X
-
Surprised me! That is seriously cool. Of course that?s the only reason I come here, to be impressed.
-
Doubt that this is any faster, but... You've always wanted a bigger display option.
https://www.automationdirect.com/c-more/headless-hmi
Cool! I didn't know you guys were in that space! 8)
-
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.
-
Cool! I didn't know you guys were in that space! 8)
The headless C-more HMI was announced yesterday. You're behind the times. ;)
-
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.
-
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).
-
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.
-
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.
-
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.
-
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.
-
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 :)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
I think you could choke the C-More before the BRX.
-
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.
-
I think you could choke the C-More before the BRX.
And with that said, you might try adding an EA-ECOM Ethernet module to the C-more to see if that helps any.
-
Just a quick sidebar, not trying to steal the conversation. My question is C-more related and you all were talking about multiple displays to the same PLC, so here it goes:
Will the BX-SERIO allow me to connect 4 c-mores?
Can I get 2 BX-SERIO's and connect 8 c-mores?
I'm assuming yes, but wanted to ask before dropping the coin.
-
yes and yes
Just configure all 4 of the BX-SERIO ports as Do-more Protocol. This is actually the default Protocol, so just set up the proper baud rate for each port.
-
Just a quick sidebar, not trying to steal the conversation. My question is C-more related and you all were talking about multiple displays to the same PLC, so here it goes:
Will the BX-SERIO allow me to connect 4 c-mores?
Can I get 2 BX-SERIO's and connect 8 c-mores?
I'm assuming yes, but wanted to ask before dropping the coin.
Don't all but the smallest C-more's have Ethernet capabilities built in? Wouldn't a switch and cat 5 cable be an easier cheaper way to hook it all up?
-
I think you could choke the C-More before the BRX.
And with that said, you might try adding an EA-ECOM Ethernet module to the C-more to see if that helps any.
Yep, going to try that too. Stay tuned for more updates soon :)
-
Just a quick sidebar, not trying to steal the conversation. My question is C-more related and you all were talking about multiple displays to the same PLC, so here it goes:
Will the BX-SERIO allow me to connect 4 c-mores?
Can I get 2 BX-SERIO's and connect 8 c-mores?
I'm assuming yes, but wanted to ask before dropping the coin.
Don't all but the smallest C-more's have Ethernet capabilities built in? Wouldn't a switch and cat 5 cable be an easier cheaper way to hook it all up?
That was my through too. I'd think you could have a lot of C-more's talking to the BRX's Ethernet port without any real impact on the BRX.
-
Since Do-More has so much Ethernet functionality what I really want is a C-more-like App for an Iphone that doesn?t need the C-More hardware. Lots of PLC tasks don?t really need a local HMI as such. We have one in our waste treatment plants. However the operators work using the C-More app more often than the local HMI. It is really great to be up on top of a tank and be able to start a pump remotely while we watch what is happening in the tank.
-
Since Do-More has so much Ethernet functionality what I really want is a C-more-like App for an Iphone that doesn?t need the C-More hardware. Lots of PLC tasks don?t really need a local HMI as such. We have one in our waste treatment plants. However the operators work using the C-More app more often than the local HMI. It is really great to be up on top of a tank and be able to start a pump remotely while we watch what is happening in the tank.
I agree that it would be nice to have it baked into BRX, but C-More has a headless unit now ($399), so presuming they've kept the remote access capability, you could use that and not waste the space or cost on a local display.
-
The specs say that it can do remote access to the headless unit. Other options are custom, webserver and code to the modbus addresses. That's what I do. But I agree, an option built into BRX would be slick.
-
We'll get a web capability in there eventually. It'll allow you to construct basic live status pages from instructions and display to browser. Stuff just keeps getting pushed onto the stack. Working sustaining issues for the last several days. Part obsolescence is frustrating, but gotta keep stuff in production.
-
We'll get a web capability in there eventually. It'll allow you to construct basic live status pages from instructions and display to browser. Stuff just keeps getting pushed onto the stack. Working sustaining issues for the last several days. Part obsolescence is frustrating, but gotta keep stuff in production.
That's understandable, we'll just keep waiting (im)patiently. Will it be a live, no refresh needed status (at defined polling intervals)? Will we be able to access that page and use it as content in more elaborate pages generated elsewhere on the network? Will it be any element, or just sandboxed elements? Thanks for any info, just trying to decide how much programming effort to devote to a work around with current system or to sit and wait it out.
-
Will it be a live, no refresh needed status (at defined polling intervals)?
Yes.
Will we be able to access that page and use it as content in more elaborate pages generated elsewhere on the network?
Yes. Either as pages, or there is a REST API for accessing element status. Anything capable of embedding those requests will be able to pull information from the PLC.
Will it be any element, or just sandboxed elements?
Everything. Once we add true tag support, tags will also be supported via the REST API.
-
Will it be a live, no refresh needed status (at defined polling intervals)?
Yes.
Will we be able to access that page and use it as content in more elaborate pages generated elsewhere on the network?
Yes. Either as pages, or there is a REST API for accessing element status. Anything capable of embedding those requests will be able to pull information from the PLC.
Will it be any element, or just sandboxed elements?
Everything. Once we add true tag support, tags will also be supported via the REST API.
All the answers I wanted to hear. Thanks. It'll be worth the wait!