How can calculate run hour machine?

ex. i have one tag ,

 if tag001 value is more than 10 ,meaning machine is run.
   tag001 value is less than 10  , menining machine is stop

 i want to check  every day , how many hour machine run?
how can i do?

  thank you

There are a number of different way. The easiest is using the built in tag history option that can be found in the tag editor. I am not sure if its part of the core Ignition Module or part of The SQL Bridge Module. You didn’t mention the version of Ignition you’re using. This does require an Historian database being set up.

You could use a transaction group. And clever queries to extract.

You could log it on a gateway tag change event script. And clever queries to extract.

1 Like

thank you

I would opt for transaction group, that way you can have it self manage the table (ie never keep records over 1 year or 6 months…).

1 Like

normaly , hour meter should record begin start up machine.

Consider making a boolean expression tag that is true when the first tag is >= 10. Then record in your DB whenever it changes. Then you can calculate from the DB. See also:

3 Likes

i will try, thank you.

  1. create expression tag
  2. use this expression if({yourTagPath} >=10,1,0)
  3. Use the tag as the trigger in the transaction group
  4. Add any other tags you want to log along with machine status
2 Likes

Also, if you wanted to avoid interfacing directly with a database (although that is the method I would use), you could create the boolean expression tag as described above and take tag history on it. Then pull that history and use expressions/scripts to evaluate the data in the dataset that’s returned by a tag history query.

1 Like

thank you very much. ^^

thank you very much

hi sir,
3.Use the tag as the trigger in the transaction group
how to config.?


thank you

I have used this approach often. In order to ease reporting by shift, I have an additional tag change script running on my shift name tag that momentarily toggles the machine status tag value at shift change. Then, for reporting, I just filter those short duration (sub-second) status events. This makes sure that no long “running” or “down” conditions cross one or multiple shift boundaries and require more data massaging on the reporting side after the fact.

1 Like