DEVolf

Windows engineering console for Fartak Control FC22AR / FC22S devices. DEVolf connects over LAN, displays device status and measurements, edits settings and protection groups, retrieves events and signals, runs EmWolf scenarios, and creates FC22 inspection reports.

Build · Features · Company file mapping · Project layout · Documentation

Build

Build targets: x64 (Python 3.11 / Qt6) and x86 (Python 3.8 / Qt5). The BeachEye DLL is compiled separately for each architecture.

Requirements

• Python 3.11 x64 for x64 builds; Python 3.8 x86 for x86 builds, plus the py launcher.

• Git, GitHub CLI and CMake on PATH.

• MSYS2 UCRT64 GCC for x64, i686 MinGW GCC for x86, and Ninja. In the MSYS2 UCRT64 terminal:

  pacman -S --needed mingw-w64-ucrt-x86_64-gcc mingw-w64-ucrt-x86_64-ninja

• A GitHub account with read access to both private company repositories:

  gh auth login
  gh auth status
  gh repo view majidnow/BeachEye
  gh repo view majidnow/wolfeye

Build command

Run from the repository root:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\build.ps1

To update both BeachEye ver_50_remaster and WolfEye master, then run the full build:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\build.ps1 -UpdateBeachEye -UpdateWolfEye

The switches update beacheye-source.json and wolfeye-source.json independently. Omitting both repeats the recorded SHAs. See guidebuild.txt for the English command reference, native-only builds and custom build options.

Outputs: Dist\DEVolf-x64.exe and Dist\DEVolf-x86.exe.

The default builds x64. To build x86:

.\build.ps1 -Architecture x86

Use an i686 MinGW GCC toolchain for x86, selected by DEVOLF_GCC_BIN or %LOCALAPPDATA%\DEVolf\Toolchains\mingw32\bin.

The script creates the selected environment when needed, installs the matching requirements, builds only BeachEye, runs all tests, packages the EXE and checks its architecture and startup. An existing runtime can be selected with -PythonExecutable. GCC/Ninja are selected explicitly. The default toolchain is C:\msys64\ucrt64\bin; use DEVOLF_GCC_BIN for a different installation.

Advanced build options

Use -PythonExecutable to select an existing Python 3.11 x64 runtime and -Wheelhouse for offline Python dependency installation. Private BeachEye access is still required.

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\build.ps1 `
  -PythonExecutable 'C:\Python311\python.exe' `
  -Wheelhouse 'D:\Wheelhouse'

Private source defaults to %LOCALAPPDATA%\DEVolf\BeachEye. To choose another cache:

$env:DEVOLF_BEACHEYE_CACHE = 'D:\PrivateBuildCache\DEVolf-BeachEye'
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\build.ps1

Normal builds use the pinned manifests. -UpdateBeachEye selects the latest BeachEye branch commit; -UpdateWolfEye selects the latest WolfEye master commit. The resolver requires majidnow/BeachEye and ver_50_remaster; alternate repository, branch and revision build options have been removed.

Private native dependency

BeachEye source is resolved through authenticated GitHub CLI into an external cache. The build verifies repository access, privacy and pinned revisions; it stops if these checks fail. Private source and generated DLLs are not tracked in this repository. The resolver uses a pristine upstream cache and never rewrites company headers, JSON conversion or serialization. Modified checkouts are rejected by resolution, CMake and the post-build check.

All relay read/write, measurements and events use BeachEye ver_50_remaster at the exact SHA in beacheye-source.json. A device reporting build 51 still uses this branch's DisablePoints(model, build) mapping; no separate revision-51 DLL is selected. FC22AR build 51 uses 410 binary and 122 analog points in a 300-byte packed BI/AI response.

Both FC22AR (auto recloser) and FC22S (sectionalizer) use the company point maps and deserializers. The C ABI exposes the compiled company source; Windows socket handling and ABI marshaling remain local integration code.

Frame transmission and reception use the protocol's two-byte length field, without a general 5 KiB payload rejection. Native requests reserve one byte for the company sequence. Firmware file chunks retain the company's MAX_DATA_SIZE - 4 partitioning. Complete measurements with a different point count are displayed by wire index (BI N, AI N, Counter N); matching profiles retain company names. Empty channels and repeated channel blocks are supported without dropping values. Relay communication uses only sequenced BeachEye TCP on port 6536. Failed connections or INFO handshakes are reported directly; Legacy TCP/HTTP and automatic fallback have been removed. Events use the company's current Event::Deserialize and SerializeSize, without ring or short-Counter formats. Signals use the company's ten-channel structure with 32 or 64 samples per channel, selected by INFO flag 0x02, at 1600 or 3200 Sa/s respectively. 32-sample devices may return fixed-size buffers; only the INFO-selected prefix is plotted. See signal decoding and diagnostics. Get ADC follows the company half-cycle channel layout in Python. BeachEye bridge ABI is 12. BeachEye remains the only company DLL used at runtime. WolfEye SIGNAL/ADC decoding, TCC calculations and AR stage rules run directly in Python, ported from wolfeye/master at the recorded SHA. wolfeye_core.dll is no longer loaded, built or packaged. INFO still selects 32 or 64 samples per cycle independently of the executable's architecture. Qt retains signal analysis, capture history and standalone viewers.

