Duplication of Entries in Log file

Hi All,

I have a event triggered log file problem where entries are being duplicated.

The variable Ok_to_Record is set to trigger a recipe upload by PAC Display and create a historic log file.

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

Code Snippet

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.

Regards

Please wrap pretty much this exact post and email it to support at opto 22 dot com.
They will appreciate the detail and help you out.

I have the same problem. I always get two entries for each trigger. I thought it was just me!

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