Machine state and alarms from an MTConnect agent right in the chat

An MTConnect agent usually sits on the site's network next to the machines, so the gateway reaches it: a program installed on a computer on the same network. The gateway is added on the Gateways tab and assigned to the connection. The connection takes the agent address, for example http://10.0.12.5:5000, and a device name if needed. While there is no link outside, the gateway keeps the data on disk.

The gateway reads the agent the way the standard's clients do: /probe gives the device model and every DataItem becomes a tag, /current gives the present, then /sample page by page from nextSequence. Each observation is read exactly once, with the agent's time. If observations have left the agent's ring buffer, the gateway reads /current again: intermediate values are lost, the present is not. An agent restart with a new instanceId reads the model again.

The gateway sends the agent only three GET requests: probe, current and sample. PUT and POST, an adapter's way of writing to the agent, are not used by the driver, so the agent receives nothing from the gateway and the machine is not controlled through it. CONDITION items become alarms at the Warning or Fault level; MTConnect has no acknowledgement, and the gateway does not pretend otherwise.

Polling waits the Scan interval (1000 ms by default) between requests, and none while the agent still has unread observations. A request that does not finish within the Timeout ends the round, and the gateway starts again from the position it remembered, also after its own restart. The machine state word comes from EXECUTION by the same rules as for FANUC controls over FOCAS, so one control reads the same by either path.