Pathfinder PC
5.1.36.3666
2/19/2026

Changes made for Pathfinder V5 PC's.

Added error messages 472 Clamping Beam Confirmation Failure, 473 Grippers Are Not OK, and 474 Bypass Throttle Valve Failure.

Changes made for Pathfinder V5 PC's.

All flash operations (Erase, RetrieveBoardData, SendProgram, SendLockCommand) in FlashTool.cs were being routed through the application's shared communication queue. That queue serializes all communication with the controller — regular status polling, parameter reads, etc. — so flash commands had to wait their turn behind unrelated traffic, and each flash packet would compete with other queued commands for a time slot.

The fix was to bypass the QueueManager entirely for flash operations, having FlashTool send commands directly via SendFlashCommand instead. Since firmware programming is a dedicated, exclusive operation (the controller is already in flash mode and not responding to normal commands), there's no need to share the queue. This eliminates the queuing overhead and wait times between each of the thousands of S-Record packets, dramatically speeding up the transfer.

Changes made for Pathfinder V5 PC's.

The core problem was that the code assumed master and slave would always be the same board revision (e.g., both Rev G), but in practice they can differ — like a Rev E/F master with a Rev G slave, or vice versa.

Firmware file selection: The slave programming was using Board1Type (master's board type) to select the firmware file instead of Board2Type. So if the master was Rev F and the slave was Rev G, the slave would get flashed with the Rev F firmware. Fixed by using Board2Type for the slave's firmware stream lookup.

Post-flash version check: After programming, the code compared the master's version against the slave's version and errored if they didn't match. But they're supposed to be different — Rev E/F and Rev G use different firmware files with different version numbers. Fixed by checking each controller individually against its own required firmware version (looked up from its own board type's firmware file).

Revision display: The dialogs only showed the master's revision info. Updated AvailableFlashDialog to show labeled master and slave sections (revision, current version, required version), and updated IsValidToFlash to display both "Master is Rev X" and "Slave is Rev Y" in the programming status dialog. Also added a slave validation check after RetrieveBoardData to catch board data mismatches before flashing the slave.

Changes made for Pathfinder V5 PC's.

A lot of the machine configurations that have a 5226 as the controller to use did not have rev E as one of the options as the board to use. This isn't truly a problem with so little of E's in existense, but just in case they have been added to all machine configurations that use a 5226 board. Except for ThalmannTDv1 which uses B boards.

When Pathfinder connects to Eclipse Pro, it requests the list of Delay Codes and the Halt Delay Minimum value. If the list of codes is not empty, a new button will appear in the main toolbar that launches the Record Delay dialog. If the Halt Delay Minimum parameter is greater than 0, the button will be displayed with a warning color. The run button will also launch the Record Delay dialog before allowing the machine to enter Run mode. Pathfinder will check for updated Delay Codes every five minutes.

Pathfinder can now set the number of pieces produced at once. When the last step of a sequence is completed, the quantity complete will increment by that value. A new parameter, Operator Preferences > Max Pieces per Cycle, will enable the new button if that value is greater than 1.

Changes made for Pathfinder V5 PC's.

Added the RoperElectricPartial machine configuration for installs that use most of the existing cabinet already on the Roper machine.

Changes made for Pathfinder V5 PC's.

The double folding machines have a lot of inputs so simulation mode active needed to be removed to put in clamping beam confirmation. If set to true the the signal from the new input will create a simulation task error. These machines needed it set to false:

JornsTwinmaticClosedLoopV3 JornsTwinmaticClosedLoopV2 JornsTwinmaticClosedLoop JornsHyperDriveFullSystem JornsHyperDriveFlexTwinmatic JornsHyperDriveFlex5Frame JornsHyperDriveFlex4Frame

Changes made to Pathfinder V5 PC's.

The ClampingBeamConfirmation needed to be add or set to true in some of the Hyper Drive configurations so it can be used.

JornsHyperDriveFlex5Frame IsEnabled changed from false to true JornsHyperDriveFlex4Frame IsEnabled changed from false to true JornsHyperDriveFlexTwinmatic IsEnabled changed from false to true JornsHyperDriveFullSystem New ClampingBeamConfirmation input added on pin 24, IsInverted: true, IsEnabled: true JornsHyperDriveTwinPro New ClampingBeamConfirmation input added on pin 24, IsInverted: true, IsEnabled: true

Changes made for Pathfinder V5 PC's.

Rev F: V4.04.23 Rev G: V5.00.21