pxe-server/docs/mtconnect-followup-runbook.md

MTConnect follow-up runbook

Written 2026-08-11. Everything here needs a machine this box cannot reach - the SFLD share, the middle-man PC, or a shopfloor bay - so it is yours to run.

Work in the order given. Part 1 changes what future installs get; parts 2 and 3 fix bays that are already wrong; parts 4 and 5 are questions to answer before any more code is written.

Identify every bay by machine number

The machine number is the only identifier that stays put. A PC gets replaced or re-imaged and its name changes; the machine it sits at does not. Both machine-to-PC sources used to build this document are point-in-time snapshots and will already have drifted.

Every PC name below came from mtconnect-hostname-machine-map.csv (12 June), the Shop Floor PC Name column of West Jefferson_Machines.csv, or the variant captures. Treat them as "this is where the fault was last seen" - useful for finding the bay, never for deciding what to write into it.

The bay knows its own number. In order of authority:

# 1. eDNC registry - what GE-Enforce trusts post-imaging
(Get-ItemProperty 'HKLM:\SOFTWARE\WOW6432Node\GE Aircraft Engines\DNC\General' -Name MachineNo).MachineNo
# 2. the enrollment file imaging writes
Get-Content C:\Enrollment\machine-number.txt
# 3. UDC
(Get-Content C:\ProgramData\UDC\udc_settings.json -Raw | ConvertFrom-Json).GeneralSettings.MachineNumber

Or dot-source the lib and ask for both at once:

. C:\GE Aerospace\lib\Update-MachineNumber.ps1
Get-CurrentMachineNumber      # @{ Udc = ...; Ednc = ... }

ShopDB is the live PC-to-machine record, maintained by the collector rather than by hand, so it beats any CSV:

https://tsgwp00525.wjs.geaerospace.net/shopdb/api/computers/by-hostname/<HOSTNAME>

If those disagree with each other, or with the machine plate, stop and resolve that first - a rename applied to the wrong number is worse than the mismatch you started with.

---

Part 1. Push the Fanuc adapter 3.25.3 to the SFLD share

The staged bundle here is already on 3.25.3.0 (sha256 starts 6e46dcd51affa9e0). The live share is not. Until this is copied, new installs still get 3.23.0.0.

1.1 From the middle-man PC, with Z: on the dev share:

Z:\mtconnect-bundles\fanuc\Adapter\

should contain FanucCppAdapterWinX64.exe at 3,369,984 bytes. Confirm before copying:

(Get-Item Z:\mtconnect-bundles\fanuc\Adapter\FanucCppAdapterWinX64.exe).Length
(Get-FileHash Z:\mtconnect-bundles\fanuc\Adapter\FanucCppAdapterWinX64.exe -Algorithm SHA256).Hash.Substring(0,16)
# expect 3369984 and 6E46DCD51AFFA9E0

1.2 Back up what is on the share now, then copy the three files:

$share = '\\tsgwp00525.wjs.geaerospace.net\shared\dt\shopfloor\main\machineapps\mtconnect-bundles\fanuc\Adapter'
Copy-Item $share\FanucCppAdapterWinX64.exe "$share\..\FanucCppAdapterWinX64-3.23.0-replaced-$(Get-Date -f yyyyMMdd).exe"
Copy-Item Z:\mtconnect-bundles\fanuc\Adapter\FanucCppAdapterWinX64.exe $share -Force
Copy-Item Z:\mtconnect-bundles\fanuc\Adapter\Fwlib64.dll  $share -Force
Copy-Item Z:\mtconnect-bundles\fanuc\Adapter\fwlibe64.dll $share -Force

1.3 Verify on the share:

(Get-FileHash $share\FanucCppAdapterWinX64.exe -Algorithm SHA256).Hash.Substring(0,16)   # 6E46DCD51AFFA9E0

adapter.xml is deliberately NOT copied. The config vocabulary is identical between 3.23 and 3.25.3, and the share's copy carries site settings.

