Scan Classes not working

Having a rather strange one that is a bit of concern as we beef up our data collection… The site I’m on has recently upgraded from 7.9.1 to 7.9.12 and it seems scan classes are now no longer having any effect. They simply stay “fast”. Even if I knock a tag’s scan class down to 10 seconds, the value will keep changing every second or less and execute their respective scripts in the same manner.

Has anybody experienced this issue??

Any help much appreciated!


Unfortunately I entered the same situation today. Was told that my 7.9.9 would migrate to 7.9.12 without issue. On top of hoping there is a search and replace for anti-aliasing (all my text looks like crap), now I see that large data displays I commissioned long ago are ‘dancing’ and hard on the eyes. Now I wonder if I have to revisit 21,000 tags to re-implement scan classes. They all update below 1 second and I have 20 different scan classes.

Hopefully tech support has some answers.

Worked with Tech Support today. They have confirmed this is a bug that appears above 7.9.9 when using Legacy v20 Logix Driver and PLC5 drivers. All tags being read from those PLCs using those drivers will scan at the rate of the fastest subscription hitting the PLC. A 30 second tag, a 10 second tag and a 250 ms tag will all scan at 250 ms. The Ignition Gateway will show proof that it IS adhering to scan classes and yet your tags are changing at 250 ms. So I’ve got to figure out how to re-organize my tags. Haven’t yet arrived at my final solution. This is still an issue moving into v8.0.x also.

It actually depends on the implementation of request optimization in the driver, but yes, that’s generally what will end up happening.

I’m looking into fixing this behavior hopefully in time for 7.9.13.

And FWIW, the drivers have acted like this forever, as in since 7.0.0. But a recent change to the way the OPC client makes subscriptions is allowing the faster-than-asked-for values to make there way to the client now, whereas previously even though the drivers were polling some tags faster than asked, the UA client never received the values too quickly.

edit: by fixing I mean tweaking the driver optimization, not reverting the OPC client subscription changes

1 Like

Hi @Kevin , do you know which version this starts happening? We have a scheduled down day where we plan to downgrade to 7.9.11 in order to fix this. @Jdubbbb mentions above that he was told it happens with anything after .9. The simulations I did with 11 didn’t show the same behaviour. Any clarity you can add before we go ahead and do this?

I would have thought it began with 7.9.12.

Like I said, the drivers have always been polling some tags too fast in some cases, but the change that caused these tags being polled too fast to have their values arrive at the client too quickly probably started with 7.9.12.

Cheers, we will continue with .11.

Yeah it’s not the polling of the devices that’s getting me - it’s the tag execution scripts. Going gangbusters every 250ms.

Sure, but only for OPC tags and only if they’re actually changing that fast, right?

That’s right. We’re doing a large data collection project at the moment, and most (nearly all) values do change at that frequency or faster. It just means our timeseries db is getting hammered far more often than it needs to.

@keiran.stokes, my jump from 7.9.9 to 7.9.12 did require all client side shortcuts to be recommissioned. Will 7.9.11 work with client side configured for 7.9.12? I might opt to duplicate your effort.

@Jdubbbb Yeah should be fine, I think the client launch change (embedded java) was from 7.9.10.

@Kevin.Herron @keiran.stokes

TL;DR - I hope your rollback goes well.

I also did testing for the rollback. Tests show I will need to full uninstall 7.9.12 and install 7.9.11 and then restore from a gateway backup from 7.9.9. The 7.9.12 is when Gateway OPC Connection - Type went from ‘OPC-UA’ to ‘OpcUaNextServerType’. Once 7.9.11 is installed, attempting import of a 7.9.12 project will have a parsing error, that could be common knowledge to everyone.

This rollback testing is still not successful. The last test I performed was to see if I had to redo all client side short cuts after a rollback. The answer was YES I do have to redo all client side shortcuts but I got into a situation where server side and client side were all rolled back to version 7.9.11 with clean install and redownloaded client projects. The Clients were up, scan classes were now partially synced, by that I mean that a 250ms scan, a 1 second scan, and a 10 second scan, were following a 250ms, 1sec, and 5 sec scan rate. Odd yes, but I could not get that 10 second, whether I changed it to 20 or 30 to do anything but 5 seconds. Regardless, the Active Designer changes I tried to make before or after a reboot would not push out to clients. The clients still showed live but old designs. They splash the updating project, updating cache popups, but come back as an older design that shows live values changing at 250ms, 1sec, and 5 sec.

I am still testing. * A full clean out of C:\Program Files\Inductive Automation\Ignition\data\jar-cache did not fix.

Maybe I’ll see if I can get all the the way back to 7.9.9, or go to 8.0.5 now.

I’m trying to get a fix for this into 7.9.13 and 8.0.6.

1 Like

Ok. Thank you @Kevin.Herron.

Hey Kevin… Did this fix make it into 7.9.13?