• Not Answered

How to detect if DeltaV Operate is running

I want to detect, from within a control module, whether DeltaV Operate is running on a workstation.

I set up a simple watchdog system where a VBA procedure writes to the control module every 5s. This works fine except that the online change file for this module is growing rapidly as each write is recorded.

I wondered if there was a parameter that could be read from the module which would indicate when Operate was not running, even if this was just by its CST going bad. OPCWatchit shows some apparently useful parameters in the WS/Operator group such as EXIST but when selected in OPCWatchit they all report Bad, Comm Failure. In any case these parameters don't appear in the list of diagnostics available from the Expression Editor dialogue in Control Studio. Does anyone know of a suitable parameter, accessible from a control module?

The alternative might be to live with a big online change file. Does the system limit the size at some point?

 

Cedric Dawnhawk

• 7 Mar 2018 9:13 AM
• Cancel

10 Replies

• Matt Forbis

  

  • 7 Mar 2018 8:49 PM

  I don't believe there are any parameters you can read from within a control module to get the status on a workstation. In addition, there is probably not an easy way to write a parameter that is not logged. There might be some obscure way, but I think before I would offer a suggestion, I would be more curious of the need for determining whether Operate is running. If we knew what you were trying to accomplish, maybe we could suggest an alternative way to achieve your end result without needing to get into the details of the ideas you have proposed.
  
  There are limitations on the event chronicle, but in most cases, these are not hard limits. If you were to look in Books online, there are instructions that explain how to set up the size of the database as well as how to setup automatic exports of the event chronicle.

  • Cancel
• Cedric Dawnhawk

  

  • 9 Mar 2018 9:47 AM

  In reply to Matt Forbis:

  Thanks for taking an interest in my question. I had avoided describing the background to it as it is complicated. However here goes.
  
  The problem is that we have five workstations which can each control any one of three plants. Each plant has different audible spoken alarm messages. If two workstations are controlling the same plant the same message is spoken from each workstation but there tends to be an echo effect due to delays between the two. To make the message clearer, I want to limit alarm annunciation to a maximum of one workstation per plant by disabling the horn on the others. The operators do not have access to the horn disable so it can't be done manually. I need to detect when a workstation is changed to control of a different plant, but also if a workstation is no longer capable of producing the message, because DeltaV Operate is not running.
  
  The solution I came up with involves each workstation writing every 5s to a common module to indicate its own status, reading the status of the other workstations from this module and setting its own HORNENAB appropriately. This was fine apart from the potentially very large (2GB in 6 months) online change file that was being created. I could change the writes to occur only when there was a change in the plant being controlled by a workstation and also when DeltaV Operate starts and when it exits. However the DeltaV Operate exit write would not occur if Operate was ended abnormally.
  
  The other alternative might be for each workstation to read the status of all other workstations. This would detect if the workstation was powered up, but again is there a parameter that would tell me that Operate was running?
  
  Note my concern regarding file size is not in relation to Event Chronicle. I can easily prevent the writes being recorded there. It is the .imp file in the POWERUP folders for the module I am writing to that I am concerned about.

  • Cancel
• Leo Paradis

  

  • 9 Mar 2018 1:44 PM

  In reply to Cedric Dawnhawk:

  We reduce the size of the power up directory on occasion by bringing up (selecting upload) the associated module then just cancelling the upload. This cleans out all but the last change for each parameter.

  Leo

  • Cancel
• Youssef.El-Bahtimy

  

  • 9 Mar 2018 6:54 PM

  In reply to Cedric Dawnhawk:

  It sounds like your application is purely UI and does not need to register with the controller logic at all. Instead of registering with the controller, Operate could just write to a shared file that lives on the pro plus, as this is easy to do in vb. The next workstation would check this file to see who is in charge and as of what date/ time. If the last registered entry is older than your threshold, something is wrong and an available client needs to take control by enabling the local horn. There are probably more fancy ways to do it, but I'd say keep it out of the controller if it is not a controller function.

  • Cancel
