This package provides control object primitives for a ethercat bus of motor controllers, presently only the Maxon
EPOS4 Micro. It wraps the pysoem library, providing a framework for interacting with device states and registers
and performing homing (calibration) and position-based moves with devices on the bus. As a soft master, it requires a
dedicated NIC attached via ethernet cable to an EtherCAT motion controller bus. Note that EtherCAT traffic is
incompatible with normal ethernet networks and networking equipment.
- Instantiate
bus = EPOS4Bus(<ethernet device, i.e. eth0>>) - Subclass
EPOS4Motorand implementconfig_func. - Call
bus.initialize(type_mapping). Where type mapping is a mapping of bus node ID toEPOS4Motorsubclass. - Use methods on bus or bus.slaves. Refer to code/docstrings for more information.
The hardware abstraction layer is responsible for sending actual information over the NIC to the workers. Currently,
the only HAL setup for this repository is the pysoemHAL. It uses pysoem, a cython wrapper for
SOEM. Something to keep in mind is that these are designed to be simple soft EtherCAT controllers,
and as a result it is difficult to directly change the CoE messages being sent, which likely prevents using
CoE to its full potential. Future HALs should be made with the same function names and send the same CoE
telegrams (this can be verified with wireshark). An additional consequence is that the high level soft
controller and pysoemHAL have very similar function names.
TODO this should likely be merged with the EthercatBus.
The high level controller breaks down many high level fundamental requests into sequences of CoE commands that will be performed by the hardware abstraction layer (HAL). This includes configuration tasks on startup. Additionally, it does a lot of 'book keeping' tasks, such as tracking worker process data object assignments, fully automates device state changes, and handling the network management state at the current scope of the project (it's easy to break with the addition of new features).
A current limitation of the soft high level controller is that PDO communication is only possible once all workers have reached identical states and modes. The reason for this is that many of the performable actions (homing, and moving) complete at unique times for each worker, and all workers must receive PDO during each message. This means that creating a truly generalized PDO solution must handle time sensitive input, sequence sensitive input, and wait/continue logic unique to physical robotic systems. The difficulty of this task in comparison to the new capabilities was too low to justify for the FCS and CSU for which this repository was initially designed.
A base class for EPOS4 Micro's on the bus. Client code should subclass this and implement config_func. Look at the
lris2-csu library for an example.
- Software tested on EPOS4 Micro 24/5 EtherCAT
- Pesent development has centered on the needs of the LRIS2 CSU, the first client to this library.
- This system uses EPOS2 Micro motion controllers and the CiA 402 specification.
- Currently the only CiA 402 supported operation modes are Homing Mode and Profile Position Mode (non-continuous)
The CAN in Automation (CiA) group has released a technical specification for power drive systems that is designed to make communication robust and safe. The most important thing to know about this specification is that it ensures robust and safe operation by standardizing device states, network management states, and operating modes. Certain actions, for example movement and configuration, are only available in the correct combination of device state, network management state, and operating mode. A CoE CiA 402 guide has been made specifically for Maxon's EPOS Micro 24/5 EtherCAT worker hardware, which is worth a read to get more information about the CiA 402 specification.