For source provenance and the direct Python ports, see the current architecture.

Features

Area	Capabilities
Connection and status	BeachEye LAN connection and INFO handshake, device identity, alarms and operating state.
Measurements and events	Revision-aware analog/binary/counter values, timestamps and 32-bit counters.
General settings	Measurement, DNP3/IEC configuration, ports, digital I/O, functions, synchronization, security and heater settings.
Protection and TCC	FC22AR/FC22S menus, four groups, UV/OV stages, IEC/ANSI curves and current bounds.
Signals and analysis	Capture history, waveform viewing, zoom/pan, RMS, phasors, harmonics and sequence quantities.
Device operations	Settings read/write, firmware/bootloader transfer and device reset.
EmWolf	EWS2 setup/projects/scenarios, digital-input transitions, result interpretation and PDF reports.
FC22 Tester	Inspection sessions, persistent form/test values, company checklist PDFs and Windows printing.

Settings use the company's original wire serializer and defaults. The Qt editor assigns typed Configure fields directly, like the company desktop, without passing through the mutating company JSON exporter. TCC calculation and AR stage rules are direct Python ports of the pinned WolfEye master source. EmWolf, FC22 Tester and user analysis/report features remain unchanged. See the current company-process audit for source provenance, corrections and the explicit remaining differences. Sampling regressions are covered in tests/test_signal_sampling.py.

The internal wolfeye package, native DLL names and schema identifiers are retained for ABI compatibility. The product name and EXE are DEVolf.

Company file mapping

Reference: company WolfEye master, commit 7e58f4af439c6fa9c9db51e4558936264401732a (checked 2026-10-20).

The complete file-by-file inventory accounts for all 60 tracked master entries, with source links, destination files and an explicit treatment for each file: retained, adapted, split, replaced, removed, external or unported.

Company source	Main DEVolf counterpart
WolfEye/src/main.cpp, include/main.h	Application entry and MainWindow.
SettingsView.cpp, SettingsView.h	General/Protection editors, schema, native mapping and numeric limits.
TCCCalculator.cpp, TCCCalculator.h	TCC calculations, editor and chart.
MeasurementsView, EventViewer, FaultViewer	Qt pages, device service, native decoding.
EmWolf.cpp, EmWolf.h	EmWolf page, EWS2 protocol and reports.
DataProvider/include, src, cJSON	Six required CRC/JSON/configuration files; unused provider/scenario/timer copies were removed. Active transport is the native adapter.
DataProvider/BeachEye submodule	Pinned dependency manifest and authenticated resolver.
Visual Studio projects, resources and ImGui helpers	PowerShell build, CMake, Qt and assets.

A counterpart identifies implementation responsibility, not a byte-identical port. The complete inventory marks partial workflows, unported LogViewer and the DNP3 Master sample, and the difference between master's BeachEye gitlink and DEVolf's revision pins.

Project layout

code/main.py              Application entry point
code/wolfeye/widgets/     Qt pages, dialogs and charts
code/wolfeye/services/    Device, protocol, analysis and report services
code/native/beacheye/     C ABI, active transport adapter and CMake build
code/native/DataProvider/ Six required CRC/JSON/configuration files
code/assets/             Branding, SVG controls and form templates
tests/                   Regression tests
docs/                    Mapping, audits, release and publication details
build.ps1                x64/x86 release build with -Architecture
build-native.ps1         Pinned ver_50_remaster native build
requirements.txt         Pinned Python dependencies
build/                   Generated intermediates and logs
Dist/                    Generated Windows EXE

Relay pages share DeviceService; the EmWolf page owns its EWS2 connection. FC22 Tester consumes the existing device state. Inspection sessions are generated under sessions/; supplied FC22AR/FC22S scenarios remain in their named scenario folders.

FC22 Test Lots

FC22 Tester uses four fixed workflow steps: Setup, Form data, Run test and Report. The test table keeps each observation beside its source and verdict; hover over the parameter or result for the exact acceptance rule. Use All measurements & test results for the complete diagnostic list. Setup exposes WI03 worksheets and shared EmWolf controls; enable Custom acceptance rules / Test Lot JSON to load or edit additional rules, including percent tolerances. Blank manual fields can be completed on paper. Form groups adapt to the window width, and test navigation stays visible while measurements scroll.

The company procedure is code/test_lots/wi03.json, transcribed from WI03 revision 00, 1403/01/25, 8 pages. It contains 38 test modes, 104 checks and 14 numeric input specifications for HMI, Keypad, Analog, Digital, Power, Base, Relay & key, Modem, AR DRV Power and LLDL. Every mode keeps its model, setup, units, source expressions and Word page references.

