For modification of our frame 9E by autotune, It was necessary to move some mA inputs from q to C core. This are 3 points. Anyway, after downloading everything worked fine for a few days. This morning I was resetting DCC errors on R S and T. A few minutes after this, the extended mA input card TCCB in C core got frozen.

We also activated Modbus in I computer. I do not see any relations. Does anybody have any idea why the card gets frozen? After reboot of C it works again for a few days.

TCCA card in C is already full filled with mA inputs, also on Q.

We also experience this on the MK V of our steam turbine.

Any help will be appreciated.
[email protected]

 

carlosMKV,

Interesting that there are two (2) extremely similar threads opened on the same day that are extremely similar. The other thread is:

http://control.com/thread/1506350052

I don't have access to my Mark V Application Manual (GEH-6195), but I think you are trying to say that something is amiss with either the TCCA or the TCCB card; TBQD is an analog terminal board (generally, TB in the first two characters of a Mark V card designation refers to a terminal board (where field wires, or wires connected to field devices, terminate). Generally, TC in the first two characters of a Mark V card designation refer to an I/O card (an 8-1/2-inch by 11 inch card in one of the cores (<C>, <R>, <S>, <T>, <P>, <PD>, <CD>, <QD1> and <QD2> if so equipped--and possibly a steam turbine PLU module (again, I don't have access to my App Manual).

Both threads refer to newly assigned mA inputs working for some short period of time and then not working, requiring a re-boot of <C> processor to get them working again.

Both threads refer to recent activation of a MODBUS link on an <I> (not a GE Mark V HMI running MS-Windows and CIMPLICITY--but a <I> running IDOS, the first operator interface used with Mark V turbine control systems).

It's not clear if these two threads refer to the same site (both with GE-design Frame 9E heavy duty gas turbines...), but if it is while the fact that on the face of it it shouldn't seem like MODBUS is causing a problem it very could be that MODBUS is using one or all of the newly assigned mA input signals--requesting their status at a fast rate. And it's possible that because of the way <C> multiplexes mA inputs it's getting hung up trying to send the data as quickly as it's being requested. (Multiplexing inputs refers to the way that inputs are read. Inputs to <C> are not deemed (by GE and the card/software designers) to be critical--so the analog inputs to <C> are generally not all read at the same instant in time. Rather they are read one at a time, serially, and so there is a time delay in the update rate in the CDB (Control signal DataBase). And since the <I> may be requesting the data from the newly assigned mA inputs at a rate much faster than once-per-second, <C> might be having a hard time responding, hence the issue with the inputs "freezing.")

This is pure speculation on my part--based solely on similar (but not exactly the same) issues I have experienced before with <C> analog inputs being requested by MODBUS.

It's also very possible that the Mark V is one of the early Mark V versions (there are Mark V "A" panels; "B" panels; "Hybrid A" panels; and "Hybrid B" panels); sometimes if you run CARD_ID.EXE from a command prompt it will tell you which version of Mark V panel is being used. And the software on the PROMs of the DCC/SDCC and/or LCC/SLCC and TCCA/TCCB cards might have issues that were solved by newer revisions of PROM software. (The last two characters of the PROM P/N (Part Number) indicate the revision of the PROM software, so CB would be Major Revision 3, Minor Revision 2 (for the third and second characters of the alphabet, respectively.)

Failing all of the above, I would have to say there might be a problem with either the TCCA/TCCB card, or a problem with the MODBUS configuration. (I believe it's possible to ask for different signals via MODBUS at different rates (not Baud rates--the number of times per second), so you might try just stopping MODBUS and then waiting a couple/three days to see if the problem does not re-occur. If it does not re-occur, then you've isolated the problem to something related to MODBUS, either the signal names were not entered correctly (possibly the wrong scale type, or mis-typed signals, or the wrong register type, etc.), or the timing of the requests from the <I> is too fast for the way the information is being updated. You could then try changing the timing of the requests for those signals in MODBUS and seeing if that resolves the problem.

If it's not a MODBUS or timing issue, then it's likely a TCCA/TCCB card issue (try swapping in a new or refurbished TCCA/TCCB card), or a PROM issue (requiring updated PROMs).

That's about all I can think of. Please write back to let us know what you find!

 

CarlosMKV,

I did think of one other possibility--the jumpers for signal isolation on the TBQx card where the new mA signals were terminated. I believe the Mark V does NOT provide power for <C> mA inputs but there IS a hardware ("Berg") jumper for grounding the input loop. Some other control systems have a different grounding system, and putting the hardware jumper in will cause problems for either the Mark V, or the other control system providing the signal. (That's something I didn't suggest to be checked--to see if the input signal is frozen and not updating, which would suggest it's not a Mark V problem at all!) Sometimes, it's necessary to use a signal isolator to prevent ground loops from hampering the signal and the control system(s). Many signal isolators are self-powered.

Finally, it could be that the input signal loading of the <C> mA inputs causes the sending control system to not be able to power the loop--especially if the Mark V was "added" to an existing loop. Most loops can only handle a total of 500 ohms; without being able to look at the Signal Flow Diagrams in Appendix D of GEH-6195 I can't say for certain what the dropping resistor is in the <C> mA input loops.