Mark-VI DCOM error


Thread Starter


I have a Mark-VI Control System installed on Gas Turbine. Recently, i have started facing a problem in that the Mark-VI station freezes up and needs to be restarted. This is occurring on a roughly weekly frequency.

On viewing the system log, DCOM error was identified with the error code. The same code description on Microsoft website suggests the following:

However, all permissions are already in place. No modifications in system/ *.m6b have been done and the problem has started to appear on its own.

Does anybody have any suggestions ?
Does the HMI at your site use MODBUS or GSM to communicate with a DCS or other control system?

The problem is likely not related to the .m6b file or Toolbox, but ... I have seen intermittent odd MS-Windows errors caused by keeping Toolbox continuously running. Usually when this occurs, it seems someone is forcing some variable and keep the forcing window open continuously "at the ready". (And usually, the reason for forcing the variable is an attempt at keeping the unit running with a very high exhaust temperature spread.)

I have also seen a couple of sites that left Trend Recorder running continuously for days at a time and they had odd MS-Windows errors reported, as well.

I have also seen this very same error message at about a one-per-week-rate, also. We used a hard drive optimization utility (I don't remember the name at this writing), shut down all running programs (meaning the HMI was "unavailable) and let the utility run--it ran for several hours. It did find and "block" several hard drive errors and after it was finished the problem did not reappear--for a few weeks, and then it came up randomly again for a few more weeks.

At that point we ran a BIOS utility to test the RAM modules in the CPU and it reported two errors with two of the four modules. We didn't have any new RAM modules at the time, so we removed them, cleaned the inside of the CPU case (it was very dirty), and re-installed the RAM modules taking care to seat them very carefully, several times. (One of the RAM modules did not seem to have been seated very well when we removed it.) We then powered-up the HMI and, to my knowledge that MS-Win2K-based HMI hasn't had any more DCOM errors.

Don't know if this will help, but take a look at how Toolbox is being used.
Firstly, CSA thanks for the detailed feedback.

Yes, the Control System does communicate with ABB DCS (AC-800F) but the communication is through OPC (optic cable).

There are no forcing or trend recorder related issues. As for hard drive optimization utility and BIOS utility, i can certainly have a look into that.
I'm no communications protocol expert, but I believe OPC makes use of DCOM on MS-Windows machines.

My point is that the problem is not likely Toolbox, the .m6b file, or the Mark VI.

Try to think of the Speedtronic panel as separate from the HMI. GE HMIs can be used to communicate with Mark IV, Mark V, Mark VI and Mark VIe panels. They are NOT the Speedtronic panel, though software on the HMIs can be used to program, configure and troubleshoot the Speedtronic panels. Operations are done through CIMPLICITY, and alarms are handled by TCI or WorkstationST or other GE-provided programs (based on the type of Speedtronic panel).

Yes, you need an HMI to operate a GE-design heavy duty gas turbine equipped with a Mark V or Mark VI or Mark VIe turbine control panel. But, it doesn't have to be a GE HMI. There are other vendors who are providing HMI solutions. The point here is that a problem with MS DCOM is not likely related to the Speedtronic or the file(s) used to program/configure the Speedtronic. And since communication with a Speedtronic panel is through either an ARCnet-based protocol (Mark V) or Ethernet (Mark VI and Mark VIe)--neither of which use DCOM if I understand them correctly--it's a better troubleshooting path to look at things that do use DCOM than things that don't.

I don't know if TCI or WorkstationST use DCOM, but they're still not directly related to the Speedtronic panel--only to transferring information from EGD to CIMPLICITY.
I used both hard drive and BIOS optimization utilities, however no errors were reported.

Anyhow, i have cleaned the CPU internals today. Let's see if the error re-occurs within the next week.