Rollback: copy the -3.23.0-replaced- file back over FanucCppAdapterWinX64.exe.

---

Part 2. Fix the two Makino bays

Both have the agent on the machine number and the other three files still on MAKINO-1. The fixed Update-MachineNumber.ps1 converges them.

machine	PC when captured	confirm at the bay
7502	G5W5V7V3ESF	eDNC reg / enrollment file / plate
7506	G4H8KF33ESF	eDNC reg / enrollment file / plate

Find the current PC for a machine number in ShopDB rather than trusting the name above; if the PC was replaced, the new one may never have had the bad rename applied, in which case check its four files before doing anything.

2.1 On the bay, elevated PowerShell:

. C:\GE Aerospace\lib\Update-MachineNumber.ps1     # or wherever the lib landed
$r = Update-MTConnectVariantName -NewNumber '7502' `
      -Root 'C:\Makino-MTConnect' `
      -Targets @(
        @{ Path='Agent\Devices.xml';        Kind='attr' },
        @{ Path='Agent\Devices.EDM.xml';    Kind='attr' },
        @{ Path='Data\AdapterDataFile.xml'; Kind='name' },
        @{ Path='Agent\Agent.cfg';          Kind='cfg'  }
      ) `
      -Services @('Makino Adapter Manager','Makino MTConnect Agent')
$r.Updated; $r.Errors

Use the bay's own number - do not paste 7502 onto 7506.

2.2 Verify all four agree, and nothing still says MAKINO:

Select-String -Path C:\Makino-MTConnect\Agent\Devices.xml,`
                    C:\Makino-MTConnect\Agent\Devices.EDM.xml,`
                    C:\Makino-MTConnect\Data\AdapterDataFile.xml,`
                    C:\Makino-MTConnect\Agent\Agent.cfg `
             -Pattern 'MAKINO-\d+|7502'

2.3 Confirm it is serving:

(Invoke-WebRequest http://localhost:5000/current -UseBasicParsing).Content -match '<MTConnectDevices'

Watch for: the vendor guide says the Adapter Manager rewrites its whole configuration from memory when it stops. The function stops it first, but this has never been proven on real hardware. If the names revert after a reboot, stop here and tell me - that changes the approach.

---

Part 3. Fix the seven Fanuc bays

The agent and the adapter disagree. Three have a correct agent and a stale adapter; four have no agent device name at all and need looking at before any rename (Part 4).

Rename these three. The "correct number" column is what the June map said - it is a starting point, not authority. Confirm from the bay itself (see the note at the top) before running anything:

machine (per map)	adapter says	agent says	PC when captured
7801	4007	7801	G9N2JNZ3ESF
7804	3031	7804	GG1J98Y3ESF
2005 or 2006	2005	2006	GC7ZN7V3ESF

GC7ZN7V3ESF is the one to be careful with: 2005 and 2006 are a Hwacheon dual-spindle pair sharing a PC, so two machines legitimately answer to one hostname and the map and the agent disagree about which. Read the machine plate and the eDNC registry before running it.

3.1 On the bay, elevated:

. C:\GE Aerospace\lib\Update-MachineNumber.ps1
$r = Update-MTConnectVariantName -NewNumber '7801' `
      -Root 'C:\MTConnect' `
      -Targets @(
        @{ Path='Agent\devices.xml';   Kind='attr' },
        @{ Path='Adapter\devices.xml'; Kind='attr' },
        @{ Path='Adapter\adapter.xml'; Kind='elem' }
      ) `
      -Services @('MTConnect Adapter Fanuc','MTConnect Agent Fanuc')
$r.Updated; $r.Errors

3.2 Verify the three files agree:

