Provides the concrete node types used to access and manipulate the features of a GenICam-compliant device via a NodeMap. More...

Classes
class	peak::core::nodes::BooleanNode
	Represents a GenAPI boolean node. More...
class	peak::core::nodes::CategoryNode
	Represents a GenAPI category node. More...
class	peak::core::nodes::CommandNode
	Represents a GenAPI command node. More...
class	peak::core::nodes::EnumerationEntryNode
	Represents a GenAPI enumeration entry node. More...
class	peak::core::nodes::EnumerationNode
	Represents a GenAPI enumeration node. More...
class	peak::core::nodes::FloatNode
	Represents a GenAPI float node. More...
class	peak::core::nodes::IntegerNode
	Represents a GenAPI integer node. More...
class	peak::core::nodes::Node
	Represents a GenAPI node. More...
class	peak::core::nodes::RegisterNode
	Represents a GenAPI register node. More...
class	peak::core::nodes::StringNode
	Represents a GenAPI string node. More...

Detailed Description

Provides the concrete node types used to access and manipulate the features of a GenICam-compliant device via a NodeMap.

Node and node map behavior follows the GenICam feature model as exposed by this API.

Node Caching and Polling Concepts

Caching exists to reduce control-channel traffic and access latency for frequently queried feature values. By reusing values that are still valid according to cache and invalidation rules, applications can read dynamic feature state more efficiently while preserving correctness.

Nodes can be cacheable, depending on their XML metadata and runtime state. Use Node::IsCacheable and Node::CachingMode to inspect this behavior.

The caching mode is represented by NodeCachingMode.

Various access states are represented by NodeAccessStatus; refer to that enum for concrete values. Access status can also be cacheable. Use Node::IsAccessStatusCacheable to check this.

Invalidation dependencies still apply: when one node changes, dependent nodes can be invalidated and may require re-evaluation on next access. Use Node::InvalidatedNodes to inspect which nodes become invalid when the current node changes (directly and indirectly connected dependent nodes), and Node::InvalidatingNodes to inspect which upstream nodes can invalidate the current node (directly connected nodes only).

Typical usage is to update a controlling node, then re-read affected dependent nodes (optionally with NodeCacheUsePolicy configured to ignore cache when strict freshness is required).

Polling Time and NodeMap Polling: Some nodes provide a polling hint via Node::PollingTime. Polling is executed on node map level by NodeMap::PollNodes, which updates nodes that require polling.

The parameter of NodeMap::PollNodes is elapsed time since the previous call in milliseconds. This API does not run an internal polling thread; applications must call it explicitly.

NodeMap Polling Best Practice: Use one periodic loop per active node map and pass real elapsed milliseconds to NodeMap::PollNodes.

Practical guidance:

Keep polling active while your application displays or depends on dynamic feature state.
Choose an interval at or below the shortest relevant node polling time, but avoid over-polling.
For deterministic behavior, compute elapsed time from a monotonic clock instead of a fixed constant.

Cache Use Policy in Value and Read Calls

Most value accessors expose NodeCacheUsePolicy, for example:

These accessors use NodeCacheUsePolicy to choose whether a single read operation should use cached data or request fresh data from the device.

Classes

Detailed Description