Counting uptime techniques

I don't know if it is a lingering concern from an old bug that people are concerned about.

I think you didn't read the post before the dashed line.

That tag is being historized, and I tried to explain my question was more implementation side less historian side.

From experience, it can, if you are using CIP motion, and the servos are in motion at the time.

1 Like

Indeed. Which is why everyone who can should be using a technology that eliminates the need to ever have to set the PLC time.

4 Likes

To iterate, that is if there is a large swing in time difference. Using a good time source is very important.

EDIT: Phil's point exactly.

2 Likes

What exactly do you need help on for implementation?

1 Like

Thanks guys
I passed that along, but it would have to wait for a shutdown period to implement.

For now for me to get correct shift uptimes, I think then it comes down to:

Option 1
Script sets the uptime tag to 0 at shift start.
Running boolean tag on-change script to adds time to the uptime for running time from tags.
Script toggles the boolean at -2 to shift end to insure I get the time.
I collect data at -1 minutes to shift end.

or

Option 2
Script sets the uptime tag to 0 at shift start.
Running boolean tag on-change script to query durationOn for time of the shift
Script toggles the boolean at -2 to shift end to insure I get the time.
I collect data at -1 minutes to shift end.

I think I will go with option 1 to avoid an additional database read.

Implementation
Or did I not understand the intended implementation of the tag history?
This is the part I was not sure of I think.
From a script that writes all the uptimes, or from the boolean tag on change script for example.
Seems like there should be a historian query tag type, or that might be a small performance tax.

Use the SQL Bridge module. Hour and Event Meters - Ignition User Manual 8.0 - Ignition Documentation

1 Like

Thanks
I think that works well with groups that are run every second.
I am getting my reports at the end of the shifts.

I think both these options are overkill. I am with @dkhayes117 on this with his post on Jan 25. If you have some kind of state tag being historized (1=ON,0=OFF) and only need the uptime report on a historical time frame (vs real time which your method may be better for) then I would use the script he presented. The only change needed to that script is to wrap the aggregationMode in [brackets].

1 Like

@DNice Are you describing this:

Option 2
Script sets the uptime tag to 0 at shift start.
Running boolean tag on-change script to query durationOn for time of the shift
Script toggles the boolean at -2 to shift end to insure I get the time.
I collect data at -1 minutes to shift end.

Or what is the implementation you are describing?

My concerns:
Triggering the script once at the end of the shift
Capturing specifically the shift data only including over the midnight shift
Excluding time outside of the shift
Having a 0 at the shift start for my trending of the historized tag

@zacharyw.larson,

Really depends on what you want. If you want the uptime seconds between 2 timestamps (shift start/end), the historian query is how I would approach this.
If you want a continuous uptime seconds tag then you could go with the options you mentioned or alternatively use a event/hour meter that keeps the uptime counts for you. You can set up a single ShiftEnd tag that can reset all the counter tags for ea machine.

1 Like

The beauty about using tag historian is you don't need to worry about resetting or rollovers. If you simply want to do a shift counter, do it in the PLC.

1 Like

I am doing this Option 1 right now.

Hour meter doesn't work for this, I am not running the transaction every second.

I don't have accurate clocks in the PLCs. I can't fix that, it is not in my control.

Historian query doesn't work so far, unless someone can explain an implementation that overcomes the concerns.
My concerns:
Triggering the script once at the end of the shift
Capturing specifically the shift data only including over the midnight shift
Excluding time outside of the shift
Having a 0 at the shift start for my trending of the historized tag

I am just going with Option 1.

I can't spend more time on it.

Option 1
Script sets the uptime tag to 0 at shift start.
Running boolean tag on-change script to adds time to the uptime for running time from tags.
Script toggles the boolean at -2 minutes to shift end to insure I get the time.
I collect data from the tag at -1 minutes to shift end in a transaction group that runs at that time.

@DNice thanks for the message.
I should have clarified this pertinent detail of my requirements:

Resetting the uptime tag to 0 at shift start creates sawtooth appearance for historical inspection.
Makes visual inspection easier.

1 Like