Test Machine slow.... Looking for a reason

I'm still in the testing phase of ignition, and wondering if we should do this software or something like a panelview straight from rockwell.

Now that the project is getting close to being done, I'm getting pretty severe delays pulling tags, as well as slow response from the test controller.

For the record, the controller now is a L36ERM. The one that will be installed is a L38ERM or a 1756-L83E.

I got my head wrapped around the tags, and most of my tags are currenty leased at a 250ms/10000ms rate. I don't have ignition doing any real "work", just more of a display HMI and a way to shuttle tags and inputs back and forth. It's not conducting any logic.

I'm at about 20000 tags currently, and this number will likely grow a bit more. It is on the high side, mainly due to the way that I'm processing mixers. I'd like to have a display of all the raw materials in each mixer, the target/actual loaded quantity, the current status (Loading, Waiting, Running, PulseFail/etc), as well as a bit more information stuff. Besides that, I need things like agitator status, batch size, current weight, etc... I do only display one mixer like this at a time, and use indirect tags to switch back and forth. 25 lines * 20 mixers * 6 or 7 items adds up fast, not to mention the background info that I have on a longer cycle that pull (such as valve status, pump status, etc... about 250-500 per each)

Whether I have 1 or 8 requests, my "fast" rate of 250ms is overloaded. Queue time is over a second. My rung cycle times in Studio show as I expect, in the -us and ms range based on task.

Also, when ignition is online, my copy of studio slows to an absolute crawl when connected.

Any clue as to why? I can thing of a few things - keeping in mind that I have everything running off of one laptop now for development. Bit of a shoestring budget until I can prove that this works.

  1. Simply too many tags for the network. I have a 10/100 USBC to Ethernet cable hooked directly to the PLC. Is there too much traffic back-and-forth, and I'm actually overloading my network?
  2. Too many tags for my PC to handle the processing of. It's not a bad PC, but a few years old by now. Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz 1.99 GHz, 16GB of ram
  3. Too many tags for the processor. I don't think so, because even when running slowly I can see the scan times are as expected.

Thoughts? Will my problems disappear if I have an actual server running the gateway? Or do I need to go back to the drawing board on some aspect of things...

Did you drag all of your tags from the PLC into Ignition? If so, you screwed up. Only make tags in Ignition for the tasks you need Ignition to perform.

Meanwhile, some reading for you:

Read all of the linked topics, too.

In particular, look at the Msg Class 3 stats in your PLC's diagnostic web page. If you've maxed that out, your problem is too many tags for your PLC, or too many too quickly for your PLC.

FWIW, 250ms scan classes are unusual in SCADA applications.

1 Like

Will do.

For the record, no.. did not add all tags - just as I had a home for them in ignition. But, they grow fast. I do have “extra” programmed in though, I could likely save some by removing. For example, I have 20 mixers. While I only display one at a time in full, the full amount of info is billed following for each mixer…

(25 ea) priority no, rm number, rm name, target qty, actual qty, status
Plus about 25 more per mixer for me info.. t,p,weight,etc

Lots of information items
Valve status(x1500)
Pumps (250)
Meters (250)
Names for the above
Settings for the above (meter factors, pulse fail timers, etc)
Rm names (150), wt per gallon, assay for each

I’ll check the links and give it a shot… was wondering if the simple fact I’m running the gateway and logix and etc on the same machine is a recipe for trouble, or if the issues would persist after upgrading the controller and using a proper server

There is also a significant difference between the L3X and an L83E. The L8X will have an over all much better response for SCADA tags solely based on the fact that there is a dedicated processor for communications on board. The L3X doesn't.

Of specific notes in the links... use UDTs for your SCADA comms, and if you can don't read/write tags in AOIs.

Also, check your CIP connection size.

2 Likes