The native master/slave state machine is the preferred way to coordinate synchronized virtual/physical systems.
Use it when:
Typical examples are slit and mirror systems with virtual master axes and physical slave axes.
Use the wrapper script:
${SCRIPTEXEC} ${ecmccfg_DIR}addMasterSlaveSM.cmd \
"NAME=Slit_SM, MST_GRP_NAME=virtualAxes, SLV_GRP_NAME=realAxes"
Arguments:
NAME: object name shown in PVs and overviewsMST_GRP_NAME: master-group name, normally the virtual axesSLV_GRP_NAME: slave-group name, normally the physical axesMST_DISABLE (optional): auto-disable master axes when not busySLV_DISABLE (optional): auto-disable slave axes when not busyIf you want full control from each axis YAML instead, leave MST_DISABLE and SLV_DISABLE at 0 and configure axis.autoEnable per axis.
For state machine 0, the main PVs are:
$(IOC):SM00-EnaCmd$(IOC):SM00-StateCmd$(IOC):SM00-Stat$(IOC):SM00-MstsAutoDsbleCmd$(IOC):SM00-SlvsAutoDsbleCmd$(IOC):SM00-DbgPrntEna$(IOC):SM00-MstGrpNam$(IOC):SM00-SlvGrpNamStateCmd supports these states:
IDLESLAVEMASTERRESETThe exact transition behavior depends on the object state and the involved axes, but in normal use the state machine decides which group should currently drive the synchronized system.
Master/slave objects are also exposed through the standard linked-list summary PVs:
$(IOC):MCU-Cfg-SM-FrstObjId$(IOC):MCU-Cfg-SM<n>-NxtObjId$(IOC):MCU-Cfg-SM<n>-PrvObjIdThese are primarily used by overview panels and object-browser tooling.
addMasterSlaveSM.cmd.For most new systems, this is preferable to keeping equivalent switching logic in PLC code.