Overview
The PM motion module allows axes to be controlled using the PP, HM, PV, and TQ command modes of EtherCAT (or other CANopen-based platforms).
These command modes are different from the cyclic position, cyclic velocity, and cyclic torque command modes that are used by other motion modules. Instead of sending position, velocity, or torque commands to the servo drive every cycle, motion commands are sent to the servo only when one of the functions in the PM motion module is called. The cyclic position commands are then generated by the servo drive.
Each platform or each master is controlled by either PMMotion or CoreMotion. When both modules are loaded, the axis is controlled by the former if PP mode is enabled in the def settings of the communication platform, and by the latter otherwise (default value).
Therefore, in the case of multiple platforms or masters, there can be one network lineage controlled by PMMotion and another controlled by CoreMotion.
PM Motion Axes
PM motion axes are axes that can be controlled by the PM motion module.
PM motion axes are assigned axis numbers separately from regular axes. As such, a PM motion axis with a particular axis number is different from a regular axis with the same axis number. All functions in the PM motion module with axis parameters must be passed PM motion axis numbers.
The maximum number of PM motion axes that may be controlled is contained in the constant maxPMAxes.
The status of PM motion axes can only be obtained with the GetStatus function defined in the PMMotion class.
PM Motion Network
PM motion axes must be connected to a network that is separate from regular axes. If both PM motion axes and regular axes must be controlled, two NICs are required.
The I/O data of PM motion axis slaves and other I/O modules connected to the PM network are assigned addresses in the same address space as regular slaves, and can be accessed through functions in the Io module.
Not all servo drives support PP, HM, PV, and TQ command modes. The PM motion module is unable to control servo drives that do not support any of these modes.
Supported Platforms
The PM motion module is only compatible with the EtherCAT platform (or other CANopen-based platforms). PM motion axes cannot be controlled by any other platform, including the Simulator platform.
Configuration
The Configuration page explains the settings that must be configured to use the PM motion module.
About the PM Motion equivalent APIs supported by the Platform
The PM Motion equivalent API supported by the Platform accesses objects directly through asynchronous communication. When using these APIs, there is no need to use PM Motion, which offers the following advantages.
Asynchronous communication takes place, so there is no need to map objects to cyclic data. This is an advantage for some slaves who cannot map objects required in profile mode to cyclic data. Note: If the object is mapped, the command is sent by writing values to cyclic data, not by asynchronous communication.
There is no need to load the PMMotion module.
The PMMotion module requires the entire network tied to a particular NIC to be a dedicated PMMotion line by defining PPmode=1 in the network definition file, but this is not necessary with the Platform function. It is also possible to change some slaves running in cyclic mode to profile mode. (However, there are some precautions described below.)
On the other hand, there are also the following disadvantages.
Bandwidth is squeezed by asynchronous communication packet data.
Reflecting commands through asynchronous communication has an overhead compared to commands by writing values directly to cyclic data.
In the profile mode control via the Platform API, CoreMotion commands are only temporarily disabled by the platform during profile mode. Therefore, the CoreMotion command values are suddenly enabled and the axis position may change suddenly if the control mode is changed back from profile mode to cyclic mode while the servo is on.
How to set a value to a profile mode object not supported by APIs
PMMotion APIs (and the platform’s APIs for profile mode) accesses a specific minimum number of objects, but many objects are supported by some slaves, for example, profile type.
If setting values to those objects is required, use the platform’s asynchronous communication functions to control them individually.