Emerson Exchange 365

• Not Answered

msgbox question

Is there a way to trigger a msgbox (D-V Operate) from a Control Module Parameter?

I understand that, usually, a msgbox (or any sub for that matter) would be trigger from a event on a page (button click). However, I would like to trigger a msgbox popup on the change of a control module parameter.

I would put all my conditions into a CND bloc, and the output (a parameter) would trigger the msgbox when changing to "true". Clicking "OK/YES" on the msgbox would reset that parameter to "false".

I have it working fine when I "click" to change it to true, but are unable to "read only" the parameter to trigger the msgbox.

Is there a way to do that, or I have to draw the "messge box" as a graphic item?

Thanks,

Pierre.

• DeltaV Operate
• VB
• control module

Pierre_Dion

• 18 Apr 2016 3:26 PM
• Cancel

15 Replies

• Bill Tinley

  

  • 18 Apr 2016 3:50 PM

  Pierre-
  
  You can do what you are asking by using the Scheduler- look in Books Online for the topic "The Scheduler" under "Mastering DeltaV Operate". You can create an event that runs a VBA script for your message box whenever the "OnTrue" event occurs for your monitored parameter.

  • Cancel
• Matt Stoner

  

  • 18 Apr 2016 4:32 PM

  You can create a picture variable and link this variable to a parameter from a module. Then you can have a script run when that datavalue changes and then show your message box.

  Here is the process:

  With your picture open, open the DeltaV toolbox (if not already open) and click the icon with the paperclip.

  

  Then fill out the form making sure to pick the right type of variable.

  

  Then find the variable in the system tree and right click and select Edit Script. The default should be OnChange but you can also select OnTrue or OnFalse for when you want your script to execute.

  The problem with this method is that it will only execute when the picture is open so if you want this to run regardless if a picture is open or not, you will need to go the scheduler route or put this variable in the toolbar or alarm banner which is always open.

  Regards,

  Matt

  • Cancel
• amodbobade

  

  • 19 Apr 2016 5:14 AM

  For such a requirement, it is better to use "DeltaV Alarm" functionality.
  It provides:
  1. Possibility to see alarm on any open graphic (Not graphic or workstation specific).
  2. Possibility to acknowledge (Click sets the parameter to False). Furthermore, it also provided the "Acknowledged - Active" state for the parameter.
  3. No need of additional scripting, which would keep the operator interface at optimum loading.
  4. Easy interface between Database & Graphics.
  5. Easy interface for historian & event chronicle.
  6. Some flexibility in terms of dedicated priority, message, & color possibilities (If available in project configuration).
  7. If the alarm is kept in a dedicated area, then it can even provide unique event to trigger an messagebox in HMI.
  
  Hope this would help!
  
  Best Regards,
  Amod.

  • Cancel
• Pierre_Dion

  

  • 19 Apr 2016 3:46 PM

  Thanks to all. I will have a look at all these options. All of them are interesting.

  • Cancel
• MichaelP

  

  • 19 Apr 2016 4:09 PM

  In reply to Pierre_Dion:

  Hello Pierre
  
  When complete would you report back to the forum on the solution.
  It is interesting for other use.
  Thanks.

  • Cancel
• Pierre_Dion

  

  • 19 Apr 2016 4:15 PM

  In reply to Matt Stoner:

  I will do a mix of your suggestion and Amod's. That will be perfect. Exactly what I was looking for. The operator page will be open since it will be actions on that page that would trigger the msgbox, specifically for that part of the process. It's a safety reminder when starting a process with some abnormal conditions still active.

  • Cancel
• Andre Dicaire

  

  • 19 Apr 2016 5:10 PM

  In reply to amodbobade:

  I'm not a fan of using the Alarm System for anything but the Alarm system. And an alarm is different than a message. What you say is true, but you have to allocate an alarm level this is not an alarm, and triage the information on alarm statistics and so on. The description of this problem is not consistent with alarm definitions. Since the message is ultimately intended to work with the operator interactively on a specific display, the use of a display variable with an OnChange event is appropriate. As for display loading, a specific onchange event in a display is not a concern for loading, while having the alarm report and trigger activity on all operator stations as a global event is.
  
  Too often we see non alarm events treated as alarms and then suffer the consequences of alarm floods and bloated nuisance alarms etc. If you do chose to use alarms as informational messages, always be thorough in the design such that it will not result in a poorly functioning alarm system.

  Andre Dicaire

  • Cancel
• MPHymel

  

  • 19 Apr 2016 5:47 PM

  In reply to Andre Dicaire:

  I like Matt's suggestion, this will serve a need I have as well.

  • Cancel
