step index in the sfc

hi 

i have problem understanding step index concept in the sfc .please describe for me to understand that .

for example in my plant we have to many sfc logic . in the some of the action(last action) we have( '^/STEP_INDEX.CV' := 10;) or ('^/STEP_INDEX.CV' := 20;)

what does it mean 10 ,20?

  • STEP_INDEX is normally found in Equipment Modules or PLM modules, in an SFC only module STEP_INDEX is not by default. From the expression you detail above, the actions are assigning a number to the variable STEP_INDEX. The main reason for doing this is for external traceability, i.e. other calling modules (or graphics) can resolve the actual step number easier than referencing a step name.

    Typically, I would link the step number with a named set, that would list my step names, this would then be used on my graphics. In other logic, I would trigger other actions based upon STEP_INDEX equaling a value rather than writing script that used step names.

    Hope that helps.
  • In reply to AdrianOffield:

    Very much as  Adrian stated. Just to add I understand in has origins in an SFC visualisation implementation used within Emerson projects delivered from the European region late 90's, early 2000's, it was then adopted as a norm for projects delivered based on PCSD. This allowed the visualisation package to be added on top if required without need for SFC alteration.

    There is also an indicator on the EM detail displays EM_INFO tab that could well be this number.

    It is not a standard or required parameter for DeltaV, you'll not see it in out of the box non PCSD installations  (see correction to this statement in a post that follows) Even then, it's not a bad concept and probably worth retaining something similar for SFC traceability in any SFC implementation.

    Just one note on something Adrian mentioned. From a configuration maintenance perspective, using raw, non functional numbers, to keep track of one SFC from another SFC carries a minor risk in the case of future SFC alterations. Imagine you were referring to step number 40 as an indication of a particular process condition being satisfied, if someone alters the reference (source) SFC and inserts a couple of steps and happens to renumber the step index numbers as it might seem sensible to do, the referencing SFC would become confused. I would much rather see functionally named indicator flags such as TEMP_ACHIEVED at the source SFC. If you do choose to go down the step index referencing route, the future modification should avoid step renumbering, instead use intermediate step numbers. In my example possibly 33, 35, 37. For this reason at initial implementation you should probably consider using step gaps of at least 100, i.e. 100, 200, 300 as it allows you to later insert a larger number of  future steps without causing yourself step numbering issues.

  • We use STEP_INDEX as a way to recover from our hold logic. We do it both in sfcs and phases (structured sfcs). As an example if we are in the middle of a charge and go to hold when we come back from hold the STEP_INDEX would be used to skip resetting the integrators as we do not want to restart the charge but continue from where it left off. We do use integers, not named sets, as we did not feel like coming up with names for all the places we increment the STEP INDEX. We set STEP INDEX to 999 when we are done.
    Hope this helps.
  • In reply to IntuitiveNeil:

    Slight correction to my original post.

    STEP_INDEX "is" a standard phase logic parameter in DeltaV out of the box. From Books online...

    STEP_INDEX is a 16-bit unsigned integer Configured by the user, the STEP_INDEX can be used to indicate each step in a phase to track the phase while running. This is an integer written by the phase logic for use by recipe logic or DeltaV Operate.

  • Like it's stated in BOL, step-index can be used for tracking phase (or general SFC) logic. You're free to decide if you want to use it and how.
    In 1 plant we use step-index for visualizing transition conditions to operators and even evaluate the transition itself. Also we sometimes use it in transitions in operations, but we try to avoid this.
    In another plant it's used as a restart-pointer to jump right back where phase went to 'holding/held'.