ToolboxST is the core engineering workstation software within the GE Vernova ControlST suite, designed for the Mark VIe turbine control system. It handles a range of functions, including system configuration, diagnostics, online downloads, and data restoration. For control engineers, proficiency in ToolboxST is the difference between merely observing an alarm and being able to systematically trace the root cause—navigating through the IONet topology, assessing the health status of I/O packs, and reviewing configuration records. The insights and analyses presented in this article are for reference purposes only. Please note that this information is provided for guidance; for specific technical support, consult with a qualified professional engineer.

ToolboxST Positioning and Connection Paths

ToolboxST is not an isolated diagnostic tool; rather, it serves as an engineering gateway integrated into the same software ecosystem as the Mark VIe controllers, I/O packs, and the WorkstationST alarm server. Its interface is structured around two primary levels: the System Editor and the Component Editor. The System Editor manages the devices and network topology of the entire system, while double-clicking a controller opens the Component Editor, where the “Hardware” tab provides a tree-view breakdown of I/O packs, terminal boards, and redundancy configurations. The interface is anchored by three key components: the Tree View (for navigating the component hierarchy), the Property Editor (for editing parameters of selected objects), and the Summary View (which provides a graphical representation of network connectivity).

The preferred method for connecting to a Mark VIe system is via Ethernet. The workstation must be configured on the same subnet as the controller. In ToolboxST, navigate to Controller → Communication → Connect, select “Ethernet,” and enter the appropriate IP address and port to establish an online connection. If Ethernet is unavailable, an RS-232 serial connection can serve as an alternative, using the following settings: 9600 baud, 8 data bits, no parity, 1 stop bit, and no flow control. It should be noted that serial connections are generally intended only for initial IP configuration or emergency access; once an IP address is established, all subsequent configuration and diagnostic tasks should be performed via Ethernet. Layered Interpretation of Diagnostic Information

Diagnostic output in ToolboxST is not merely a flat list of alarms; rather, it is a structured information system organized into three levels: I/O Pack, Module, and Component. The “I/O Diagnostic Viewer”—accessible via the “Summary” tab—serves as the primary diagnostic entry point. By right-clicking an I/O pack or terminal board and selecting “Troubleshoot and Status,” users can view fault logs, version information, and diagnostic communication data for that specific unit. Symbols within the tree view carry distinct meanings: red indicates a link anomaly, yellow signifies an active alarm, an information icon denotes an inactive alarm, and a lack of any such marker indicates a normal state. Hovering the cursor over an item reveals detailed explanations—a feature particularly useful during on-site troubleshooting.

Diagnostic reports are an often-underestimated resource. ToolboxST can generate four types of reports—I/O Module Fault Report, Revision Report, Communication Report, and Hardware Report—each containing configuration or diagnostic details specific to the relevant modules. When replacing modules or comparing versions, the Revision and Hardware reports are far more valuable than manually checking alarms screen by screen. Furthermore, the “Compare Parameters” function allows users to perform a hierarchical comparison between the configuration currently stored in the controller and the values ​​defined in the ToolboxST project before downloading new parameters. This is crucial for preventing “ripple effects,” where changing a single parameter inadvertently alters a broader range of logic.

An important diagnostic distinction to note is that communication-related diagnostics generated by ToolboxST itself (such as “unhealthy link” or “cannot retrieve diagnostics information”) are not reported to the WorkstationST Alarm Viewer. Consequently, if an operator’s HMI appears normal while ToolboxST indicates that an I/O pack is disconnected, the root cause likely lies at the engineering connection layer—for instance, the I/O pack may have failed to complete its startup, a configuration file might be missing, only one network is connected in a dual-network configuration, a terminal board barcode may have been entered incorrectly, or the configuration may not yet have been downloaded to the controller. When troubleshooting such issues, one should first verify the communication between ToolboxST and the controller, and then systematically confirm that the hardware configuration matches the actual physical installation.

Module Replacement: Essential Safety Prerequisites in ToolboxST

