Emerson Exchange 365

• Not Answered

Eliminate multiple Event Chronicle entries for the same user action

I'm trying to use DeltaV Analyze "User Actions" to identify areas of the process requiring the most interaction (some type of change) from the operators.

We noticed that a graphic button object used to restart a sequence was generating numerous log entries in the Event Chronicle.  Looking deeper, we noticed that often, there were two or three or even more entries per second.  At first, we questioned whether or not these entries were being logged correctly.  But with offline testing, I was able to generate up to 9 entries over one second by clicking the mouse as quickly as possible. 

So, it seems that some operators take the approach of click, click, click, click, etc. instead of just clicking once.  While I realize this is an opportunity for training, I also realize that this action is unlikely to go away permanently. 

Is it possible for the Event Chronicle to recognize these as a single action vs. multiple?  If not, has anyone used any logic in the visual basic script to filter these out? 

I realize that it is technically really multiple user actions in the world of a computer, but for an operator, its like hitting the elevator button several times to make sure it "took it".   Being that the associated control module scans once per second, logging multiple user actions that write the same value within a second is annoying and misleading for user action reporting. 

• event chronicle
• Analyze

Michael Moody

• 2 Nov 2016 3:24 PM
• Cancel

1 Reply

• Andre Dicaire

  

  • 2 Nov 2016 4:31 PM

  You've pointed out the underlying issue. Computers do what you tell them. It is not possible for Event Chronicle to filter or discard messages. This is something a client application retrieving this data might do, treating them as identical messages, even though they have a slightly different time stamp.
  
  The solution is to intercept the mouse click actions in the Operate script, and only execute the write to the controller once. The event messages are from the actual write action that is being passed to the DeltaV communication layer, and not from the clicks. I can think of several ways to address this, but the simplest is to execute the write from a popup dialog, such that on the first click, the Operator is prompted to press OK to execute the write. This would eliminate the "happy clicking" and provide positive feedback the write has been executed. Then you will only see one change event in the event chronicle.
  
  I'm thinking you could also manipulate the button such that on the first click, the click action is hidden/disabled, and is enabled a second or two later when the button is valid to use again. For instance, if the button is used to start an SFC, it could be disabled when the SFC is running. When the SFC stops, an on_change event could re-activate the button for subsequent use. This would require some serious thought to create a solid solution that would not leave the button unavailable when it is actually needed.
  
  Maybe it would be as simple as using a variable that you reset to 0 every couple of seconds. Protected one time clicks would set this value to unique number, and on a click, you check if the variable is already equal to your button value. If not, execute and set the value. If you click again on the same button, you skip the write. If you click on another button, it sets the same variable to its button value, which is different, so the first click will work. if you go back to the first button, it would now work one time. Then set a periodic reset of the variable to 0, maybe every two or 5 seconds. I would also add a visual change in the button to show that it has been pressed and is not ready to accept another command. Then think about ensuring this variable is cleared when ever the Picture opens, and lastly, add a manual clearing of the variable, as a way to ensure the operator can always issue the command, even if the automatic reset fails for some reason. Ok, not that simple...
  
  As you can see, the bigger challenge is to handle the what if and error scenarios, and not so much preventing multiple clicks. Adding a confirmation dialog seems the easiest, but it adds a mandatory click. Making the script "Multi Click" aware will take a bit more work to ensure your solution works 100% of the time as needed.
  
  Hopefully someone has solved this and will post to this thread.

  Andre Dicaire

  • Cancel