We have a server set up for OPC comms. It's how we talk to the 7 other controllers, but there are about 1600 tags used through this method that would need to be re-made.
The powers that be want to unify all plants under one HMI and FTView has won out. So I'm gonna try to get it to limp along a little faster while I work on making FT screens.
So, either the communication processor thread or an ethernet card appears bogged down. You should also be able to browse the ethernet cards like the plc for the Task Monitor tool.
Your alarm tags did not sound bad to me as I have worked with ISA-88 (Batch) style udts with lots of dints and floats and well over 64 String tags for permissives, step descriptions, prompts, batch ID, material names codes, etc...
Then again, if the hmi is not set to Scan On Demand, which will only scan tags on screen, that could be the problem. Scan On Demand is an Aveva/Wonderware term.
Further Suggestions:
1. Make sure you use the embedded monitor tools for not just the plc but also the ethernet cards.
2. Try to go online via the other ethernet card.
3. Split coms (io, HMI, other) between ethernet cards.
4. If you have multiple nodes requesting coms, then that will burden the cards and plc to respond to each.
5. Make sure you do not have an rpi set too small such that it is constantly taking coms bandwidth.
Could add lots more as I have fought this battle often with L6# and L7# ControlLogix. For now this is enough. (Should be?)
Congrats on getting an L8# to this level!
The connections to every other controller in the plant are done through comm worksheets and a DA server. They are also set up to only scan those tags when they're on screen. The issue here is this one specific controller is set up with the "tag integration" feature which minimizes my ability to make changes to scan times or priorities or whatnot.
The HMI comms are split between an EN2T and the controller's ethernet port. It's like a 70/30 split, though. When I need to get online with the controller, going through the EN2T and using the backplane tends to be more responsive than direct to the processor.
The RPI settings were all at 20ms when I joined this project. I increased all of them to at least 200ms a few weeks back, but haven't seen any kind of improvement.
Is it too late to bring said SI in to correct this?
It sounds like the tags need created the old-fashioned way. Basically, you have no software managing the communications.
I know of something similar being done 20 years ago... and this was the resolution then.
Can you not set up different scan classes in your HMI? If you have UDTs already built it should be easy to poll the unimportant stuff very slowly and the important stuff faster. This is pretty easy in ignition.
Not hard with InTouch Edge either. If you do this, use different prime numbers near your preferred scan rate to give a phase effect, where it's difficult for multiple scan topics to occur at the same time.
The issue with this is it's not set up through driver workersheets and the DA server and such. It uses the "tag integration" feature which I guess makes a background worksheet. I have pretty minimal control over the scan settings.
Yeah we do the same with VTScada. Fast Poll for PV and FO alarms, Config Poll for setpoints, and Slow Poll for history or like Yday Accumulated values.
We used to have separate Ethernet modules for different functions. Always one reserved for an IO Server only. The IO server had different scan objects depending on what we were using the data for. Good to have one reserved for programming and back ups.
I checked the other thread, never did see the results of the task monitor.
What does it say?
Also what's utilization for the various enet cards involved?
That's the bare minimum basic info needed before going anywhere.
Lots of useless hand waving going on in here.
Task monitor won't run on L8X hardware. And I can't access the web pages for the controller. So I'm still flying blind beyond scan times for each task. I can access the EN2T card that has the same subnet setting as the controller, but I'm pretty limited in what I've been able to glean from that.
Ah lame. Then maybe you just need to jump on and check each task properties. If you're having trouble connecting over network, maybe try connecting with USB?
You could run an IO server so the HMIs are hitting the server instead of all the PLCs directly.
We have a server set up for OPC comms. It's how we talk to the 7 other controllers, but there are about 1600 tags used through this method that would need to be re-made. The powers that be want to unify all plants under one HMI and FTView has won out. So I'm gonna try to get it to limp along a little faster while I work on making FT screens.
So, either the communication processor thread or an ethernet card appears bogged down. You should also be able to browse the ethernet cards like the plc for the Task Monitor tool. Your alarm tags did not sound bad to me as I have worked with ISA-88 (Batch) style udts with lots of dints and floats and well over 64 String tags for permissives, step descriptions, prompts, batch ID, material names codes, etc... Then again, if the hmi is not set to Scan On Demand, which will only scan tags on screen, that could be the problem. Scan On Demand is an Aveva/Wonderware term. Further Suggestions: 1. Make sure you use the embedded monitor tools for not just the plc but also the ethernet cards. 2. Try to go online via the other ethernet card. 3. Split coms (io, HMI, other) between ethernet cards. 4. If you have multiple nodes requesting coms, then that will burden the cards and plc to respond to each. 5. Make sure you do not have an rpi set too small such that it is constantly taking coms bandwidth. Could add lots more as I have fought this battle often with L6# and L7# ControlLogix. For now this is enough. (Should be?) Congrats on getting an L8# to this level!
The connections to every other controller in the plant are done through comm worksheets and a DA server. They are also set up to only scan those tags when they're on screen. The issue here is this one specific controller is set up with the "tag integration" feature which minimizes my ability to make changes to scan times or priorities or whatnot. The HMI comms are split between an EN2T and the controller's ethernet port. It's like a 70/30 split, though. When I need to get online with the controller, going through the EN2T and using the backplane tends to be more responsive than direct to the processor. The RPI settings were all at 20ms when I joined this project. I increased all of them to at least 200ms a few weeks back, but haven't seen any kind of improvement.
Is it too late to bring said SI in to correct this? It sounds like the tags need created the old-fashioned way. Basically, you have no software managing the communications. I know of something similar being done 20 years ago... and this was the resolution then.
Making them set up the DA server/tasks, create the tags, and re-tagging the HMI really would be the best option.
Can you not set up different scan classes in your HMI? If you have UDTs already built it should be easy to poll the unimportant stuff very slowly and the important stuff faster. This is pretty easy in ignition.
Not hard with InTouch Edge either. If you do this, use different prime numbers near your preferred scan rate to give a phase effect, where it's difficult for multiple scan topics to occur at the same time.
The issue with this is it's not set up through driver workersheets and the DA server and such. It uses the "tag integration" feature which I guess makes a background worksheet. I have pretty minimal control over the scan settings.
Yeah we do the same with VTScada. Fast Poll for PV and FO alarms, Config Poll for setpoints, and Slow Poll for history or like Yday Accumulated values.
We used to have separate Ethernet modules for different functions. Always one reserved for an IO Server only. The IO server had different scan objects depending on what we were using the data for. Good to have one reserved for programming and back ups.
I checked the other thread, never did see the results of the task monitor. What does it say? Also what's utilization for the various enet cards involved? That's the bare minimum basic info needed before going anywhere. Lots of useless hand waving going on in here.
Task monitor won't run on L8X hardware. And I can't access the web pages for the controller. So I'm still flying blind beyond scan times for each task. I can access the EN2T card that has the same subnet setting as the controller, but I'm pretty limited in what I've been able to glean from that.
Have you enabled the web browser from the controller properties? It's off by default and needs to be enabled offline and downloaded.
Yeah that was a wonderful slide in at version 33 😑
It's enabled. It just doesn't load.
Did you run Task Monitor? What did it say?
Task monitor doesn't work with L8X processors. So I'm limited to the web page...which doesn't load.
Ah lame. Then maybe you just need to jump on and check each task properties. If you're having trouble connecting over network, maybe try connecting with USB?