# 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:

```powershell
# 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:

```powershell
. 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:

```powershell
(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:

```powershell
$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:

```powershell
(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:

```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:

```powershell
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:

```powershell
(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:

```powershell
. 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:

```powershell
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:

```powershell
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:

```powershell
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.

```powershell
$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.