Hello, I have problems with a markV Simplex, HMI with sonftaware GCI and cimpliciti 9.0.

#1- The problem occurs when I do logical forces. The forces that I do on input points on CD work Ok, if I look at the prevote data it is seen that the point is forced on both R and C processors and the Mark F appears above the forced point in the rung
But when I do the same at a point in QD it only changes state in R, in C it remains with its original state, and it does not show me the F mark indicating that it is forced. It is difficult because if in a test I do not write which signals I force, to be sure that there are none, I must restart the Mark V
Any idea what it could be?

#2- diagnostic alarm
It repeatedly throws me diagnostic alarms
TCE1 power supply out of limits dcom
TCE2 power supply out of limits dcom
TCE3 power supply out of limits dcom
What should I check to solve the problem?

I have many more alarms but I don't want to bother you, it is a machine abandoned for more than 10 years and it is in the recovery process

 

1) I don't believe I've ever heard of "sonftaware" and I think "cimpliciti" is CIMPLICITY. I don't know as I've ever looked at signals in Rung Display when they've been forced and if I did I don't recall seeing an F above the rung to indicate it was forced.

In my personal opinion, Prevote Data Display is kind of useless for SIMPLEX Mark* control panels, particularly Mark* V turbine control panels. About the only place voting is taking place is in <P> (where the TCEA cards are located, and TCTx card (might be a TCTG if a gas turbine, or TCTS or TCTL if a steam turbine). So, I don't think I would put any emphasis on <C> or <R> signals when looking in Prevote Data Display--that's just my personal opinion based on a lot of experience with Mark* V turbine control panels/systems.

2) It's interesting that all three TCEA cards in <P> are reporting the same problem with respect to DCOM. ALL DC signals in the Mark* V are relative to ONE ground, be it DCOM or PCOM or any DC voltage--they are all connected to/referenced to the same ground--which is the ground the Mark* V turbine control panel is connected to. Each TCEA card should have a white wire connected to it that is connected to a ground bar which is common to the entire Mark* V control panel AND to the earth/ground grid the Mark* V SHOULD be connected to. (A LOT of Mark* Vs were not properly grounded during installation. If the control panel was in a metal compartment and the metal compartment was connected directly to earth/ground many people falsely believed that was a sufficient ground (the control panel being bolted to the floor supports. But, all of the metal was painted, and bolting only provided a false sense of ground. MANY nuisance control system problems could be solved by simply connecting a suitably sized ground conducot to the plant earth/ground grid AND to the earth/ground bar in the bottom of the Mark* V panel (sometimes it was on the right side wall, often it was in the middle of the rear wall, under the contact input modules. Without a solid connection to the plant earth/ground grid many odd, unusual and intermittent problems often occured that were blamed on the Mark* V (ALL problems were initially ALWAYS blamed on the Mark* V)--but if it's not properly grounded it can't work reliably, now can it.?.?.???!?!?!)). But, I would START by checking to be sure there is a proper earthing/grounding conductor connected directly to the earth/ground bus bar in the bottom of the Mark* V turbine control panel AND to the plant earth/ground grid. The act of connecting a conductor to a earth/ground grid is often called "bonding" and it is very important that it be done properly. I have bonded one end of a earth/ground conductor to the large bare copper cable which is usually solidly clamped to the metal base of the control panel enclosure (the PEECC, or the control compartment) using a copper earthing/grounding clamp; sometimes it was necessary to braze the two cables together with copper brazing rod when we couldn't obtain a grounding clamp quickly. (I think we even used bronze brazing rod at one site--and when it was done a site which had been complaining for months about nuisance, intermittent problems suddenly stopped complaining, because they all stopped. NOT a Mark* V problem; an installation/commissioning problem.)

Anyway, some Mark* V operator interfaces had a couple of ASCII text files that were sometimes useful for troubleshooting Diagnostic Alarms. HELP_QD.DAT and HELP_BD.DAT were a couple of the file names which had some information, still kind of cryptic but better than nothing sometimes. If you can list a few of the Diagnostic Alarms at a time we can try to help, and you might begin to see how to understand those cryptic messages and how to interpret them. We can try, anyway.

 

1) I don't believe I've ever heard of "sonftaware" and I think "cimpliciti" is CIMPLICITY. I don't know as I've ever looked at signals in Rung Display when they've been forced and if I did I don't recall seeing an F above the rung to indicate it was forced.

