I want to go look at a value every hour and record that value to a specific label on my screen, each hour has its on label. The reason I'm doing this is because if we have a changeover and now my SQL query is pulling a new value from the server I don't want that value to go back and rewrite over the previous hour values that I've already captured.
The expression below works as long as I'm in the 9 oclock hour but once the hour changes it goes to zero because my false return is 0.
And if your client crashes or the operator closes the window, what do you want to show when it is opened again?
Consider recording important information to the DB in gateway scope, then displaying from the DB in your UIs, so that your display is correct even when no client was open for the time periods in question.
I thought that all the information was gathered/stored on the gateway and the client just mirrored what was on the gateway. So each client is running its own SQL query to get the data?
That's true for gateway tags. SQL queries are run through the gateway, but each client is making its own request and getting its own results. (Named Queries have optional caching if the parameters are identical, but SQL is otherwise independent per client.)
Below is what my screen looks like and each hour I get the actual cases from a PLC that's counting boxes and the target comes from a SQL query that pulls the standard lbs per hour out of a table and then divides that by the case weight to give me my standard boxes per hour.
So what your saying is I need to run a gateway script every hour to pull the lbs/hour out of SQL and then store that value to a tag and use those tags to populate my target values?
No. Presuming that lbs/hr is dependent on the product running, I would store that back to the database as the snapshot of the expectation at the time, along with the actual production. If the expected value can be obtained from the DB for any time period desired (not just "now"), then I would have the timer event just store the actual production.
Then the UI runs a Named Query to retrieve the join of expected values and actual values, per hour. Arrange to have the time period fed to the NQ normalized to the hour so that named query caching will work for however many clients are displaying this information.
Ignition's tags are designed to efficiently distribute near-real-time information, using a subscription model, to many consumers--typically user interface clients, but also internal consumers. Tags are "now".
Tag history is one of those internal consumers, as are transaction groups in the SQL Bridge module. These consumers take "now" and store it (with configurable criteria/timing) as "then" in a database.
The expectation is that your UI will use query bindings to obtain information about "then", while using tag bindings to display "now". The tag historian has packaged SQL queries for its specific cases, but is still working with a DB to deliver information about "then".
While you can run queries to assemble information about "then" and place into tags to display as "now", that's an anti-pattern that really locks down your UI's flexibility. Don't do that.