• amodbobade

  

  • 20 Apr 2016 3:41 AM

  In reply to Andre Dicaire:

  Agree Andre... Alarm system is not designed for operator messaging, but then DeltaV does not provide native functionality for operator prompts.
  You have to rely on either PMO blocks or on customization... or one can twist the native alarm functionality to make use of 'unused priorities' for some other better use.
  Also agree with the issue of nuisance alarm, but I think "bypassing the abnormal condition during startup" can surely be worth considered for an alarm.
  
  As I understand now that this functionality is only specific to one graphic, it is surely easier to do this with "on change" event of the parameter, as there is no need of schedule. But the issue with customization is, that it is never fully tested for all scenarios.... Some scenarios can be:
  1. What if the operator login is <None>. This user will not be allowed to write to this parameter on click of OK, but he can still open the messagebox. The code becomes further complex to check the operator login. Even more, if this this message is restricted to specific level of operation, as this is safety related (Kind of bypass for some abnormal conditions flags).
  2. The operator action will be logged in the event chronicle as "Parameter = 1" & not with a message for specific action. Or code will need to use customized "Logevent" function. If operator wants to see the exact "abnormal condition text" in the messagebox, then the code becomes more complex.
  3. What if the same graphic is open in two workstations & message box is opened at both places? will this log 2 events? With alarm it is always only 1 event. If you want to achieve this, then the code becomes more complex.
  4. What if the operator interface is down & someone wants to run this logic from module? User needs to take care that the module configuration takes care of this functionality. This makes the module code more complex.
  5. What if operator wants to resolve the abnormal condition & come back to click "OK". The message box cannot be open during this time. It has to be closed meanwhile & need to reopen after the checks are done. This makes the SOP as a "trial & error" process. All other events are blocked until operator clicks OK/cancel/close on this messagebox. If you want VBA to proceed for other events, then the code for messagebox becomes more complex.
  
  The DeltaV Operator interface is very flexible & versatile to write almost anything. It is up to the user on how much he wants to explore. But for certain functions like operator prompts, it has to be a standard process in the SW, which can be obtained (for now & Limited!) by use of alarm, until it is provided as native functionality in DeltaV.
  
  Best Regards,
  Amod.

  • Cancel
• amodbobade

  

  • 20 Apr 2016 3:48 AM

  In reply to amodbobade:

  Furthermore, I have seen that operators sometimes have tendency to click OK on prompts, without fully reading/understanding it.
  This is because the system does not proceed without this click. (e.g.: How many times do we read all given prompts during any software installation? or during download/upload of controllers?)
  
  But alarm acknowledge has a defined SOP that is followed, & are generally not clicked "unintentionally/accidently".

  • Cancel
• jiahui

  

  • 18 Apr 2017 6:43 AM

  In reply to Matt Stoner:

  Hi Matt
  
  I am trying to implement your solution. Have followed all the steps.
  The objective is to pop up a message prompt to operator when a particular valve is open.
  Do you have a sample script that i can use for OnTrue trigger?
  
  Have tried the following but seems like it is not working.
  
  Private Sub ps_Msgbox_OnTrue()
  MsgBox ("The Valve is open")
  End Sub
  
  Thank you very much
  Jiahui

  • Cancel
• Matt Stoner

  

  • 18 Apr 2017 12:38 PM

  In reply to jiahui:

  Remove the ( ) around the message box text, you only need those if you are assigning the result to a variable or checking (i.e. If Msgbox("The Valve is open") = vbOK Then)

  • Cancel
• jiahui

  

  • 19 Apr 2017 2:49 AM

  In reply to Matt Stoner:

  Thanks Matt
  
  Everything is working fine now!

  • Cancel
• jiahui

  

  • 19 Apr 2017 3:18 AM

  In reply to jiahui:

  Hi Matt
  
  If i want to have the Msgbox permanently displayed on 1 of the graphics.
  It will continuous monitor the valve.
  When the valve is open, it will display a text in green.
  When it is closed, it will display a text in red.
  
  What function or script do i need to write?
  
  Thank you very much
  Jiahui

  • Cancel
• dave_marshall

  

  • 19 Apr 2017 3:11 PM

  In reply to jiahui:

  Wouldn't this defeat the purpose of the pop-up message box? If I read the earlier posts correctly, wasn't the purpose of this to alert the operator to specific conditions that they need to pay attention to? If you do this, then how is it any different from a indicator on a graphic or an alarm? The message box (or custom form as the case may be) would eventually become part of the noise of the graphic and be ignored.
  
  This is certainly possible, but it seems like the wrong solution to achieve your goal. I would suggest examining the graphic(s) used and look for a re-design or modification that clearly displays the necessary information. Perhaps the strategic use of colors and alarms should be considered.

  • Cancel