Mark V <C> Core Error


Thread Starter


We are experiencing Communications failure to our GTG Server for one of three Mark V Systems.

The Error is noted on <C> Core. The Core is running at A7 and the error is QST DPM Timeout and DCC Errors are incrementing.

This has happened twice now and the 1st time we reset C core ... Is there anything else we can check please?


We're really glad you found this site.

It has a very good 'Search' feature; the search term entry field is located at the far right of the Menu bar at the top of every page.

Try using the Search term:


with the double quotation marks enveloping the terms.

This Diagnostic Alarm has been covered many times before on

I tried searching this issue already however nothing that seems to cover my issue.

Any thoughts please?

<b>When did this problem start?</b>

Other threads have mentioned that these kinds of problems usually occur when Pre-Vote Data Displays or Logic Forcing Displays are left open for long periods of time. Is that happening on this machine?

<b>Do you use <I>s or GE Mark V HMIs?</b>

If you use GE Mark V HMIs (running CIMPLICITY), has anyone made any changes to the CIMPLICITY project recently? Or to any displays?

Has anyone run MK5MAKE.BAT on the operator interface for the Mark V that's having the problem(s)? If someone ran MK5MAKE.BAT, why? Were changes made to sequencing or to any of the .ASG files? Were new signals added to any of the .ASG files? If the operator interface is an <I>, was the operator interface re-started after MK5MAKE.BAT was run? If the operator interface was a GE Mark V HMI, was the CIMPLICITY project updated?

Has anyone downloaded to the Mark V that's having the problems recently? If so, why?

The 3PL cable connecting the LCC/SLCC to the DCC/SDCC and to the TCCA (and TCCB if it's present) has also been quite problematic over the years. The absence of pull tabs means that it quite frequently gets "abused" when replacing PROMs or cards because it's not pulled carefully when unseating the connector from the card connector.

QST DPM means that something is asking <C> (in this case) to do something that it can't, or to find values or data that it can't. (QST means Queue Server Task; DPM means Dual-Ported Memory.)

There is a known problem with corrosion on the pins of ribbon cable connectors. Do you know if conductive grease was ever applied to the connectors, and if it was, how long ago?

All of these things have been mentioned previously in threads where this question has been asked. How does none of this relate to the problem you are having?

Sometimes, it's necessary to replace the DCC/SDCC card if the Dual-Ported Memory has failed (and it does fail sometimes). Sometimes, it's necessary to replace the LCC/SLCC card, as well. Also, heat and humidity and dust can cause premature electronic failures.

There have also been reported cases of failed ARCnet termination resistors and in more than several instances I have found Ethernet termination resistors had been used instead of 30-ohm ARCnet termination resistors--they worked for years in some cases, then the StageLink communications went bad, resulting in these, and other, Diagnostic Alarms.

Have you tried running ARCHWO or I_ARCHWO to see if there are any problems on the StageLink? It should only report the nodes on the link; if it reports every node or intermittent StageLink IDs which do not exist, there may be a cabling problem. (This has also been mentioned in other threads.)

Is there a fiber optic link in the StageLink? Are the hubs working correctly?

Have you checked for corrosion of the BNC fittings/connectors on the StageLink cable ends?

Please write back to let us know how you resolve the problem.

When you have made some troubleshooting efforts (even researching them) and haven't had any success, it's always best to detail what you've done and what the results were. That way you don't get told to do something you've already done, and we don't waste our time trying to think of everything to try to find out, "We've already done that."
This happened once In August and just now. We took the machine down and reset C Core and Monitoring now.

Logic Forcing Display being left open? We need to double check that for sure, quite possible!

We use Cimplicity and have never edited, downloaded or run any other software other than Cimplicity on these units.

Thanks for the details on the QST DPM as that's what we were looking for in all the other posts (Only 5 that i found??).

We thought similar checks as well for connections and or card replacement.

Will follow up on your suggestions and thanks