• Andre Dicaire

  

  • 9 Mar 2018 9:22 PM

  In reply to Youssef.El-Bahtimy:

  An interesting problem. One I wish we had a better answer.
  
  As you know Reading data from the workstations eliminates the recorded Upload writes, but we can't expose any additional information from a workstation to controllers without writing to a parameter, even a Workstation module in the Pro Plus or App Station. What if each Workstation had the capacity to add parameters as needed that VB could write to and DeltaV could read, without Upload captures or Ejournal records? Hmm.
  
  Anyway, I'm wondering if you can use the Horn Parameter or other diagnostic parameter to read the "presence" of a workstation so that when an Operator station is not available (rebooted or disconnected, or Operate is not running), the status of the parameter would allow a controller to detect the station is gone, and remove it from being the active horn PC. Then you don't have to write every 5 seconds to and use a watchdog to detect the workstation is off line. Then you can move to a Write by Exception approach. (Read the current value and set it if it needs to change).
  
  Some diagnostic parameters are not available to control modules running in the controller, and I'm not sure if the HORN.ST would reflect that DeltaV Operate is shutdown while DeltaV services continue to work. My reference system is offline at the moment.
  
  Assuming you solve the Online/Offline monitoring using Parameter Reads, a control Module can host the desired State of each workstation. By keeping an array of which workstations are currently monitoring an area, but have suppressed the horn, you can evaluate which workstations are available and identify the station to switch to, in case the active horn station goes off line, or the user changes User Logon and such. Which would reduce your Parameter writes down to next to nothing.
  
  As Leo suggested, you can remove the pending upload file periodically, as part of your back up procedures script.
  
  I can see a lot of potential for each Workstation to have "silent" parameters to allow certain Operator station information to be shared. One application I had was to monitor the active Main Display and track this onto the screen of a second workstation. This allows a central display wall to be controlled from various Operator stations. With the click of a button, a workstations writes its main display name to a parameter, and the other workstation reads this. When it changes, the new display is programmatically called by the Display wall Workstation.

  Andre Dicaire

  • Cancel
• Cedric Dawnhawk

  

  • 10 Mar 2018 10:32 AM

  In reply to Leo Paradis:

  Yes about every six months we review the online changes for all modules and upload those that need to be made permanent and lose the rest. However I would have to do the upload of this module more frequently to avoid it growing very large. I estimated it would be 2GB in six months. I did find that it was possible to simply delete the .IMP file for the module in the POWERUP folders and the system immediately created another. Automating this deletion may be the answer.

  • Cancel
• Cedric Dawnhawk

  

  • 10 Mar 2018 10:39 AM

  In reply to Youssef.El-Bahtimy:

  Thanks for your contribution. My reason for using a module in a controller as the store for the status of the workstations was that it was a central location that would (nearly) always be available. If I use a workstation it is more likely to be unavailable and there would be extra complexity to cope with this. The module I am thinking of using is already dedicated to controlling an external horn in response to alarm changes anyway. However I will consider your idea.

  • Cancel
• Cedric Dawnhawk

  

  • 10 Mar 2018 10:56 AM

  In reply to Andre Dicaire:

  Thanks for your comprehensive thoughts on the problem.
  
  I did consider monitoring the status of the HORN parameter as we already read this in a module that controls an external horn. However a test (admittedly on a Simulate system) suggested that its status was Good even with Operate not running.
  
  As you say it is the offline/online detection that is the difficulty. I have developed a solution along the lines you suggest which seems to cope with any combination of plants and workstations.
  
  As I mentioned in my reply to Leo I found that the pending .IMP upload file could just be deleted and the system created another. I don't think there is any adverse effect on other modules. Maybe you can confirm this? This means that I could automate this - checking periodically if the file was more than a certain size and, if so, deleting it.

  • Cancel
• Andre Dicaire

  

  • 12 Mar 2018 2:57 PM

  In reply to Cedric Dawnhawk:

  Cedric, yes the .imp file can simply be deleted. As I suggested, you could add this to your automated backup procedure to remove these unwanted imp files on a daily basis. Make explicit commands to verify the file is present and to delete it by name.extension. You don't want to delete the wrong file. Note that the imp file may or may not exist. The error handling is always more work than the actual command you want to execute.

  Andre Dicaire

  • Cancel
• Cedric Dawnhawk

  

  • 13 Mar 2018 8:45 PM

  In reply to Andre Dicaire:

  I've set something up along the lines you suggest and it seems to be working well, at least on my simulate system. Now to try it for real...
  
  Thanks again

  • Cancel