# MTConnect C++ Agent configuration for the OtOpcUa integration-test fixture. # # ASCII ONLY. The Agent's config parser rejects the whole file on a non-ASCII byte -- # even inside a comment -- with a bare "Failed / Stopped at line: N" and exits. An em # dash in a comment is enough to make the fixture never start. # # The image's CMD is `/usr/bin/mtcagent run /mtconnect/config/agent.cfg`, so this file is # bind-mounted at exactly that path (see docker-compose.yml). Paths below are ABSOLUTE on # purpose: a relative `Devices` is resolved against the Agent's working directory # (/home/agent), not against this file, and would silently start an Agent with no device # model. Devices = /mtconnect/config/Devices.xml Port = 5000 ServiceName = OtOpcUaMTConnectFixture # 2^14 = 16384 observations retained. Generous on purpose: the driver's /sample pump # re-baselines through /current when its cursor falls out of the Agent's ring buffer, and # a small buffer would make the fixture exercise that recovery path on every run instead # of the steady-state streaming the suite is here to prove. BufferSize = 14 CheckpointFrequency = 1000 MaxAssets = 128 # MTConnect is a read-only source for this driver; the Agent must not accept writes. AllowPut = false SchemaVersion = 2.0 MonitorConfigFiles = false Pretty = true # The block name must equal the Device name attribute in Devices.xml (OtFixtureCnc) -- # that is how the Agent binds an adapter connection to a device. "adapter" is the compose # service name of the SHDR feeder; the Agent dials OUT to it. Adapters { OtFixtureCnc { Host = adapter Port = 7878 ReconnectInterval = 2000 } } # Log to stdout rather than a file: /mtconnect/log is an image-declared VOLUME that is # created root-owned while the Agent runs as uid 1000, so file logging fails to open. # stdout also puts adapter-connect / device-model errors straight into `docker logs`, # which is how you diagnose a fixture that comes up but reports everything UNAVAILABLE. logger_config { logging_level = info output = cout }