In my personal opinion, Prevote Data Display is kind of useless for SIMPLEX Mark* control panels, particularly Mark* V turbine control panels. About the only place voting is taking place is in <P> (where the TCEA cards are located, and TCTx card (might be a TCTG if a gas turbine, or TCTS or TCTL if a steam turbine). So, I don't think I would put any emphasis on <C> or <R> signals when looking in Prevote Data Display--that's just my personal opinion based on a lot of experience with Mark* V turbine control panels/systems.

2) It's interesting that all three TCEA cards in <P> are reporting the same problem with respect to DCOM. ALL DC signals in the Mark* V are relative to ONE ground, be it DCOM or PCOM or any DC voltage--they are all connected to/referenced to the same ground--which is the ground the Mark* V turbine control panel is connected to. Each TCEA card should have a white wire connected to it that is connected to a ground bar which is common to the entire Mark* V control panel AND to the earth/ground grid the Mark* V SHOULD be connected to. (A LOT of Mark* Vs were not properly grounded during installation. If the control panel was in a metal compartment and the metal compartment was connected directly to earth/ground many people falsely believed that was a sufficient ground (the control panel being bolted to the floor supports. But, all of the metal was painted, and bolting only provided a false sense of ground. MANY nuisance control system problems could be solved by simply connecting a suitably sized ground conducot to the plant earth/ground grid AND to the earth/ground bar in the bottom of the Mark* V panel (sometimes it was on the right side wall, often it was in the middle of the rear wall, under the contact input modules. Without a solid connection to the plant earth/ground grid many odd, unusual and intermittent problems often occured that were blamed on the Mark* V (ALL problems were initially ALWAYS blamed on the Mark* V)--but if it's not properly grounded it can't work reliably, now can it.?.?.???!?!?!)). But, I would START by checking to be sure there is a proper earthing/grounding conductor connected directly to the earth/ground bus bar in the bottom of the Mark* V turbine control panel AND to the plant earth/ground grid. The act of connecting a conductor to a earth/ground grid is often called "bonding" and it is very important that it be done properly. I have bonded one end of a earth/ground conductor to the large bare copper cable which is usually solidly clamped to the metal base of the control panel enclosure (the PEECC, or the control compartment) using a copper earthing/grounding clamp; sometimes it was necessary to braze the two cables together with copper brazing rod when we couldn't obtain a grounding clamp quickly. (I think we even used bronze brazing rod at one site--and when it was done a site which had been complaining for months about nuisance, intermittent problems suddenly stopped complaining, because they all stopped. NOT a Mark* V problem; an installation/commissioning problem.)

Anyway, some Mark* V operator interfaces had a couple of ASCII text files that were sometimes useful for troubleshooting Diagnostic Alarms. HELP_QD.DAT and HELP_BD.DAT were a couple of the file names which had some information, still kind of cryptic but better than nothing sometimes. If you can list a few of the Diagnostic Alarms at a time we can try to help, and you might begin to see how to understand those cryptic messages and how to interpret them. We can try, anyway.

Greetings WTF!!! Thanks for your answer.

Sorry for the errors but the proofreader and translator sometimes modify the information.

Regarding point #2, I will check tomorrow the correct connection of the cables in each TCEA, they may not be correctly connected to ground

Fortunately I have the help files for the diagnostic alarms you mention, but sometimes they don't help much.

For example, I have many voter mistmatch alarms and I can't find a help file to guide me where to look.
I attach an image of the diagnostic alarms

Thanks for your help.

 

Thank you for the reply and image. The image is incomplete; I'm sure it's just a short sample of the alarms, but it doesn't show the signal names which are mismatched.

ALSO, it seems the HMI is not a GE Mark* HMI. Perhaps you are trying to force logic from [???] in order to test this HMI to see if it functions properly.?.?.? If you're using the GCI HMI for forcing, then I can't explain what is happening and why it's not displaying the information in the manner you are expecting it to. We also don't know if the GCI HMI is communicating via the StageLink (ARCnet) or some perversion of the StageLink using protocol converters--we just don't know. Are you using some version of OPC through an existing GE operator interface over Ethernet? Again, we don't know enough about what you're doing and how you're doing it.

If you're using a GE operator interface (either and <I> running IDOS, or a GE Mark*V HMI running some version of MS-Windows and CIMPLICITY as part of this communication test, we don't know because you haven't told us what these tests are for.

We can try to help with the voting mismatch Diagnostic Alarms, but we would need a full-width image of the list of the alarms, including the Mark* V CDB (Control Signal Database) signal names.

Best of luck! I think you're going to need some good luck if you're doing what I presume you are doing. I worked for several years helping to develop a Mark* V HMI using a different graphical user interface (than CIMPLICITY) that can be directly connected to a GE Mark* V <C> to replace the GE operator interface (an <I> or a GE Mark* V HMI). It was NOT a simple task, and it took some very technically savvy people to do it. (It works very well; but I've lost touch with the product and whomever is now selling and supporting it.) But, again, it took several people working MANY longs days and nights, and when they encountered different PROMsets, there was always something new to be solved. It was a labor of love for two of the developers.

 

It is necessary to be precise, with poor information I have, I can tell you:
1) Check the power supply voltages on the HMI diagnostic screen.
2) Make sure the MKV is properly grounded. Please take into GE recommendations.
3) Check the network and its terminations.

Regards,