Force Redundancy Switchover Command within DeltaV Operate

How do I force a redundancy switchover on a redundant card from within DeltaV Operate?

From Diagnostics, this is easily done but I want an operator to have the ability to do it from a DeltaV display.

 

Thanks for your assistance.

  • redudancy check for the deltav redudant card is possible from physical removing the redudant card and then it automatically take over to other .
  • Thanks for the reply.  I’m looking for a way for an operator to switch to backup card from DeltaV Operate.
    We have two NAU’s coming into redundant serial cards and sometimes the active NAU will lock up in such a way that the data just quits updating into DeltaV and a way to switch to the backup card from DeltaV Operate would be desirable.
     
                       
     
  • In reply to TexasDV:

    It took a while to clear the cobwebs...

    You can force a switch over of the serial card by writing to the SWREQ parameter. This is undocumented.

    The Serial card is designed to switch over when it loses the ability to communicate on the serial bus. When there are two or more devices on the bus, a situation arises when one device may fail to communicate, but other devices do. The Serial card sees this communication and knows it is not faulty, and a switchover does not happen. The work around is to monitor the health of the devices on both the active and stand by cards, and if a switch over need is detected, you can programmatically request the switchover.

    In your case, you can create a module that has an Operator activated parameter. When this is set True, an action block or CALC block can execute the SWREQ command and force the card to switch over.

    '//CNTRL-1/IO1/C1/SWREQ.CV':=1;

    I believe this parameter is not recognized by the database so if you do place this in a module, I recommend you create a dynamic reference and use an expression to set the path after download. This keeps the download verification from reporting an "unresolved" error, that actually will not be unresolved.

    You'll need to proceed carefully and test the behavior of the commend. Not sure if you have to reset this to 0. you can verify the redundancy OINTEG and availability to indicate to the operator the command is able to execute. Maybe disable and shade out the button when the standby card is not available.

    I'd start with the Dynamic Reference, define the path and then manually manipulate the parameter to observe the behavior of the card. Once you understand the timing and values needed (1 or 0) then you can set up the module to allow the operator to trigger it.

    I would not recommend this to be manipulate directly from VBA script. Every console would have the code. Better to manage this in one location and let operators write to a module level parameter.

    Good luck.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thanks Andre. I agree with creating a module to write to a parameter to execute this command. I'll work on getting this together and get back to you when we get it to work.
  • In reply to Andre Dicaire:

    This worked. We had no problem downloading using standard referencing with the ACT block. We used a TP1 block to write to the ACT1 block and we had to extend the pulse time to between 6 and 10 seconds to get it to switch consistently. We also set the SWREQ back to "0" after the pulse time. Now to put it into DeltaV Operate with the "Switch_Avail" = True and "OInteg = Good" conditionals.
  • In reply to TexasDV:

    Glad to hear it. I think the solution I say was to set the SWREQ true and wait for Switch Avail an OInteg to clear, and then to set SWREQ to false. I find it better to explicitly confirm something rather than an independent timer. I'd use a timer to set a time out condition.

    It seems the SWREQ is a triggered on the transition, and it does not cause the cards to constantly switch back and forth if it is left "On" or 1.

    Is the OINTEG a valid check? If the Standby card becomes available, but there is still some integrity issue with one device or data set or something, OINTEG might still be "BAD" but a switchover might still be warranted. You might want to be a bit more precise on what enables/disables ability to request the switchover.

    If you can, please confirm that the SWREQ only triggers the switch over on a transition from 0 to 1. Thanks.

    Andre Dicaire