Reset Hour Meter when source value of tag where reset trigger is configured is N/A (PLC offline - tag quality bad)

This a continuation of Scheduled Script not working sometimes . Basically, I am logging uptime of our machines based on a bit being read from the PLC of each machine. We then log the runtime of each machine into our EAM system. If the machine is offline, the reset trigger fails. Our concern is if that reset bit fails, we do not want to rerecord old runtime values.

One potential solution we though of was to compare the timestamp value of the runtime hours tag to current date and only log if daysBetween == 0. An issue with this is that if the machine goes online later in the day, we would be adding on to a runtime value from an older date (as it missed the reset trigger).

Another potential solution was to create an expression tag to evaluate the quality of the bit we are reading from the PLC. Something like: If(runtime.quality = "Good", runtime.value, 0) and use this expression tag to start/stop our runtime hour meter. This should fix the issue of not resetting if offline as we are providing a fallback value. The problem with this is that the expression does not seem to be functioning properly. I can provide more details on this if this approach seems to be the best way to fix our problem.

A third solution we considered was to make some tag change scripts tied to the PLC bits. If quality changes (specifically goes from bad to good.. or machine is backonline), compare the datestamp of the hour meter to the current date and if daysBetween != 0, then reset the bit. Only issue with this is that we'd have to break up our reset trigger from one common bit to an individual reset trigger for each machine which is not exactly ideal.

We do not want to handle this hourmeter odometer style because we want to display the daily values elsewhere. I learned from the former post that that method is preffered, but we would like to refrain from handling it in that manner if possible

Please advise if any of these potential solutions are feasible and the best way for us to proceed.

Odometer-style does not preclude displaying daily values elsewhere. For best results, the PLC should have the following:

  • An odometer tag for the quantity being counted/totalized.

  • A snapshot tag for day/shift/hour/whatever to be the baseline for display

  • A timestamp tag for day/shift/hour/whatever to hold the boundary of next snapshot. When now >= timestamp, set timestamp to next boundary (skipping multiple intervals if the machine was off) and copy odometer to snapshot.

  • A display tag for day/shift/hour/whatever computed continually as odometer - snapshot.

And then Ignition would have the following:

  • Tags for the various display values, and

  • A tag change event for the most granular timestamp that records the new snapshot with the new (future) timestamp.

  • Use lag() in SQL to get odometer boundaries exactly on timestamps.