Mark V problem

Posted by wstei on 11 July, 2008 - 1:26 am

Mark V with <I> setup on a Frame 6FA. R and T cores are displaying messages on the LCC (see below). R
& T Core DPM bad protocol message came in first. Rebooted processors and the message cleared, but
came back a few weeks later. Today additional alarms and messages were received. Would like to know
what the messages mean and where to start troubleshooting.

Thanks.

R CORE
4 DCC ERRORS
NO QST AVAILABLE
QST DPM NO DEST

T CORE
5 DCC ERRORS
NO QST AVAILABLE QST DPM NO DEST
DPM BAD PROTOCOL 

Got the following alarm messages: 

11-JUN-2008 18:55:18.000 T2 R 0020 TRUE DALARM DCC Message received with bad protocol
11-JUN-2008 18:56:47.000 T2 R 0020 FALSE DALARM DCC Message received with bad protocol

09-JUL-2008 13:04:19.031 T2 Q 0000 TRUE PALARM DIAGNOSTIC ALARM <C><Q>

09-JUL-2008 13:04:18.000 T2 R 0005 TRUE DALARM DCC No queue server for destination
09-JUL-2008 13:04:18.000 T2 R 0009 TRUE DALARM DCC DPM: Invalid destination address
09-JUL-2008 13:04:29.031 T2 Q 0000 TRUE PALARM DIAGNOSTIC ALARM <C><Q>
09-JUL-2008 13:04:28.000 T2 S 0005 TRUE DALARM DCC No queue server for destination
09-JUL-2008 13:04:28.000 T2 S 0009 TRUE DALARM DCC DPM: Invalid destination address
09-JUL-2008 13:04:39.031 T2 Q 0000 TRUE PALARM DIAGNOSTIC ALARM <C><Q>
09-JUL-2008 13:04:38.000 T2 T 0005 TRUE DALARM DCC No queue server for destination
09-JUL-2008 13:04:38.000 T2 T 0009 TRUE DALARM DCC DPM: Invalid destination address
09-JUL-2008 13:05:41.000 T2 R 0005 FALSE DALARM DCC No queue server for destination
09-JUL-2008 13:05:41.000 T2 R 0009 FALSE DALARM DCC DPM: Invalid destination address
09-JUL-2008 13:05:41.000 T2 S 0005 FALSE DALARM DCC No queue server for destination
09-JUL-2008 13:05:41.000 T2 S 0009 FALSE DALARM DCC DPM: Invalid destination address
09-JUL-2008 13:06:41.000 T2 T 0005 FALSE DALARM DCC No queue server for destination
09-JUL-2008 13:06:41.000 T2 T 0009 FALSE DALARM DCC DPM: Invalid destination address
Reply to this post...

Posted by CSA on 17 July, 2008 - 2:30 am

QST = Queue Server Task

DPM = Dual-Ported Memory 

You say the unit has an <I>; does the <I> use MODBUS to communicate with a DCS or some other
controller? Has someone made a change to MODBUS.DAT or the DCS/controller MODBUS files? 
Does the unit have an OSM or UOSM? 

Has TIL-1480 been done on the Mark V? 

Has conductive grease been applied to all the ribbon cables/connectors, including the power cables and
VARC and BUNET and IONET connectors? 

What is the temperature inside the compartment or enclosure where the Mark V is located? Has it been
hotter than normal? More humid than normal? Drier or dustier than normal? Has it been cooler than normal
(has(have) the temperature setpoint(s) been reduced greatly recently? When was the last time the Mark V
panel had any housekeeping done (dusting and vacuuming)? 

Did the problems begin after some downloading to the Mark V? If so, what was downloaded? Was (Were)
the download(s) done for any reason other than an I/O Configuration change? 

If the download was made because of an I/O Config change, does the <I> use individual I/O Config files? 

Has a MK5MAKE been done recently for any reason? If so, for what reason? (I'm *not* suggesting that a
MK5MAKE be done; just asking if one has been done.) 

If the unit uses an OSM or UOSM and a MK5MAKE was done, were the configuration files transferred to
the OSM or UOSM? 

There seems to be some problem with the DENET (the ARCnet link between <R>, <S>, <T>, and <C>).
This usually happens when "malformed" requests for data are made, or when downloads have been made to
the processors which are not identical (with the exception of individual I/O Config downloads, if used). 

These kinds of problems can also occur when the Logic Forcing Display or the Prevote Data Display is left
open for long periods of time (though this is much more likely to occur on HMIs because multiple Logic
Forcing and Prevote Data Displays can be opened simultaneously). Both Logic Forcing and Prevote Data
(and even DIAGC) ask for processor-specific data at very high rates and this can cause communication
issues. 

One last thing that can happen when new signals are added to UNITDATA.DAT for <Q>, and a
MK5MAKE is done, and the new information is only downloaded to <Q>. It's my beliefe that everything
that is in <Q>'s Control Signal Database (CDB) is a subset of what's in <C>'s CDB. I've seen similar
problems occur after making changes to <Q>'s CDB and only downloading to <Q> and re-booting <Q>
only, and suddenly go away when nothing more than a download to <C> is done and <C> is re-booted.
This isn't a very likely occurrence, but it has occurred a couple of times. 

So, we'd love to hear the answers to all the questions (even the ones you think are not relevant; we don't ask
irrelevant questions (at least not intentionally) here at control.com). There can be many causes for problems
like this. It could even be a problem with the DCC/SDCC card on <C>, or the TCCA card in <C>, but not
usually. Most times it's because of high data requests (especially from displays like Logic Forcing or
Prevote Data) or malformed data requests (like from MODBUS or an OSM or UOSM) or from not
downloading the same information to all three processors (except for the I/O Config). 

We'd also like to know if any of the above suggestions resolves the problem, or if something else resolves
the problem. Feedback is the most important contribution here at control.com.
Reply to this post...