ge-aerospace/pxe-server
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Runbook for the MTConnect follow-up work

Browse Source 
The rename fix only changes what future renumbers do. Nine bays are already in
the state it prevents, the 3.25.3 adapter is staged but not on the SFLD share,
and two questions - whether DMG Mori needs a bundle at all, and whether the v2
manifest ever received the MTConnect entries - are unanswered.

All of it needs a machine the dev box cannot reach, so it is written as steps
to follow rather than something to run here: exact hashes to check before
copying, per-bay numbers from the hostname map, verification after each change,
and rollback for the share copy.

Notes the two things not proven on real hardware: that stopping the Makino
Adapter Manager keeps it from rewriting config on shutdown, and that the four
Fanuc bays with no agent device name are a different fault that a rename would
not fix.
This commit is contained in:
cproudlock
2026-08-11 14:44:08 -04:00
parent 0d9c4fdac4
commit cc20501e2e
1 changed files with 233 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

233
docs/mtconnect-followup-runbook.md Normal file
View File

@@ -0,0 +1,233 @@
# 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:
```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.
| PC | machine number |
|---|---|
| `G5W5V7V3ESF` | 7502 |
| `G4H8KF33ESF` | 7506 |
**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 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:
```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
| 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:
```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 |
|---|---|
| WJ-7401 | `G1KDN7X2ESF` |
| WJ-7402 | `G1KCR7X2ESF` |
| WJ-7403 | `G1HYK7X2ESF` |
| WJ-7404 | `G1HGQ7X2ESF` |
| WJ-7405 | `G1KLM7X2ESF` |
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.
---
## 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.