Actually no. That was a misimpression I got when I first encountered this. You should re-read that with the edits I made later.
Sigh. I'm trying to get a "yet" inserted in that statement.
Actually no. That was a misimpression I got when I first encountered this. You should re-read that with the edits I made later.
Sigh. I'm trying to get a "yet" inserted in that statement.
It has been brought into question why they are using Edge over standard ignition and it was pointed out that this is their standard and cost efficient to them. I have no choice but to live with a single PLC and Edge. I have a better chance at marrying Victoria Beckham then them changing either of those things.
You are [expletive]ed.
It seems that way, but I do find something interesting you said in which if a member of an array is leased, yet the entire array is not then it is adding more traffic. If I was able to refine what I have as a leased tag, then I could potentially relieve some excess communication. Issue is that we are not looking at a single array, most of them are inaddressed tags examining the subroutine which is then packed full of aliased tags and AOIs so it would be extremely difficult to perform but something to examine.
If you have OPC items that are alias tags in the PLC (not alias members of AOIs), you should change the Ignition OPC Item Path to point at the actual base tag. That will give the IA driver a chance to read things in the base tag in bulk. Go back into the linked topics and study the descriptions of how a driver optimizes arrays and structures.
@Kevin.Herron. Do you think that reverting back to a different version could help. For instance, is there a difference between 8.1.31 and 8.1.38? If so, is there an easy way to change the version of the gateway or is it a fresh download?
No, there's no difference between versions that would matter here.
Going through the differences, I didn't think so either. If I do revert back to a previous version for the customer, can I use the license key multiple times or is there a quick way to revert .38 to .31.
Going backwards isn't always easy. If you made changes since the upgrade they are not guaranteed to be compatible in the older version.
I think it's easiest to take a gateway backup, uninstall, install desired version, restore.
I'm not sure what's got you thinking you need to be reverting to an old version.
Appeasing the customer. They are insisting on a change even though they have backups of my screens operating perfectly on their plant floor right now (with multiple PLCs)
Not for 7 HMIs, I'm thinking.
@JordanCClark we will chalk it up to creative differences on "standards"
I don't think changing a PLC task will make any difference in HMI comms with the L8x series of processors, as communications is now run on a separate core from the Logic, so this was most likely just coincidence. Are all 7 HMIs talking to the same number of tags, or is each gateway talking to only the tags it needs? When you mention PP, are you talking PlantPAx? If so, delete any tags out of your UDTs that you don't need on the HMI.
As others have suggested, if you can't limit each station to only the tags they need, then you'll be better off with Ignition Standard edition, so there's only a single gateway collecting the data and each PC is a client off of that main gateway. If you don't have the PLC's web page enabled, I highly suggest it, as you can go to its IP in your browser and look at your tasks page. It will show you how much communications is loaded (my guess is 100%). If switching over to a central gateway and you're still overloaded, then you'll need to look at Phil's driver to improve comms and possibly "tweaking" the AOIs to make sure all parameters/local tags are set to at least read-only.
I have the HMIs in 2 configurations. The first one was with each HMI looking at the same amount of tags which is roughly 200K. The second was that each HMI looks specifically at the operator station within line of site, which trimmed down the tags to around 90K. What I found was that regardless of the number of tags, the HMIs overload at the same position when the robots are interacting with the fixtures and running through their sequences. When I say PP, I mean part present sensors. We initially had latency issues with them which is where the leased tag group was introduced, and the issue has since compounded from there. @Kevin.Herron doubling back to the CIP connect of 7 HMIs x 12 = 94 CIP Connections, where is that 12 multiplier coming from?
Do you really need all of those tags? I have an entire gas plant I programmed and I'm only using about 41k tags for the entire plant. My bigger plants are around 90k but spread between multiple PLCs. I don't know your use-case, but it sounds to me like you have way more tags subscribed to than necessary. If you do need that number of tags, then check your UDT scan groups and make sure you're not polling tags faster than necessary.
Kevin's number came from you saying that you increased the connection count from 2 to 12.
It's whatever value you have in the "Concurrent Requests" setting. It's 2 by default.
I wish we didnt't need all of those tags, that is the absolute minimum that we can use per hmi to ensure functionality. The bulk of them come from large arrays that the tags are using as a parameter for the tag path. Ideally, we would get away from these since 70% of the array is not being used. However, that would entail changing their standard PLC program and HMI which is non-negotiable. When I first received the project I was looking at around 370K for 7 robots and 14 operator stations.
Explain in more detail, please. Maybe these shouldn't be subscribed tags at all.
Show the architecture of these arrays and describe how the HMI uses them.
This is an example of the UDT for what will be Op[1]. Then in ignition we utilize for following tag path.
Op[] is used for everything that goes into the status of the operation station as well the main sequencer. Each op station has between 4-6 sequences which jump back and forth between op[] and rbt[*] through multiple AOI based on where it is in the cycle. Initially was 1 linear op index but has been broken up into multiple for whatever reason.
Sidenote: I'm working remotely so it is not connected to the PLC time of presentation.
So I think what @pturmel is asking is how are the tags actually used. Like do these values change constantly? Are any of them just settings that only get changed by an operator while he's adjusting things? Is anything historized? What speed are all your different scan groups and what's direct/leased? Any settings changes that are HMI driven can be on slower scan groups and set to leased with a rate of 0ms and a slow rate (like 2000-5000ms) for the leased rate (and hopefully they're all grouped together in a UDT for optimization). Any alarm or historized values should be set to direct with the desired rate you want alarms or history to be collected, or if it's something being historized or alarmed that only needs to be collected every 5 seconds, but when displayed on the screen you want it to update at a 1 second rate, then set the scan group to 5000ms with a 1000ms leased rate.
Your/their UDT is fairly large at 5,420 bytes per UDT (how many instances of this are there?)
I feel like your Ignition parameters could be simplified also by having and OpId tag or something that is an integer that gets used by all the other item paths on tags rather than manually specifying all of those unique parameter values, but maybe it's because Op10 is linking to arrayIndex 1, but even then you could use 2 parameters instead of a dozen or more.