While Mark VIe I/O packs support “hot-swapping,” this capability does not mean they can be removed or inserted at any time without following proper procedures. Before addressing a physical module, two verifications must be completed within ToolboxST. First, check the health of the IONet ring network by navigating to Device → Component → IONet Status. All nodes should show a green status with both ports indicating “Link Up,” the frame error counter should be below 100 frames per minute, and all UCVE controllers must be “In Sync.” A yellow ring status indicates that redundancy has been lost; replacing a module under these conditions would expose the system to the risk of a single-point failure. Second, use the “Force I/O to last value” function in ToolboxST to freeze outputs, preventing signal fluctuations during removal that could otherwise trigger protective actions.

Once these prerequisites are met, the replacement process itself is relatively straightforward: remove the faulty node, insert the replacement unit, download the configuration to register the new MAC address, and finally, verify that the real-time readings are within ±1% of the actual process values. While the IONet automatically reroutes within approximately 200 ms of a module’s removal, this does not negate the need to confirm the restoration of the ring network. After the replacement, you must re-examine the IONet Status to ensure the integrity of the ring network has been restored; otherwise, the system will continue to operate without redundancy. For vibration-related channels, the affected channels must also be placed in “bypass” mode via the Bently Nevada 3500 rack interface before replacement, and protection must be restored only after the signals have been verified.

Engineering Logic for Configuration Backup and Recovery

In ToolboxST, “backup” is not merely a single-button operation, but a data preservation strategy comprising three distinct processes: upload, download, and controller replication. An “upload” transfers configuration data from the controller back to the workstation, while a “download” writes modified configuration data to the controller. Both operations require a functional communication link and version compatibility. Furthermore, before a download, the system must be in an “IDLE” or “CGG” state—never in “RUN” or “SEQ” mode. Because a download overwrites the entire controller configuration, and an incorrect configuration could lead to severe consequences—such as turbine overspeed—verifying the backup prior to a download is mandatory, not optional.

The “.m6b” file serves as the primary container for engineering configurations in ToolboxST. When version mismatches occur between multiple workstations and a single controller, the recommended method to restore consistency is to use the `.m6b` file from a workstation showing an “Equal” status as the reference. Replace the mismatched files on other workstations with this reference file, then reconnect and verify the status. Recovery following a controller hardware failure involves replacing the UCSB (Universal Controller System Base) and executing a backup/restore procedure: if possible, back up the NAND flash from the original UCSB, replace the hardware, and use ToolboxST to restore the controlled configuration. A subsequent download may be required to return the controller to an active control state. The Controller Setup Wizard can also guide the recovery process; however, the preparation of recovery media and the interpretation of status indicators (a solid green light signifies an ongoing recovery, while a flashing green light indicates a failure) must be strictly coordinated with the hardware replacement steps.

Q: If ToolboxST fails to connect to a Mark VIe controller, what should be checked first?

Verify the physical layer and network parameters before repeatedly attempting to connect via the software. Check whether the workstation and controller IP addresses are on the same subnet, ensure that the firewall allows traffic on TCP port 18245, and confirm that the Ethernet cables and switch ports are functioning correctly—these three checks cover the majority of connection failure scenarios. If the device is completely unreachable via Ethernet, you can perform an initial IP configuration using the COM1 serial port with an RJ45-to-DB9 adapter, then switch back to Ethernet. If you still cannot retrieve diagnostic information after establishing a connection, verify that the Type, HW Form, Bar Code, and physical location in the I/O pack configuration match the actual hardware; if necessary, perform a “Build” and download the parameters to the I/O pack.

Q: Can ToolboxST be used for troubleshooting without being in an “online” state?

Some tasks can be performed offline, but core diagnostic functions require an online connection. The I/O Diagnostic Viewer, for instance, explicitly requires an online connection to display real-time diagnostic data, whereas reporting functions are more flexible. In an offline state, ToolboxST is primarily useful for configuration review—such as verifying that the IONet topology, module parameters, redundancy settings, and EGD configurations align with expectations—or for using the “Compare Parameters” feature to contrast the current project configuration against a known, verified backup. However, true “fault diagnostics”—such as assessing the health of I/O packet links, reading the current alarm status of modules, or verifying whether the controller is “In Sync”—can only be performed once an online connection has been established. Therefore, the standard procedure for field troubleshooting should be to first restore communication between ToolboxST and the controller, and then access the diagnostic functions, rather than attempting to infer the status of the hardware while working in an offline project.