Emerson Exchange 365

How an opertion/phase can recognise it was started outside of normal procedure or unit procedure structure

Hi there,

Looking for an idea as how a phase can determine (in run time) that it was loaded and started only by:

a)  loading and starting the associated operation using the standard Batch graphic Load and Start buttons (the operation/phase is started as a result of operator intervention in the recipe process). 

As against the phase starting automatically as part of a Procedure / UP / OP structure.

It's for operational reasons, it is necessary to catch that an operation/phase was started by an operator (via the batch system, using the standard Load and Start buttons).

Thanks for your time on this. 

• Operation Manaul Load Start recognise

MichaelP

• 18 May 2017 10:55 AM
• Cancel

2 Replies

• Matt Stoner

  

  • 18 May 2017 6:53 PM

  When running a phase manually from the batch executive there is probably only one way to 'check' that this is being run from a recipe and that is to have a recipe parameter that is set a certain way when running from recipes and defaulted to be something else in the phase and then "hope" the operator doesn't change this recipe parameter when starting manually.

  • Example - PHASE_MANUAL recipe parameter defaulted to be True in the Phase configuration and the Operation(s) will have this parameter downloaded as False when they run.

  You can't rely on Unit parameters OPERATION or UNITPROCEDURE as there is no way to tell that these items actually started the phase.

  If the phases are loaded from DeltaV Operate via the Unit Faceplate then you can look at the OWNER parameter of the phase.

  • "DeltaV Batch" if phase is started from Batch Executive (either from Recipe or Manual Phase)
  • "External" if manually loaded from Unit Faceplate.

  • Cancel
• MichaelP

  

  • 7 Jul 2017 8:06 AM

  In reply to Matt Stoner:

  Hi Matt, thanks for the reply. We continue to look into this.
  One item to mention on the topic, we look to use a receipe parameter as you mentioned, and to avoid the chance the operator can change this we think the on the parameter setting "Lock Changes to this parameter". This in turn uses key BATCH_MODIFY_LOCKED_PARAMETER, which is (by default ?...we are not sure) associated with lock "Batch Operate", which in turn is assigned to the batch operators (group in use here). So we would have to remove the BATCH_MODIFY_LOCKED_PARAMETER from the "Batch Operate" for this approach to work. We look into this to see what, if any, knock on effects this may have.
  
  If you have feedback on use of "Lock Changes to this parameter" or BATCH_MODIFY_LOCKED_PARAMETER please send on.
  
  Thanks.

  • Cancel