worker: document MXAccess Toolkit alarm-API gap (A.2 follow-up) #114

2026-04-30T21:30:56-04:00

dohertj2 commented

2026-04-30 21:30:56 -04:00

Summary

Dev-rig discovery: the MXAccess COM Toolkit installed at C:\Program Files (x86)\ArchestrA\Framework\Bin\ArchestrA.MXAccess.dll does not expose any alarm-event family. Reflection enumeration of the assembly confirms ILMXProxyServerEvents and ILMXProxyServerEvents2 only carry OnDataChange, OnWriteComplete, OperationComplete, and OnBufferedDataChange — no IAlarmEventSink, no Alarms collection, no OnAlarmTransition.

AVEVA's separate alarm-subscription managed assemblies (aaAlarmManagedClient.dll under InTouch\ViewAppFramework\Content\MA\ and ArchestrAAlarmsAndEvents.SDK.Common.dll under Wonderware\Historian\x64\) exist on this box but are x64-only — incompatible with the worker's x86 bitness, which is the bitness constraint the mxaccessgw architecture exists to isolate in the first place.

This PR replaces the speculative "TBD pin during dev-rig validation" comment in MxAccessAlarmEventSink with the actual finding plus the two operator-facing paths forward:

Stay on the value-driven sub-attribute path (current production behaviour). Operator-comment fidelity is the only v1 regression.
Add an x64 alarm-helper sub-process alongside the worker that loads aaAlarmManagedClient and forwards transitions over a small named-pipe IPC. Recovers full v1 fidelity but adds operational complexity.

Until that decision resolves, the sink's Attach is a no-op and lmxopcua-side AlarmConditionService keeps the sub-attribute synthesis active.

Test plan

Worker builds clean (no functional change)
No new tests — pure documentation update

## Summary **Dev-rig discovery**: the MXAccess COM Toolkit installed at `C:\Program Files (x86)\ArchestrA\Framework\Bin\ArchestrA.MXAccess.dll` does not expose any alarm-event family. Reflection enumeration of the assembly confirms `ILMXProxyServerEvents` and `ILMXProxyServerEvents2` only carry `OnDataChange`, `OnWriteComplete`, `OperationComplete`, and `OnBufferedDataChange` — no `IAlarmEventSink`, no `Alarms` collection, no `OnAlarmTransition`. AVEVA's separate alarm-subscription managed assemblies (`aaAlarmManagedClient.dll` under `InTouch\ViewAppFramework\Content\MA\` and `ArchestrAAlarmsAndEvents.SDK.Common.dll` under `Wonderware\Historian\x64\`) exist on this box but are **x64-only** — incompatible with the worker's x86 bitness, which is the bitness constraint the mxaccessgw architecture exists to isolate in the first place. This PR replaces the speculative "TBD pin during dev-rig validation" comment in `MxAccessAlarmEventSink` with the actual finding plus the two operator-facing paths forward: 1. **Stay on the value-driven sub-attribute path** (current production behaviour). Operator-comment fidelity is the only v1 regression. 2. **Add an x64 alarm-helper sub-process** alongside the worker that loads `aaAlarmManagedClient` and forwards transitions over a small named-pipe IPC. Recovers full v1 fidelity but adds operational complexity. Until that decision resolves, the sink's `Attach` is a no-op and lmxopcua-side `AlarmConditionService` keeps the sub-attribute synthesis active. ## Test plan - [x] Worker builds clean (no functional change) - [x] No new tests — pure documentation update

dohertj2 added 1 commit 2026-04-30 21:30:57 -04:00

worker: document MXAccess Toolkit alarm-API gap (A.2 follow-up) 4e933802a7

PR A.2 ship-pin discovery: the MXAccess COM Toolkit installed at
C:\Program Files (x86)\ArchestrA\Framework\Bin\ArchestrA.MXAccess.dll
does not expose any alarm-event family. Reflection enumeration of
the assembly confirms ILMXProxyServerEvents and
ILMXProxyServerEvents2 only carry OnDataChange, OnWriteComplete,
OperationComplete, and OnBufferedDataChange — no IAlarmEventSink,
no Alarms collection, no OnAlarmTransition.

AVEVA's separate alarm-subscription managed assemblies
(aaAlarmManagedClient.dll under InTouch\ViewAppFramework\Content\MA\
and ArchestrAAlarmsAndEvents.SDK.Common.dll under
Wonderware\Historian\x64\) exist on this box but are x64-only —
incompatible with the worker's x86 bitness, which is the bitness
constraint the mxaccessgw architecture exists to isolate in the
first place.

This commit replaces the speculative "TBD pin during dev-rig
validation" comment in MxAccessAlarmEventSink with the actual
finding plus the two operator-facing paths forward:

1. Stay on the value-driven sub-attribute path (current production
   behaviour). lmxopcua's AlarmConditionService already synthesizes
   Part 9 transitions from the four MXAccess sub-attributes.
   Operator-comment fidelity is the only v1 regression.

2. Add an x64 alarm-helper sub-process alongside the worker that
   loads aaAlarmManagedClient and forwards transitions to the
   worker over a small named-pipe IPC. Recovers full v1 fidelity
   but adds operational complexity.

Until that decision resolves, the sink's Attach is a no-op, the
worker continues to function for data subscriptions, and
lmxopcua-side AlarmConditionService keeps the sub-attribute
synthesis active.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

dohertj2 merged commit e030661c1b into main

2026-04-30 21:30:59 -04:00

dohertj2 deleted branch track-a2-followup-com-api-finding

2026-04-30 21:31:00 -04:00

dohertj2 referenced this issue from a commit

2026-04-30 21:31:00 -04:00

Merge pull request 'worker: document MXAccess Toolkit alarm-API gap (A.2 follow-up)' (#114) from track-a2-followup-com-api-finding into main

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dohertj2/mxaccessgw#114