Control.com - Nerds in Control

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

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.