Joseph Doherty
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>