In FC22 Tester → Setup → WI03, select a mode and open its worksheet. Establish the displayed input/setup conditions, confirm them, and record the measurements. Applicable DUT voltage/current readings use the conversions already present in System Status (raw volts to kV, raw current divided by ten to A). Oscilloscope, multimeter and qualitative observations are recorded explicitly as manual. Frequency is entered in verified Hz; WI03 does not establish raw F ABC/F RST scaling. No stimulus amplitude calibration or automatic board commands are inferred from the procedure.

Tolerance endpoints are inclusive. Explicit X>13.0 V and 11.4<X<11.6 remain strict. The IN differential entry 2.7±3.3 V and the three Charger/Battery ranges with tolerances on their boundaries remain verbatim and require review. Where WI03 supplies no numerical acceptance limit, the program leaves the check NOT_TESTED rather than inventing a threshold. Those cases cannot automatically approve a report. The previous illustrative frequency/trip/charging limits were removed; acceptance defaults now come from this procedure.

Saving a worksheet preserves the exact rules, source identity, setup confirmation, model, units, timestamps and individual results in session.json. Applicable checklist fields use these recorded engineering-unit values and are protected from subsequent raw autofill. Manual edits invalidate the corresponding WI03 verdicts; failed, missing, changed or review-required criteria trigger the PDF warning. The original Word file is read-only source material and is not bundled or published with DEVolf. Edit/load the JSON to maintain procedure data; protocol and device connections retain their existing responsibilities.

FC22 Tester shares the existing EmWolfConnection and EWS2 protocol with the EmWolf tab. Its Setup page can connect/disconnect the board, run the current EmWolf project and open the scenario editor. Both tabs show the same connection state and endpoint. Connecting the test board and reading the FC22 DUT remain the existing separate EmWolf and DeviceService responsibilities.

Without loading a lot, incoming DUT snapshots automatically fill 22 numeric fields (phase/line voltages, currents, total powers, both frequencies and PF) and 3 status fields (AC supply, door and lockout), plus the existing device identity/software fields. While Tester is visible, its automatic-update option requests DUT measurements every two seconds through DeviceService and waits while device operations are busy. Manual reads are also available. Values use the same raw units as Measurements, with no inferred scaling or synthetic values.

Confirmed EmWolf scenario times and feedback are recorded even without a lot. The results view distinguishes MEASURED values from acceptance verdicts. Use a Test Lot to define the acceptance conditions for protection and digital tests; receiving feedback or a status bit alone does not declare those tests PASS. Serial numbers, visual inspections and measurements unavailable from the existing protocols remain manual. Session JSON records measurement sources, timestamps and confirmed EmWolf feedback. The optional external-equipment adapter is separate from the shared EmWolf board controls.

For additional custom acceptance rules, create a Test Lot or load a version-1 JSON lot. Select the DUT model and assign each test to a checklist field. The source editor uses BeachEye's point catalog, including the connected DUT's exact build when available. Offline lots accept company points from revision 50 and newer; an unavailable reading remains NOT_TESTED.

• analog, binary and counters consume the existing DeviceService snapshots. Analog and counter values are the same raw values shown in Measurements; the unit label does not convert them. Set acceptance limits in those units. The frequency source is analog.F ABC (load side: analog.F RST).
• emwolf.scenario_N.trip_time_ms consumes a confirmed trip from the Nth scenario of an EmWolf run started after selecting the lot. Time is converted to milliseconds.
• external.FIELD accepts equipment measurements through the optional Test Bench listener, or the existing external-value adapter. Start the listener explicitly and use the displayed session ID and temporary token. Its protocol is a 4-byte network-order length followed by a JSON measurement object. Each device's sequence number must increase.

Example bench object (prefix its UTF-8 JSON with the 4-byte byte length):

{"version":1,"source":"testbench","type":"measurement","device":"meter_1","sequence":1,"session_id":"CURRENT_SESSION_ID","token":"CURRENT_LISTENER_TOKEN","field":"charging_voltage","value":27.2,"unit":"V"}

Changing the lot, DUT identity or session stops the bench listener and resets its input context. Queued measurements from an earlier listener cannot verify the new context. Live readings expire after max_age_seconds (default 30); timeouts advance even when no new response arrives. EmWolf deadlines start when its run begins. Stability counts distinct received samples, not timer ticks.

Every configured test must have a verified PASS before the lot is complete. Editing an automatic field manually marks it NOT_TESTED until a fresh source measurement arrives. Generating a PDF with an incomplete lot requires acknowledging the warning; the exact rules and individual verdicts remain in session.json. All Test Lot regression tests are in the root tests/ directory and run during the normal build.

Documentation

• Complete company file mapping and DEVolf module responsibilities
• Current numeric storage limits and regression tests
• Release notes
• Public release checklist
• English build command reference