Dynamic variables

Path: TestServer / Dynamic

Thirteen read-only variables whose values change over time. The canonical test surface for subscriptions and monitored items.

All accessLevel = CurrentRead. Writes are rejected.

Counters

Use cases:

• Counter — basic subscription verification (1 notification/sec).
• FastCounter — sampling-interval / publishing-interval ratio tests. With publishingInterval=200ms, expect every-other update.
• SlowCounter — keep-alive and long-publishing-interval tests.

Random values

Useful for:

• Verifying every notification carries a different value (deadband-vs-no-deadband tests).
• Stressing the encoder with frequent String allocations (RandomString).

Waveforms

Waveforms are written to the address space by the 500 ms timer in DynamicBuilder.cs; they are not recomputed on read. Each read returns whatever value the last tick wrote. The deterministic period for every waveform is 10 s — the timer ticks twice per second, sampling the formula and pushing the new value into the node, so subscriptions with shorter samplingInterval than 500 ms will still only see two distinct values per second.

Timestamps

Timestamp is not recomputed per read — it is refreshed by the 1 s timer like the counters. Two reads less than ~1 s apart will typically see the same value. Useful to verify that:

• sourceTimestamp in the DataValue tracks the value (the server sets it).
• The value visibly progresses across the second boundary.

Status cycling

StatusVariable is not a deterministic three-state cycle — every tick draws independently from the three top-level status codes. Across a long enough window you will see all three, but not in a fixed order. Use it to verify your client interprets:

• Good (0x00xxxxxx) — normal value
• Bad (0x80xxxxxx) — error
• Uncertain (0x40xxxxxx) — value may be stale / unreliable

Useful for testing data-change triggers with DataChangeTrigger = StatusValue vs Status vs Value — each filter produces a different notification count.

Nullable value

Tests how your client handles values that intermittently have no data. The choice is probabilistic, not deterministic alternation — over a long enough sample you should see ~1 Bad_NoData per 5 updates. When status is Bad_NoData the value field is left at whatever the previous tick wrote — your client should treat it as absent rather than as a real number.

Subscription test recipes

Basic 1-Hz subscription

subscribe(publishingInterval=1000)
monitor(Dynamic/Counter, samplingInterval=1000)
→ expect 1 notification/sec, value incrementing

Fast subscription

subscribe(publishingInterval=200)
monitor(Dynamic/FastCounter, samplingInterval=100)
→ expect ~5 notifications/sec

Deadband

subscribe(publishingInterval=500)
monitor(Dynamic/SineWave, samplingInterval=200,
        filter = DataChangeFilter(deadband=Absolute, value=0.5))
→ notifications only when |Δvalue| > 0.5
→ over a 10 s period (one cycle), expect ~4 notifications

Status-only trigger

monitor(Dynamic/StatusVariable, filter = DataChangeFilter(trigger=Status))
→ notification only when status code changes (~every 3 s)

Compare to trigger=StatusValue (every value or status change) and trigger=Value (only value changes — fewer notifications).

Note on update intervals

The FastCounter (100 ms) is the most aggressive cadence in the suite. For higher rates, fork and adjust DynamicBuilder.cs — see Customization.

Where to read next

• Events — event-style notifications.
• Historical data — recorded time-series.
• Subscription and method tests — full test recipes.