@@ -103,10 +103,37 @@ otopcua-twincat-cli subscribe -n 192.168.1.40.1.1 -s GVL.Counter -t DInt -i 500
|
||||
|
||||
# Fall back to polling for runtimes where native notifications are constrained
|
||||
otopcua-twincat-cli subscribe -n 192.168.1.40.1.1 -s GVL.Counter -t DInt -i 500 --poll-only
|
||||
|
||||
# Coalesce bursty changes — runtime buffers up to 500 ms before dispatch
|
||||
otopcua-twincat-cli subscribe -n 192.168.1.40.1.1 -s GVL.Counter -t DInt -i 50 --max-delay-ms 500
|
||||
```
|
||||
|
||||
| Flag | Default | Purpose |
|
||||
|---|---|---|
|
||||
| `-s` / `--symbol` | **required** | Symbol path — same format as `read` |
|
||||
| `-t` / `--type` | `DInt` | IEC type (see Data types section) |
|
||||
| `-i` / `--interval-ms` | `1000` | **Cycle time** — minimum interval between change checks the PLC runtime applies |
|
||||
| `--max-delay-ms` | `0` | **Max coalescing window** — upper bound on how long the runtime buffers change events before dispatch. `0` = fire ASAP, no coalescing |
|
||||
| `--poll-only` | off | Disable native notifications, use `PollGroupEngine` instead |
|
||||
|
||||
`-i` / `--interval-ms` and `--max-delay-ms` are different things and both flow
|
||||
into the Beckhoff `NotificationSettings` ctor:
|
||||
|
||||
- **`--interval-ms`** is the *cycle*: the runtime checks for value changes at
|
||||
most this often. Smaller = lower latency, higher CPU.
|
||||
- **`--max-delay-ms`** is the *coalescing ceiling*: once a change is detected,
|
||||
the runtime can hold it for up to this long before dispatching, which lets
|
||||
it batch a burst of changes into a single callback. Default `0` means
|
||||
every detected change fires immediately — same as the pre-PR-3.1 behaviour.
|
||||
|
||||
For high-frequency signals (a counter incrementing every 10 ms PLC cycle),
|
||||
pair a small `-i` (so latency stays bounded) with a non-zero `--max-delay-ms`
|
||||
(so the OPC UA queue downstream doesn't flood). For slow signals just leave
|
||||
`--max-delay-ms` at `0`.
|
||||
|
||||
The subscribe banner announces which mechanism is in play — "ADS notification"
|
||||
or "polling" — so it's obvious in screen-recorded bug reports.
|
||||
or "polling" — and includes the `max-delay` value when set, so it's obvious
|
||||
in screen-recorded bug reports.
|
||||
|
||||
`--poll-only` polls go through the same cached-handle path as `read`, so
|
||||
repeated polls of the same symbol carry only a 4-byte handle on the wire
|
||||
|
||||
Reference in New Issue
Block a user