cia402_control.h File Reference

CiA402 drive control by bus position — resolve, bind a view, run one operation. More...

#include <chrono>
#include <cstdint>
#include <expected>
#include <string>
#include "node/cia402.h"
#include "node/cia402_drive.h"
#include "node/device_manager.h"

Include dependency graph for cia402_control.h:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Namespaces
namespace	mm
namespace	mm::node

Functions
std::expected< Cia402Status, std::string >	mm::node::cia402Status (DeviceManager &deviceManager, uint16_t slavePosition)
	Reads a device's CiA402 control snapshot (state, status/control words, active mode).
std::expected< Cia402Status, std::string >	mm::node::setCia402OperationMode (DeviceManager &deviceManager, uint16_t slavePosition, int8_t mode, std::chrono::milliseconds timeout=std::chrono::milliseconds(200))
	Requests an operation mode (0x6060) by its raw value, then reads back the snapshot.
std::expected< Cia402Status, std::string >	mm::node::runCia402Command (DeviceManager &deviceManager, uint16_t slavePosition, Cia402Command command, std::chrono::milliseconds timeout=std::chrono::milliseconds(2000))
	Runs a CiA402 state-machine command (enable / disable / quick stop / fault reset), then reads back the resulting snapshot.
std::expected< Cia402Status, std::string >	mm::node::transitionToCia402State (DeviceManager &deviceManager, uint16_t slavePosition, cia402::State target, std::chrono::milliseconds timeout=std::chrono::milliseconds(2000))
	Brings a drive to target, walking whatever transitions that takes, then reads back the resulting snapshot.
std::expected< void, std::string >	mm::node::setCia402Target (DeviceManager &deviceManager, uint16_t slavePosition, Cia402TargetKind kind, int32_t setpoint)
	Writes the one CiA402 cyclic setpoint that matches the active operation mode.

Detailed Description

CiA402 drive control by bus position — resolve, bind a view, run one operation.

These are free functions over DeviceManager& rather than methods on it, because owning the device set and knowing the CiA402 vocabulary are different jobs: DeviceManager hands out a DeviceHandle and never names a profile type, and the profile layer builds on top of it. Each function is the same three lines — DeviceManager::deviceAt to resolve the position and hold the device alive, createCia402Drive to validate the device really is a drive, then one call on the view — so the domain logic stays on Cia402Drive and these are only the lifetime-safe way in.

The bus lock is held (shared) for each call's whole duration, including runCia402Command's multi-second enable walk. That blocks only the exclusive rebuilders (scan / reset), never the RT loop or the WebSocket: each individual read and write takes the driver's control-plane lock only for its own transaction.

These are deliberately not procedures. They are short, interactive device control, and — decisively — they are what procedures are built from: offset detection has to enable the drive as one of its steps, so if enabling were itself a registered procedure the parent would deadlock trying to acquire a device token it already holds. Procedures compose out of plain calls like these. (profile_procedures.h holds the operations that genuinely are procedures.)

All of them require the device to be exchanging for the state machine to actually advance.