Has anyone ever setup a way to log how long a boolean is true for a set time. Then reset the counter at a specific time.
Example. Count for how long a boolean tag is true for 24hrs,log that data, reset at midnight, and repeat everyday. So one data point everyday.
I tried making a transaction group, then a querie that gets the data, then a timeseries chart that plots the data from the querie. I cant get the data to reset to 0 everyday though.
That is normally done in your PLC, using a retentive timer. The difference between a PLC's scan time and SCADA's poll time will make a difference in many applications.
The general recommendation in Ignition is to record every transition's timestamp in your database. Then it is relatively simply to query the database for the intervals, substituting start and end of day timestamps for any "on" intervals that cross those boundaries.
Some reading:
https://forum.inductiveautomation.com/search?q=duration%20calculations%20lead%20order%3Alatest
@pturmel So if i make a retentive timer in the PLC i can use that tag in an ignition querie instead of getting the data from my transaction group.
It just seems like its so close to working with a transaction group. Just if the counters in it would reset back to zero at a certain time.
No, with a retentive timer, you would write PLC logic to move the final time value into a separate tag at the end of the day, followed by the zeroing operation (in one scan in the PLC). At some short time after that (using schedule for the transaction group), you would record the separate tag to your database, using the boundary as the timestamp.
If you don't want to use a timer in the PLC, and you only have a boolean tag brought to Ignition, you should record every transition to the database. (Triggering the transaction group on change of the boolean, or using a simple tag change event script.) This latter will need followup computations with your DB's lead() function to assemble the durations per day.
Another option would be to use a retentive timer in the PLC that never resets. (You'd have it roll over like an odometer instead.) In Ignition, you'd record its value at the top of every hour, or every five minutes, or some other desired granularity. Then you can easily compute deltas from row to row at any recording granularity.
More reading:
@pturmel Ok. I'll have to go the retentive timer route. Unfortunately I have very little knowledge when it comes to scripting. (which I'm finding is a huge hinderance with ignition)
We can help with that. 
It is, even though, for performance, other features (expression bindings, especially) should be used before scripting in most cases.
@pturmel Part of me wants to figure this out with ignition. Since ive already got so much time invested with it. If you or someone else is willingI'd love to learn how.
Start by setting up a transaction group that will record your boolean every time it changes (triggered). Let it collect data for a day. We can exercise the results of that tomorrow. (I'm headed for the house now.)
@pturmel I have it already. Several days of data. Sounds good though. Thanks!
If you don't want to wait for me, I'm sure others will pitch in.
@pturmel You have some spare time to start this?
Yes, this is a good time. Let's start by getting yesterday's data. Create a named query with SQL like so:
SELECT *
FROM "my_table"
WHERE "t_stamp" >= :startts AND "t_stamp" < :endts
(Use your actual table name from your transaction group in place of my_table.)
Configure startts and endts as Value parameters with Data Type DateTime.
In a Perspective testing view, create a table that fills the view. Make view custom properties for start and end. Use the following expression binding on view.custom.end:
setTime(now(0), 7, 0, 0)
(Replace the 7 with your start hour of day shift.)
Use the following expression binding on view.custom.start:
addDays({view.custom.end}, -1)
Now your view will initialize itself to have start and end timestamps covering yesterday, startof first shift, through today, start of first shift.
On the table, on props.data, bind the testing named query, using the view custom properties to supply the parameters. Choose Dataset return format.
You table should now be filled with all of the transitions you recorded yesterday.
Click on the dataset editor icon next to the [RxC] indicator beside props.data. Use the copy to clipboard button to capture the dataset's CSV. Reply here, pasting that CSV, then selecting it all and clicking the "preformatted text" button. That will preserve the format of the CSV here on the forum.
Your parameter names and data types need fixing.
Use >= with start, < with end.
I recommend you use startts and endts or similar as your parameter names--they aren't dates, but datetime (aka timestamp) objects.
Use Select * so we can get the true column layout of your table. (Explicit column names are good for production code, but this is just testing.)
In line1 of your query you have spelled out your column names. Using * simply returns all columns in the table. I want to see that.
I suspect part of your difficulties may be due to your use of multiple columns--if those are different machines, then triggered inserts won't be efficient. Multiple columns is ideal when you use odometer-style retentive timers, with inserts that are scheduled, not triggered.
Missing a colon with startts in your query.
It's getting quite close to what you'd have if you'd copy-n-pasted my recommended SQL and replaced the table name. 
Didnt know I could do that lol....I just did it changed the name
If these are booleans, you need a transaction group for each machine, that records t_stamp and boolean value when triggered by any change of the boolean. You can use a single table if you include a third column, "machine number" or "machine ID", and include the right value as a constant in each transaction group.
If the values from the machines are retentive timer that roll over like odometers, then you can use one transaction group that records the timer values at the top of every hour. Scheduled.
Decide.
