I am having issues in the same area. I am doing a major change to our code base and want to use more triggered history files, so this is important to me,
I want to record conditions when specific events are detected. I was told triggers only act when the condition goes from false to true, so only on the “rising edge”. However, I get multiple stores of the data when I do the following example.
I use nGaugeSlow as the Trigger. I check it every 500 ms, Configuration: Discrete on.
Variables I need defined and collected every 1 s (history driven, can be changed to 500 ms if required.)
I set up a test to see the condition is true and change my nGaugeSlow from 0 to 1. This should result in a trigger event and a store.
The loop I am watching takes an average of 400 ms, so if the trigger is > 1, but < 3, I increment it. If > 2, I reset to 0. This holds nGaugeSlow true for an average of 1.2 seconds and then reset. This ensures the 500ms Group in PAC Display will see nGaugeSlow true before I reset it. (Wish list: Have an option for PAC Display to reset nGaugeSlow after detected!)
However, I get 2 or 3 records for each event. As a test, I used the same timing and did nor increment nGaugeSlow for the 3 cycles, but left it at 1. I got 1 entry for each trigger. It appears any non-zero change to nGaugeSlow triggers another store.
While I can add code and variables everywhere (Lots of places…) to implement a workaround, it would be best to have the code trigger only on the rising edge, as I was told it did…