Fixed my slow computer, but still having slow updates... Help a newbie out?

Ignition
1

So, I fixed my issue I had with a super-slow Logix5000 and ignition response - I had my CIP number of connections too high. While my system is now snappy in Studio5000, I am still getting less-than-expected response times from the HMI.

Yes, I am aware that I have a crapload of tags. It's not likely going down. I also don't yet have a "proper" server for the gateway, and have everything running off my laptop - Designer, the gateway, logix, as well as a SQL interface.

I have a variable that I'd like to pay a particularly close eye on. In running program, it updates about 10x per second. In Studio5000, I track it via a counter (when it updates, the counter goes up one), as well as I can just watch it visually on the screen. The counter says that it's not missing an update, ever. I can see logix update as well... it misses a few reads, but I generally can see it update about 3-5x per second. In ignition, I can see it update about once per second.

Is there any reasonable way to get that number up? Once again, I'm not sure if it's an issue with my setup, or just the fact that I'm running on a test bench for now.

Here are a few screens of possible importance... I have about 25 items in the "50ms" class for now. All DINT's in the same host array. I am not running a continuous task, although this routine is set to run every 3ms or so. I don't expect to run them at 50ms forever, but just want a proof of concept for me.

Is there a different setting I should look for?

Thanks for listening to a newbie have questions.... (And, for the record... No. I did not drag the entire controller over. We just have alot of mixers running through this system, and alot of info back and forth. I tried to set scan classes appropriately for the info)

I'd like to add... actual response from the PLC is good. I have a few push/hold buttons, and they all light up the outputs as expected, and instant. Just the communication back or display seem to be lagging.

Diagnostic :

image
image1204×962 48.9 KB

Tag Group: I tried lowering the history to match the 50ms, but it had no change as well. I am not running historian on this system.

image
image854×643 44.5 KB

Routine:
image

Task
image

CIP stats from the controller webpage. I'm not too familiar with this info, but could the RPI and API being 1001ms be the source of my frustration? Any clue how to modify that? Or is it a 1769-L36 limitation.

image
image1458×239 17.6 KB

2

In the project properties, the default client poll rate is 250ms. Speed this up to get Vision to poll faster.

3

No, RPI and API aren't meaningful for messaging connections other than for certain retransmission situations.

If you do some arithmetic on your mean response times for the different poll rates, spread over the concurrent connections you've configured, you will find that you need about 60% of any 10-second period just for the PLC responses. There's some more overhead on the Ignition side, but you aren't overloaded.

If you put a valueChange event on one of the fast-changing tags in the 50ms group, and have it push database inserts through the S&F system, you should find about 20 new records per second in your database.

4

Already tried that one. Made no difference.

According to the variables in ladder logic, my test variable should be increasing at about 40lbs/second. This is tied to about 5 updates per second in rockwell. The HMI is updating at 120-140 lbs per shot, so about once every 2-3 seconds.

Like I said, I don't really expect (or need) to see 25-50ms updates... but just trying to prove to myself that "if it works at that speed, it should work where I actually need it". Also like I said, the other direction is instant... I click a button in ignition, I see the output light up nearly instantly.

Just hitting my head against a wall.. I'm trying to upgrade us from an old, not-supported windows XP/32 bit softPLC due to hardware availability... but even with that many tags on those old computers, the fact that the logic was housed in the HMI made everything react in an instant... It makes it feel like the graphics here are flashier, but the actual experience is a bit sluggish.

5

If you're trying to gauge the update speed by just watching the tag value change in the Designer or a Vision screen then the default project update rate of 250ms is going to mean you definitely won't see it any faster than that.

This doesn't mean the Gateway isn't receiving updates faster, just that comms between Client/Designer and Gateway is limited to 250ms.

2 Likes
6

Understood.

My rate in that screen I have tried from 25 to 250 to 1000.

My tags in Studio5000 I see change about every 300/400ms. (I have a counter going at 5 ticks per second, and it skips every 2 or 3 numbers by 1).

No matter the rate, the view in the HMI only changes every 3-4 seconds. Checked with a stopwatch. Any other suggested places to look? My memory also says its running 1.5GB/2GB, but only 1% CPU.

Polling Base Rate - Default was 5000, tried down to 250

image
image632×574 29.6 KB

Tag settings. Default was 1000, tried down to 25

image
image713×572 44.7 KB

Specific tag setting for this one

image
image866×853 62.3 KB

If I look at diagnostics, though.. and spam refresh. I do see this updating only every 3-4 seconds.

image
image1138×273 20 KB

7

What's the Rate of the "Actual_Batching" Tag Group?

8

Note that the Polling Base Rate is for Query bindings, and applies only to query bindings that are set to poll.

The poll rate for delivering tag values to a Vision client is in your Project/General settings for "Client Poll Rate". That is the fastest that tag updates will be delivered to a Vision Client, or a designer's component bindings in Preview.

The designer's tag browser is even lower priority. Don't base anything on what you see in the tag browser.

Consider setting the Client Poll Rate to 100ms. (That satisfies most people's perception of "fast".)

9

As above... but I backed it off a bit from 50ms for more troubleshooting. 250ms leased/driven with a 50s fallback.

image
image613×556 36.6 KB

10

I don't think looking at it in the Tag Browser will actually lease the tag. It might be better to test this with a fast direct group just as a baseline...

It might also be worth adding a tag change script to one of the tags you expect to be updating quickly where you just print something to the logs.

11

Perhaps you should temporarily disable all of your tags. Then:

  • Use a GSV to pull the controller's micro-second resolution wallclock time into a pair of DINTs. Run this in a periodic task that executes ~ every 10ms. This ensures every poll from Ignition actually has a new value.

  • Subscribe to the low-order DINT at some fixed rate. 50ms, perhaps.

  • Use a valueChange event script to write to a test DB (via S&F) for every new value.

  • Create a window in Vision that has a tag binding to this in a numeric label. Use a property change event to monitor new values of that binding and print system.date.now() to your diagnostic console.

  • See how many database entries you are getting per second, and how consistently, and how quickly you are getting Vision diagnostic timestamps, and how consistently.

  • Then start manipulating settings and re-enabling some tags to see what you really are getting.

The tag browser is simply not designed to monitor fast-changing values.

(And what's with the non-leased rate of 51035ms? Using different paces will absolutely scramble the driver's ability to optimize requests.)

12

When you make changes to the project settings, make sure you are clicking save after pressing OK. Just pressing OK doesn't actually apply those settings until you do a save.

As others state, the Timing settings aren't for tag updates to the screen, and the General/Tag Settings is where you need to speed things up.

Temporarily set a tag to a direct fixed speed and watch it as just doing leased won't cause it to speed up until it's displayed on a screen.