Trigger is set, then a timer is started for 10sec. If PAC Display supplies notification that the recipe has been uploaded it will proceed, alternatively if display does not respond it will timeout and move on. Application being a production line that needs to continue un-interupted
There are no loops back to the trigger, trigger is set to (1) and after the conditions are met as above it is set to (0) and next batching cycle continues. Estimated time per batch around 2minutes
I will expand on some additional problems I am experiencing on this application later, surrounding the triggers in PAC Display for uploading the recipe and the application for storing the data to sql.
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…
You can do this: Click the Notification button on the Historical Log Configuration.
Definitely sounds like there is a problem, and you should probably have support open a ticket. As a work around, could you change the trigger from discrete to current value and set it to == 1 and see if that gets the desired result?
I have already switched mine away from discrete and move the value of 0 and 1 to and from the variable, in display I look for “is = 1” however still get a duplication in the log file
FYI - if any/all of you decide to contact support (support@opto22.com), which I recommend you do, mention ticket: trac ticket 87232 in your email.
Thanks!
-OptoMary