Select-String -Path C:\MTConnect\Agent\devices.xml,C:\MTConnect\Adapter\devices.xml `
              -Pattern 'name="[^"]+"' | Select-Object -First 2
Select-String -Path C:\MTConnect\Adapter\adapter.xml -Pattern '<Device(Name|ID|UUID)>[^<]+'

All should read the same number. Then the HTTP probe as in 2.3 (port 5000).

---

Part 4. Four Fanuc bays with no agent device name

machine (per map)	adapter says	PC when captured
2013	4007	GJBJC724ESF
7606	3126	G7QLY5X3ESF
4002	4002	G6JLMSZ2ESF
2001	3115	GB07T5X3ESF

These are not a rename problem - the agent's devices.xml has no <Device name=...> at all, so the agent has nothing to serve. Do NOT run Part 3 on them.

On each, collect and send back:

Get-Service 'MTConnect*' | Select-Object Name,Status,StartType
Get-Content C:\MTConnect\Agent\devices.xml -TotalCount 20
Test-Path C:\MTConnect\Agent\devices.xml
(Invoke-WebRequest http://localhost:5000/current -UseBasicParsing -TimeoutSec 5).StatusCode
Get-Content C:\MTConnect\Agent\agent.log -Tail 30

Note three of the four also disagree with the hostname map on the number (4007 vs 2013, 3126 vs 7606, 3115 vs 2001), so these bays may have been re-purposed without a full reconfigure.

---

Part 5. Two questions to settle

5.1 DMG Mori - do they need a bundle at all?

Five machines, all flagged 1,2,3 in the machine list, no bundle among the five we ship, and no captured variant. Their controllers are DMG Mori F31i A5/B5 - Fanuc 31i underneath - so the Fanuc adapter may already serve them.

machine	PC per the machine list
WJ-7401	G1KDN7X2ESF
WJ-7402	G1KCR7X2ESF
WJ-7403	G1HYK7X2ESF
WJ-7404	G1HGQ7X2ESF
WJ-7405	G1KLM7X2ESF

Those names come from the Shop Floor PC Name column of the OneDrive machine list and are subject to the same staleness - look the machine up in ShopDB for the PC that is actually on it today.

On any one of them:

Get-Service | Where-Object { $_.Name -match 'MTConnect|Makino|Coordinator' } |
    Select-Object Name,Status,StartType
Get-ChildItem C:\ -Directory | Where-Object Name -match 'MTConnect|DMG|Coordinator'
(Invoke-WebRequest http://localhost:5000/current -UseBasicParsing -TimeoutSec 5).StatusCode

If they run the Fanuc bundle already, no new variant is needed and the DMG Coordinator MSI in the OneDrive zip can be ignored. If they collect some other way, or not at all, that is the answer to whether a sixth bundle is worth building.

5.2 Does the live v2 manifest carry the MTConnect entries?

You are on v2. The concern is that the MTConnect entries were left behind in the dead v1 manifest, in which case v2 bays are not getting MTConnect from the manifest engine at all.

$m = Get-Content '\\tsgwp00525.wjs.geaerospace.net\shared\dt\shopfloor\main\machineapps\machineapps-manifest.json' -Raw | ConvertFrom-Json
$m.Applications.Count
$m.Applications | ForEach-Object { $_.Name }

Expect 8 applications, five of them MTConnect (fanuc, okuma, edncStandard, edncDualSpindle, makino). Anything less and the missing ones never made it to v2.

---

A note on the CSVs

Neither machine-to-PC list will age well: mtconnect-hostname-machine-map.csv (12 June) and the Shop Floor PC Name column in West Jefferson_Machines.csv are both hand-built snapshots, and every PC swap silently invalidates a row.

ShopDB now maintains the PC-to-machine link from collector reports, so it corrects itself as bays are re-imaged. Anything that needs to go from a machine number to "which PC is on it today" should ask ShopDB; if a CSV is still wanted for offline use, generate it from ShopDB rather than editing it by hand.

What I still owe you

• Auto-detection of controller and variant for a new machine. The inputs exist (mtconnect-bay-config.csv has controller IP and FOCAS port per machine, the machine list has the controller model, the collector already knows the machine number at imaging time) - design pending.
• The code fix is committed and pushed as 0d9c4fd on pxe-webapp-redesign. It changes future renames only; it does not reach out and fix these bays.