Emerson Exchange 365

Sequence (SFC) Programming Standards

Hey, I wanted to open a discussion on programming standards for sequencing. I have some time to Create a standard of how we would like our existing vessels (currently running on Old PLC controllers) to run after a Delta V upgrade.  We have  old ways of doing things using Transitions and steps and I recently adopted the idea of using Confirm Expressions and Confirm Timeouts (in the Step Actions). We are also going to go forward with Confirming that the .AWST parameters equal 0 Before Proceeding. Transitions will be Used to monitor the Step actions PENDING_CONFIRMS and CONFIRM_FAIL. 

The next programming standard that I would like to explore is Writing Controller modes. Currently, When the Vessel Backwash is initiated the inhibits must be satisfied. These inhibits consist of Tank Levels, Pressures ETC. As the Backwash Continues through the steps, I've found that it will actually change the Controller modes of flow controllers (RCAS) and set the RCAS setpoints. 

I think this is a bad practice, since basically your giving the processor permission to just change your flow controller mode and write it a setpoint when you click BACKWASH. What if the operator needed the valve in Manual 0%? and then a backwash is auto initiated and suddenly there valve is in RCAS 100% open? 

My thoughts are to avoid ever coding the Processors to change controllers modes as it should always be an operator that initiates this change. 

I think if we made the  Flow controller modes an inhibit to backwash, it will be a good standard to follow. That way the Operator must physically change the controller mode  and mentally accept that the program may change setpoints at will. But what if there is a better, safer way of accomplishing this idea? 

Any other Great ideas for creating the Best sequence ever is much appreciated :) 

Thanks,

Shamusk 

Shamusk

• 31 Aug 2021 2:55 PM
• Cancel

7 Replies

• SBPosey

  

  • 31 Aug 2021 4:18 PM

  We have different categories of things that are automated in an SFC:
  Sequences that need to happen quickly
  Sequences that are complicated
  Sequences that are frequent and tedious
  
  You post mentioned the backwash being "auto initiated", but it seemed that it takes an operator action to initiate backwash.
  The sequence should do the things the sequence needs to do. If the operator "needs" a valve at 0%, but then initiates a backwash and the backwash sequence needs the valve open, then the operator shouldn't initiate a backwash.
  We have sequences in which controllers need to go 100% until some process condition is met, then set to a particular setpoint until some other process condition is met, then to 0% (the sequence doing other things in the meantime). If the sequence had to stop and wait for the operator to change modes each time a mode change is needed, the sequence would run much slower than it needs to run. For us, this is unacceptable.
  
  The operators need to be trained on what a sequence will do. For your case, if the backwash sequence will put the controller mode in RCAS at 100%, the operator needs to know that will happen when they initiate the sequence. If the operator needs the valve to be closed because of some plant condition, then certainly the sequence should not be allowed to run when the plant is in that condition.
  
  That said, if your facility wants to have mode changes initiated only by the operator, then that should be the standard that your sequences follow.

  • Cancel
• Nicholas Stom

  

  • 31 Aug 2021 4:25 PM

  Your question reads like you are discussing all control modules not just the one specific to backwash.
  
  It is common to have your SFC steps/action set the mode of control modules (ex. mode.target := CAS) and then confirm expression mode.actual = CAS, then your next action is delayed until mode.actual = CAS and then the action gives the setpoint.
  
  There are some examples out there that handle some of your concerns in a great way using an owner id parameter of the control module and if its owned be an operator then your sfc logic waits until no one/no higher level module owns the device, then the sfc logic can take owner ship of the device. Prior to ever attempting to change modes or set point. This creates exclusivity to who is/can commanding the device.
  
  There is nothing stopping you from creating your standard to say only the operators can change the mode of control modules and if you only have a few devices then maybe you wont run into any problems, but if i have 500 valves in my system and sometimes operators or maintenance needs to control them for trouble shooting then and they forget to set the mode back after using it, then i got an SFC logic hung up waiting for a bunch of devices to be manually set to the right mode.

  • Cancel
• Shamusk

  

  • 31 Aug 2021 4:58 PM

  In reply to Nicholas Stom:

  Ok Good to know. I've only ever programmed at this site so I wasn't sure if its normal to have your SFCs pulsing modes. Tell me more about this Owner ID parameter and how it would be able to tell if an operator owns it. That may work for us. As SBPosey categorized above, most of our sequences are complicated at the most and in this case (as well as many others) we would only need to run an inhibit off of 3 PID controllers. But you have a valid point, we don't want to get stuck programming sequences that you must set 500 Valve modes to start the vessel simply because we are following a standard that did not account for the future LOL.

  • Cancel
• Shamusk

  

  • 31 Aug 2021 5:07 PM

  In reply to SBPosey:

  This SFC would be classified as complicated. Normally Ops watch their flow accumulators and manually queue up backwashes but, they can also turn on Auto Queue and the vessels will queue depending on accumulated flow. I totally agree but as we all know, human intervention means error. Our ops know what they must do or which controllers change modes but everyone has bad days. I feel that we can further automate what they must remember and take that stress off their shoulders. And not to mention the trainees that just don't know. I want to make our standard as close to dummy proof as we can get it.

  • Cancel
• Nicholas Stom

  

  • 31 Aug 2021 5:32 PM

  In reply to Shamusk:

  Sure. On every control module and equipment module a string parameter was created, owner id.
  In my example here phase will drive em's and em's will drive cm's.
  Batch is loaded, phase is then loaded, there is an step in the phase that tries to set the owner id of all the EM's it needs to the name of the unit the phase is loaded to, then the EM sets the owner id of all the control modules that the EM uses to the name of the EM. (Typically owner is displayed on the faceplate). The phase basically says if em/owner id = none then em/ownerid := me, if your em is currenly owned by someone/somethign else then your phase waits there and waits for whatever is currently using the em to release. same thing on the control module level.
  
  There is typicall a button on the device faceplate that is like "Own" and "Release" when you click the "Own" button the owner becomes the operator and then when the Operator is done they click "Release" the owner goes back to none. typically the "Own" and "Release" buttons are unclickable if the device is owned by unit/em/cm so that no one can release it.

  • Cancel
• SBPosey

  

  • 31 Aug 2021 5:50 PM

  In reply to Nicholas Stom:

  If you are outside the realm of Batch (Phase Logic Modules use the S88 Batch Standard), you can also create "selector" modules (kind of like a device with no I/O -- Operator sets setpoint to "OPERATOR", module gets a PV of "OPERATOR"). The sequence can be prevented from doing its thing by checking the PV of the selector. If the PV is OPERATOR, then the sequence treats it as hands-off -- the selector PV becomes one of the inhibits. When operator is done with being in exclusive control of a valve (or any set of equipment), the operator can give a "NORMAL" setpoint to the selector. Each selector can have as many setpoints as needed, each setpoint can be named whatever you wish to name them, and you can have as many selectors as your controller loading can support.

  • Cancel
• Nicholas Stom

  

  • 31 Aug 2021 6:00 PM

  In reply to SBPosey:

  Sounds like another good option, i hope i get to see that one day! On our utilities systems where we didnt run batches logic we would use the same functionality except instead of a phase being the one to initiate the setting of Owner ids, the operator would just take ownership of the EM and then em would set CM owners. and then command the EM .

  • Cancel