GE Mark VI Function Blocks for Gas Turbine Control Logic

A gas turbine control problem becomes easier to diagnose when engineers separate three layers: field hardware, controller application logic, and the supervisory tools used to observe and maintain both. GE Mark VI and Mark VIe systems execute application logic assembled from interconnected functional elements, but the exact block names, libraries, and hardware interfaces depend on the installed generation and project revision.

That distinction matters during an outage. A failed I/O interface or missing field signal is not repaired by changing sequencing logic. A healthy input that is rejected by a permissive, voter, timer, or state transition is not repaired by replacing another terminal board. The first task is to establish which layer stopped satisfying its contract.

Hardware carries field signals and executes the application; the function-block project defines how those signals become commands, permissives, alarms, and trips.

Start with the installed control-system generation

Mark VI and Mark VIe belong to the same control-system lineage, but they are not interchangeable platforms. Their controller, I/O, networking, and engineering-tool details differ. A drawing, backup, or replacement part must match the actual unit configuration rather than a generic “Mark VI” label used in conversation.

For Mark VIe systems, GE Vernova describes the ControlST software suite as the environment that includes ToolboxST for configuration and diagnostics, along with workstation, trending, alarm, and system-management applications. The official ControlST software suite overview is a useful reference for those roles. Classic Mark VI installations can have different tooling and revision constraints, so use the site license, installed software records, and OEM documentation for the specific unit.

When a repair requires hardware, match the complete part identity, revision, firmware expectations, terminal-board relationship, and redundancy role. Relevant inventory can be reviewed in the GE boards and turbine control collection, but compatibility must be decided from the site bill of material and manuals—not visual similarity.

Read the application by function, not by a memorized block name

A turbine project is easier to understand when its logic is grouped by engineering purpose. Exact proprietary block names may vary, while the underlying control obligations remain recognizable.

Sequencing and permissives

Start, purge, ignition, acceleration, synchronization, loading, unloading, and shutdown are state-driven processes. Each transition depends on permissives such as valve position, lube-oil condition, speed, flame, ventilation, and timing. A stalled sequence should be traced to the first unsatisfied transition condition. Forcing a downstream state hides the cause and can bypass the evidence needed for a safe repair.

Fuel and load control

Fuel demand is shaped by operating state, speed or load control, temperature limits, acceleration limits, valve characterization, and fuel-system constraints. Selectors choose the most restrictive valid demand or limit. Ramps and rate limiters prevent abrupt commands. A low final demand is therefore not necessarily a failed regulator; another limit may be correctly winning the selection.

Airflow and temperature control

Inlet guide vane scheduling and exhaust-temperature control interact with compressor operating conditions, combustion mode, ambient conditions, and load. Diagnose the measurement chain and active limit before changing a tuning constant. A biased temperature input, invalid median, or incorrect quality state can make a healthy loop appear badly tuned.

Protection and voting

Overspeed, flame, vibration, bearing temperature, combustion, and other protective functions determine whether operation may continue. Redundant channels may be selected, voted, or qualified by quality and timing logic. The operator needs to know which individual channel disagreed, which voter result became active, and whether a trip originated inside the turbine controller or in an external protection system.

Keep signal quality beside the value

A function block should not treat every numeric input as equally trustworthy. Engineering diagnostics need the raw or conditioned value, quality state, range status, last-good indication, and channel disagreement information. A failed transmitter frozen at a plausible value can be more dangerous than an obvious out-of-range signal.

Before blaming application logic, trace the signal end to end: field device, wiring and power, terminal point, I/O diagnostics, controller variable, conditioning, voter or selector, and final consumer. Compare redundant channels and historical trends. If the controller sees a different value from the operator display, identify where scaling, communication, or display processing diverges.

Use the engineering tools as evidence

GE Vernova states that the Mark VIe control ecosystem supports control, sequencing and protection, monitoring and alarming, and sequence-of-events or trip-history functions. Those records should be used together. A trend shows how values moved; the alarm list shows declared conditions; sequence-of-events data helps establish order; application monitoring shows the active path through permissives and selectors.

Capture evidence before cycling power or replacing hardware. Record controller and I/O health, active diagnostics, first-out information, time synchronization status, relevant trends, and the exact unit state. A restart can clear the symptom while erasing the chronology.

A disciplined diagnostic workflow

1. Define the failed obligation

Describe what the system did not do: a start transition did not complete, fuel demand remained limited, a channel was rejected, or a trip output operated. Avoid beginning with a presumed failed part.

2. Find the first decisive condition

Follow the application from the final command or state backward through selectors, permissives, timers, and quality logic. Identify the first upstream condition that explains the result. Confirm its source rather than overriding it.

3. Prove the hardware path

Use I/O diagnostics and independent measurement where safe. Check power, wiring, channel configuration, terminal hardware, network health, and redundancy status. For vibration signals, include the external monitor and probe chain where applicable; related components can be reviewed in the Bently Nevada collection.

4. Compare against the controlled baseline

Confirm application version, controller configuration, library revision, and downloaded state against the approved backup. An undocumented difference is a configuration-management problem even if the turbine currently runs.

5. Test recovery and failure behavior

After repair, verify normal operation and the relevant abnormal condition. Prove channel-quality handling, redundancy transfer, alarm annunciation, sequence timing, trip reset rules, and operator visibility. A cleared alarm alone is not an acceptance test.

Changes require outage-grade governance

Application changes can affect combustion, rotating equipment, protective action, emissions, and personnel risk. Use authorized access, an approved change package, OEM or qualified engineering review, backups, peer checking, simulation or offline review where available, and a documented rollback plan. Never import logic from another frame or unit merely because the block diagram looks familiar; fuel system, instrumentation, options, and site modifications may differ.

The practical editorial view is that a “function-block reference” is most valuable as a map of responsibilities, not a universal catalog of proprietary names. Engineers who understand sequencing, limiting, voting, signal quality, and protection boundaries can find the decisive evidence in the site project. Engineers who memorize a block label without verifying the installed revision risk fixing the wrong layer of the system.