• Not Answered

Series 2 Redundant Programmable Serial Card Diagnostic Parameters

We have an M-Series, Series 2 Redundant Programmable Serial Card that we reference some of its diagnostic parameters in our control strategy. I can't find any information on the meaning of the diagnostic parameters or their potential values.

Could someone please enlighten me as to the meaning/values of STBY_STATUS, ACT_STATUS, and STATUS for this type of card?

The cards are connected to some Mynah PIO modules that are connected to PLCs.

Do these status parameters only relate to the serial cards, or could they possibly refer to the PIO or PLC?

Any help would be appreciated.  Thank you.

Casey

4 Replies

  • Hey Casey, long time no talk! I'm so old that I remember installing those PIO modules! I don't have a live DV system in front of me, but I believe if you drill into the Diagnostics app and right click "help", it should give you some information.

    I believe Stby_Status and Act_Status just tell you which card is the active or standby in the redundant serial card. I don't believe it pulls the status from the PIO. That information may come from the serial data itself.
  • In reply to Gary Moore:

    Unfortunately, these parameters are not included in the diagnostic Help, or Books On Line. :-(

    the Status parameter tells you the overall status of the Serial Card Pair, which is a combination of the STBY and ACT Status values. The ACT_Status is the status of the active, whichever card is active.

    Apparently you get Good (0) or BAD (1). Looking at my system, I have a simplex Serial card, but redundant Profibus and H1 and they have PStatus which is the Pair Status. The Help (right click on a parameter and select help to see what is written about it) for Status includes the following section. These might apply to the PStatus of the Serial card, but I can't verify.

    STATUS parameter shows the following in the Diagnostic Help.

    Active is not configured
    Failed Component
    Good
    Redundancy Not Enabled
    Standby Not Available
    Standby Not Detected

    I checked the CTS data base and found a call that documented the ACT_SLOT and STBY_SLOT parameters, and stated these return the slot number of the Active and Standby cards. The example used slot 1 and 2, so I'm not sure if this is the unique slots 1 and 2, or a relative number meaning 1 = left and 2 = right, but that would be quick to check. Assuming it is position on the carrier, you can use this to indicate which physical card is active. But the ACT_Status and STBY status should always return the respective cards' status. The Diagnostic reference path will be by hardware, so if you look at slot 1 and it is active, you can still read the status of the standby in slot 2 via slot 1.

    Cheers.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Another note on the Redundant Serial card. When you have two or more devices connected to redundant cards, the cards do not switchover on a single fault. It does not evaluate which network is more complete, so if primary loses one of two devices due to a network or communication card failure in the PLC, you might have both PLC's talking on the secondary, but the Serial Card will not switch over by default as long as one device is successfully communicating. The premise is that whatever the fault, it is not in the Serial card.

    You can programmatically write to the Serial card switchover parameter and command it to switchover. You can read some diagnostic data and confirm if the Secondary network has better device coverage and force the switchover. There are any number of criteria you might decide to use to determine if a switchover is warranted, including evaluation of which devices are affected and such. If you dedicate on Serial card to a single redundant PLC, the loss of comms on the primary network will mean total loss of comm on that device and the card will switchover automatically on time out.

    Also, with multiple devices, loss of one device means a time out on datasets every time the card polls that device. So you will experience an added latency on all the data sets due to this ongoing verification for the device to return. I think on the initial loss of comms, the card retries according to the retry number, but on subsequent scans it does one try. Each scan becomes a retry. The impact is therefore minimized but is still there.

    Take these into consideration and understand how all your eggs are affected when they are in the same basket.

    Andre Dicaire

  • In reply to Andre Dicaire:

    Thank you for the help.
    It appears as though one of my control modules is referencing the STATUS parameter and expecting values similar to those described for PSTATUS (e.g. "Both Cards Report Problem", "Standby Card Problem", "Standby Card Not Present").
    I tried, unsuccessfully, to add the PSTATUS parameter to a trend so I could capture its value, since most of the issue seems to happen during the off-shift, but I couldn't browse to it and it just showed "No Data" if I typed it in. I tried, unsuccessfully, to add an external reference parameter pointing to PSTATUS in one of my modules, but when I downloaded the module, I got an unresolved reference warning. Any ideas why I can't get to the PSTATUS parameter in a control module or Process History View?
    Thanks again for the help.
    Casey

    I looked today, and saw where the card's stby_status and act_status showed "good", but the card's status was "possible field problem."

    Does anyone have any suggestions as to the cause of this issue or recommendations about which other parameters I should be monitoring?

    We are going to try looking at the port statuses and a dataset OInteg for the active card. We wanted to look at the same things for the standby card, but were unable to add them to PHV. Does anyone know how to trend these values for the standby card?

    Thanks for any help that anyone can give.

    Casey