mm::node::ProcessData Struct Reference

The live process-data runtime: the published image, the cross-thread exchange buffers, and per-object PDO access over them. More...

#include <process_data.h>

Collaboration diagram for mm::node::ProcessData:

Public Member Functions
bool	healthy () const
	True when an image is published and the last working counter meets the expectation.
std::optional< std::vector< uint8_t > >	readPdo (uint16_t slavePosition, uint16_t index, uint8_t subindex) const
	Reads a PDO-mapped object's current bytes from the live image. Lock-free.
bool	writePdo (uint16_t slavePosition, uint16_t index, uint8_t subindex, std::span< const uint8_t > bytes)
	Stages a PDO output object's bytes into its slot, sent on the next cycle. Lock-free.

Public Attributes
std::atomic< const ProcessImage * >	image {nullptr}
std::vector< std::shared_ptr< const ProcessImage > >	generations
std::vector< std::atomic< uint64_t > >	outputSlots
ProcessDataRing	ring
ProcessBuffer	outScratch
ProcessBuffer	inScratch
std::atomic< bool >	exchanging {false}
std::atomic< int >	lastWkc {0}
std::atomic< int >	expectedWkc {0}

Detailed Description

The live process-data runtime: the published image, the cross-thread exchange buffers, and per-object PDO access over them.

Carries the output (master→slave) and input (slave→master) images across the RT / non-RT boundary, the pointer to the currently published ProcessImage layout, and the working-counter health. DeviceManager owns one of these and drives the whole-buffer exchange each cycle; it also hands a pointer to it to every Device so a device can read and write its own PDO-mapped objects (readPdo / writePdo) without knowing how the image is stored. That single seam is what lets Device::readParameter / Device::writeParameter serve the live IO-map value while exchanging — identically from an HTTP handler or an RT task — and fall back to SDO otherwise.

Both accessors are lock-free, including writes (so an RT task can stage a setpoint without ever blocking on a non-RT writer). The output path is single-writer-per-buffer by construction: each output object owns an atomic staging slot that any number of writers store into independently, and the RT loop is the sole thread that composes those slots into the packed wire image each cycle (DeviceManager::exchangeProcessData). Composing on one thread is what makes bit-packed objects that share a byte safe without a lock — see NEXTGEN.md (Design B).

Defined in a header (rather than pimpl'd) so both device.cc and device_manager.cc can use it; the recorder ring and fixed buffers are heavy, but only those two translation units pull them in (the public device.h / device_manager.h only forward-declare it).

Member Function Documentation

healthy()

bool mm::node::ProcessData::healthy ( ) const

inline

True when an image is published and the last working counter meets the expectation.

A read of an input off a published-but-unhealthy bus would serve stale snapshot bytes (a short working counter means the driver left the prior cycle's bytes in the IOmap), so the input branch of readPdo gates on this and the caller falls back to the authoritative SDO upload. Outputs are not gated — a staging slot is always our own valid setpoint.

readPdo()

std::optional< std::vector< uint8_t > > mm::node::ProcessData::readPdo	(	uint16_t	slavePosition,
		uint16_t	index,
		uint8_t	subindex
	)		const

Reads a PDO-mapped object's current bytes from the live image. Lock-free.

Outputs come from their staging slot (our current setpoint — always valid); inputs from the newest recorded cycle (ring head()-1), gated on healthy(). Returns nullopt when no image is published, nothing has been recorded yet, the object is not PDO-mapped, or (inputs only) the bus is unhealthy — in each case the caller reads it over SDO instead. Bytes are little-endian and LSB-aligned.

writePdo()

bool mm::node::ProcessData::writePdo	(	uint16_t	slavePosition,
		uint16_t	index,
		uint8_t	subindex,
		std::span< const uint8_t >	bytes
	)

Stages a PDO output object's bytes into its slot, sent on the next cycle. Lock-free.

Returns

true if the object is output-mapped and was staged; false otherwise (no image, or the object is an input / not mapped — the caller then writes it over SDO). No health gate: staging is always safe, the value is simply sent next cycle.

Member Data Documentation

exchanging

std::atomic<bool> mm::node::ProcessData::exchanging {false}

expectedWkc

std::atomic<int> mm::node::ProcessData::expectedWkc {0}

generations

std::vector<std::shared_ptr<const ProcessImage> > mm::node::ProcessData::generations

image

std::atomic<const ProcessImage*> mm::node::ProcessData::image {nullptr}

inScratch

ProcessBuffer mm::node::ProcessData::inScratch

lastWkc

std::atomic<int> mm::node::ProcessData::lastWkc {0}

outputSlots

std::vector<std::atomic<uint64_t> > mm::node::ProcessData::outputSlots

outScratch

ProcessBuffer mm::node::ProcessData::outScratch

ring

ProcessDataRing mm::node::ProcessData::ring

---

The documentation for this struct was generated from the following files:

• libs/node/process_data.h
• libs/node/device_manager.cc