I’ve been tasked to set up a reporting system on chocolate liquor pumped from 4 separate areas of our plant for OEE data. I’ve had to build totalizators in each PLC. At 11pm the transaction group executes and writes the amount pumped to a database. I then have to send a signal to each PLC to reset the totalizator. What I’ve had to do is set up 4 separate transaction group and use the “handshake” feature in the Trigger tab to send the reset signal. I really wanted to put all 4 areas in the same group but I could never get the scripting in the expression tags to work right. According to the instructional videos the expression item executes when the group does-however I found to make the tags work at all I had to wrap them in a conditional “if” statement. Stacking 3 “if” statements doesn’t work within the group. I’m wondering if this is even possible within one transaction group.
If the lines are running at 11pm, this approach will always lose some data. Consider using totalizers that never reset, but simply roll over in 32bits. Then use a “snapshot” register to hold the most recent 11pm value. Have the PLC subtract live from snapshot every scan to yield the subtotal of the day. Read and record all of your raw totalizers at any desired interval (I would do it much more often than daily). Use another transaction group (or a script) to write the last recorded raw totals to the snapshot registers after the 11pm recording is complete.
No data loss even if a transaction is delayed (just accounts some production to the wrong period). Any time period’s production is the raw value at the end minus the raw value at the start (with rollover arithmetic).
Interesting, there is a possibility that at 11pm one of the lines will be pumping, and the resetting option may cause data loss. Really for the amount of chocolate liquor that gets pumped daily, a small loss at 11pm may not matter much…however I do like your idea as being a “cleaner” solution. I was worried about what would happen when the register “reset”…then I did the math…the value of a signed 32 bit register divided by a “high” daily total (150,000) would take nearly 40 years to roll over. I’ll be dead then. Thanks I’m gonna look into this solution
If 32-bits isn’t enough, and/or fractional values are needed, I sometimes build totalizer code with a 32-bit integer paired with a floating point register. In lieu of a 64-bit float. :-/ Whenever the float is >= 1.0, you take it’s whole part and add it to the integer register and leave the fraction in the float. This has been extremely valuable in regulatory situations, like wastewater or dangerous liquids, where the government wants a traceable value over long time periods without giving up low-flow precision. And its easy to convert and store as an actual 64-bit float on the SCADA side.
That sounds like a better design.... store the whole number part as a DINT and never* have to worry about rollovers. Of course I'm not a PLC guy so I don't know how much of a pain this is to implement on that side
Any time period’s production is the raw value at the end minus the raw value at the start (with rollover arithmetic).
I've read your other posts on totalizing and haven't been able to make my brain make sense of this yet. Could you go into more detail on the rollover arithmetic?
Using OP's example, capturing data at 24h intervals at 11pm, if the totalizer rolled over at 6pm how do we get the full 24h and not just 6pm-11pm?
32-bit integers in PLCs don’t roll over to zero. They “roll over” from 0x7fffffff to 0x80000000, maximum positive to maximum negative. If you do the math in a 32-bit register, subtracting that older positive number from the newer negative number gives the proper delta, ignoring the math overflow indication. If you have to do the math in a larger datatype, you can add 0x100000000 and then take modulo 0x100000000. Kinda’ like subtracting 11pm from 2am yields 3 hours, ignoring the midnight clock rollover. Just that in 2’s complement math, you don’t have to jump through hoops to adjust for the rollover.