Zeroing variable daily - not midnight

Actually a bunch of questions, I’m new to Ignition, and even my PLC skills sometimes are a little rusty, but a new job has me trying to come up to speed fast. We’re doing a little in Perspective, but my questions, for now, are all in Vision; predecessors to me created a some highly developed windows over the last 10 years. MySQL on the database side. There is still one person in our department who’s very good with automation, but had done less with Ignition tasks that needed scripts or advanced Ignition topics. I’ll start with the question in the title, and may need to start separate threads for the places it branches.

I’m bringing in a raw number from a counter, and doing a little math to make it a daily count. We want to reset the variable for a numeric Label/Text Field daily; maybe 2:00 or 4:00am. A similar counter looks like it was doing the math in the PLC, while Ignition had several additional tags for prior days & handling zeroing. The counter in question here doesn’t need to come through a PLC

Is there a preferred way to do this? Is it best in a script, expression, or a tag script? What is the best way to fire it? Just thinking a couple years down the road, I don’t want things unnecessarily firing every second if it’s an excess load on the software or database.

Thank you!

Welcome!

So how does this field get its variable?

But usually things like that are best run in a gateway script, because else it might trigger multiple times or not at all depending how many clients are open!

1 Like

If you’re on Ignition 8.1.6 or later, check out scheduled scripts.

3 Likes

If you are not in 8.1.6, I think the common accepted way to do this is to create an expression tag of boolean type that is True at the time you want to run your script, and then make a Gateway Event → Tag Change Script and put the logic you want to do there (or preferably in a function but call it there).

1 Like

Thanks all! Version 8.0.15.

The counter is from a value on a tag. That too begs the question of what should fire the script, or expression if the better approach. On a test screen, I had success writing the count script on a Numeric Text Field with the raw data from the tag, and firing it from property change. The output then on a separate field. That seemed to make sense for counting, but that method seems like would be constantly firing if I was bringing in time.

I’ll have to look; somebody probably already created a similar expression on it in the past.

If you’re pre-8.1.6 and have the report module installed, you can also setup a scheduled report that doesn’t actually report anything and just calls a script as it’s action.

3 Likes

I couldn’t find a previously created hour tag (and a minute tag for testing purposes), so I created that as an integer.

The boolean expression sounds like a clean way to do it! For some reason though I find scripting to objects easier than tags yet. With a Numeric Field binding its value from the hour Tag, I have a Property Change script on that with an if statement to check the hour; then 0ing the appropriate values. For testing purposes I have it at 0 minute, instead of an hour. It looks like it is working well. Aside from the invisible field to clutter things later, is there anything wrong with this approach?

Thanks!

binding a timebased function that only is supposed to run once on a component/numeric field binding is not good. It would trigger multiple times if multiple poeple are online on that page or (maybe worse) not at all if noone is running the client on that page. You should do this on the gateway/tags

1 Like

Another option is to eliminate the need for resetting. See this post:

1 Like

I should have read that better the first time you wrote it! The script was fine against multiple triggers, but worthless for missed triggers.

Thank you!

The script I referenced will work for missed ‘triggers’ as you are just looking at a counter value. You could miss 100 or more and it will pick that up.

Over a month later, I realized I didn’t reply here. I was referring to my earlier script not working, not the one you referenced.

Still it’s been so reliable since I re-wrote it onto tags, that I hadn’t tried any other ways. I sure appreciate the option though; I might need it next time.