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.

---

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.

PC	machine number
G5W5V7V3ESF	7502
G4H8KF33ESF	7506

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 map column is the authoritative number:

PC	adapter says	agent says	correct number
G9N2JNZ3ESF	4007	7801	7801
GG1J98Y3ESF	3031	7804	7804
GC7ZN7V3ESF	2005	2006	2005 (per hostname map - confirm at the bay)

GC7ZN7V3ESF is the one to be careful with: 2005 and 2006 are a Hwacheon dual-spindle pair sharing a PC, and the map says 2005 while the agent says 2006. Check the machine plate 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

PC	adapter says	hostname map says
GJBJC724ESF	4007	2013
G7QLY5X3ESF	3126	7606
G6JLMSZ2ESF	4002	4002
GB07T5X3ESF	3115	2001

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
WJ-7401	G1KDN7X2ESF
WJ-7402	G1KCR7X2ESF
WJ-7403	G1HYK7X2ESF
WJ-7404	G1HGQ7X2ESF
WJ-7405	G1KLM7X2ESF

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.

---

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.