Overview
The motion classes of INOS are responsible for all kinds of axes handling. They provide a big range of functioality beginning from simple axis moving over homing mechanisms to trajectory planning of a whole move path. Here are some customer examples based on the INOS motion library :
- optimized event based moving algorithms for pick and place machines
- planing and running 4 axes based curves in cartesian coordinates of a wire bonder
- touch down handlings based on special approaching moves reducing the speed at the target position
- dispensing free definable patterns with e.g. rounded curves based on clothoids
- running HPGL code
- ...
Example how to move with two axis :
Example how to run a clothoid shaped square :
Both examples are functional without controller hardware due to the fact, that the axes are activated in full simulation mode.
Axis
Overview of all classes which are involved in the axis handling of INOS. Clicking on a class directs to the corresponding class documentation.
As shown in the class diagram, an axis is represented by the class CINOSPhysicalAxis (the class CINOSBaseAxis is normally not used directly). It has three main parts :
- Motor represents all motor properties
- Ramp is responsible for the trajectory generation
- Control represents the axis controller
An axis is configured with a descriptor. The descriptor structure for a physical axis is defined in SINOSPhysicalAxis. The corresponding configuration file is a text file which represents the required struture. The file ending has to be 'dt2'.
Example of an axis config file x.axis.dt2:
For a detailed explanation of every description member refere to SINOSPhysicalAxis and SINOSBaseAxis.
Motor
An motor is configured with a descriptor. The descriptor structure for a motor is defined in SINOSBaseMotor. The corresponding configuration file is a text file which represents the required struture. The file ending has to be 'dt2'.
Example of an resolver motor with 5:1 belt and 32 mm spindle config file z.motor.dt2 :
Example of an motor with 4096 Inc Encoder 156:25 gear in degrees config file t.motor.dt2 :
Example of an linear motor with 20um SinCos with 4096 times interpolation and 24 mm pole pitch config file x.motor.dt2 :
100% Speed 5m/s: TurnsPerMin = 5000mm/s * 60min/s / 24mm = 12500 1/min
IncsPerTurn: 24mm/0.02mm*4096 = 4915200
For a detailed explanation of every description member refere to SINOSBaseMotor.
Ramp
A trajectory generator (aka Ramp) is configured with a descriptor. The descriptor structure for a ramp is defined in the corresponding structure, e.g. SINOSJerkRamp for the main stream generator. The corresponding configuration file is a text file which represents the required structure. The file ending has to be 'dt2'.
Example of a jerk ramp config file x.jerkramp.dt2:
For a detailed explanation of every description member refere to SINOSBaseRamp and SINOSJerkRamp.
Control
An axis controller is configured with a descriptor. The descriptor structure for a controller is defined in the corresponding structure, e.g. SINOSPosControl for the default Indel target controller. The corresponding configuration file is a text file which represents the required structure. The file ending has to be 'dt2'.
Example of a position control config file x.posctrl.dt2:
For a detailed explanation of every description member refere to SINOSBaseControl and SINOSPosControl.
Movepath
Overview of all classes which are involved in the movepath handling of INOS. Clicking on a class directs to the corresponding class documentation.
A movepath is used whenever multiple axes need to be moved on a coordinated path. Here are some examples implemented with a movepath :
- one has to move with an XY gantry from point A via point B to point C, a simple approach would be to move first to point B and in a second move to point C. Doing so would loose time. A better way is to use a movepath, where one can connect two linear moves together and blend them with an appropriate interpolator, which ensures, that the axes do not move exactly through point B and therefore do not have to stop at that point.
- a four axes handling system needs to move on a predefined path from a pick to a place position, again the simple approach would be to use single moves, the better one is to use a movepath and connect the segments together with an appropriate interpolator
- dispensing free definable patterns with e.g. rounded curves based on clothoids
As shown in the class diagram, a movepath has three main parts
- Curve represents the geometric curve definition
- Interpolator is responsible to blend movepath segments
- Trajectory is responsible for the overall trajectory generation
These three main parts need to be provided at a movepath creation. Example :
The above code creates a movepath with curve type "Base", interpolator type "Clothoid" and trajectory type "Constant". Additionaly one has to map global axis names to movepath axes indexes. This can be done either globally with the static method CINOSMovePath::glbSetAxis or separate for each movepath itself with the path method CINOSMovePath::SetAxis. Example
The maximum number of axes a movepath can handle is defined here DF_INOS_MOVEPATH_MAX_AXES. It can be overwritten by setting an own value in one's project inosuser.h file. Example how to increase to 5 axes :
The define ::DF_INOS_MOVEPATH_ALL_AXES_INVOLVED has to be equal to 2^DF_INOS_MOVEPATH_MAX_AXES-1.
Hint: To be sure, that the your number of axis is taken, you have to ensure that the application/inosuser.h file is taken before the inosdefault.h of the operating system. For this check in iDev Properties.C/C++ General.Path and Symbols.Includes.GNU C++ that your application/inc directory is listed before inos/os/inos/inc.
Before one is able to define the movepath geometry, one has to enter into edit mode
In the example we entered into edit mode and told the system, that all distances will be relative (incremental).
The geometry can then be defined by adding the required segments
Assume a starting point of X1=20, Y1=30. The upper example then moves first to the absolute position 120/80 and then to 270/330.
When you've done defining the path, exit the edit mode and run the path
After the run, do not forget to destroy the path, otherwise you would end up with memory leaks
For a full movepath example, see also Overview
Parts
Curve
The geometry of the path to move is represented by the class CINOSMovePathCurve. A curve contains segments. Depending on the curve type, one segment has either multiple parts or one nurbs curve with an unlimited number of control points and knots. In standard use cases one does not have to care about all these classes. The following curve types are currently available :
- "Base"
- "Nurbs", The NURBS Book, Les Piegl and Wayne Tiller, ISBN 3-540-61545-8
Interpolator
The interpolator is responsible for the connection of curve segments. The following types are currently available :
- "None" no connection segments are used, this normally ends up in a stop at segment boundaries
- "Polynom" allows to smoothly (two times continous) connect segments of any kind (e.g. linear and circular segments).
- "Blend" implements the Lloyd and Hayward’s Blending algorithm (limitted to connect linear segments)
- "Shape" uses standard axis speedsets to blend between segments, blending is done by stopping e.g. one axis while an other one is already started (limitted to connect linear segments)
- "Clothoid" uses clothoids to blend two linear segments, only available for paths with two axes (e.g. X and Y)
- "Nurbs" uses nurbs to connect the segments
This list can be extended with customer interpolators. To implement a customer interpolator class, inherit the CINOSMovePathInterpolator class.
We recommend using the override keyword when overriding functions from the CINOSMovePathInterpolator class.
Interpolators have to be registered with their unique name and their constructor in a static map of the CINOSMovePathInterpolator class. Use the INOS_REGISTER_MOVEPATH_INTERPOLATOR macro with the interpolator name and class name as arguments to register a new interpolator. For a CustomerInterpolator class with Customer as interpolator name it is:
Trajectory
The trajectory class is responsible for the overall trajectory generation. It is resonsible to e.g. stop or at least reduce the speed at a segment boundary if it is necessary. The following types are currently available :
- "Constant" the whole movepath is done with a constant speed
- "Segment" reduces the requested speed if necessary on e.g. segment boundaries
Parameter
To be able to parametrise a movepath and all its involved class instances, the path provides generic SetParam and GetParm methods. We differ between general and axis specific parameters. Example :
General Parameter
Here is a list of all currently available general parameters (see also cinosmovepath.h) :
Helper task
General McRobot
Shape interpolator
Nurbs interpolator
Clothoid interpolator
Trajectory generator
Axis specific parameter
Axis specific parameters are handled with SetParam(index, ...) and GetParm(index, ...). Here is a list of all currently available axis specific parameters :
Error handling
Every movepath method returns either 0 if it was successful or a corresponding error code. There are two possibilities to handle errors.
The first classic one is to check for an error after every call and react accordingly if the call was not successful. This can be pretty annoying if one creates a big movepath with a lot of segments.
The second one is to work with C++ exception handling. For this, one needs to do the following :
- Activate the following iDev features :
- General options.C++ exception support
- MovePath.Exception support
- Set the additional compiler flag '-fexceptions' for the corresponding file
- right mouse click on the file -> Properties
- C/C++ Build.Settings
- Miscellaneous -> Other flags -> -fexceptions
- Use the additional option DF_INOS_MOVEPATH_OPTION_EXCEPTION_SUPPORT during creation of the path
Then one can write code like this :
Tracing
To get extended information in case of movepath errors, there are two trace levels one can activate. The level 'MovePathCreate' for all creation stuff and the level 'MovePathRun' for movement issues. Activating both in Indel Eventlogger shows the following trace for the upper example :
Lua binding
You can create a movepath not only from C++ but also within a Lua script. To make the MovePath Lua module available, enable feature MovePath > Lua binding in the iDev feature settings of your project.
Example (linear segments connected with a shape interpolator, set priority of helper task to 31 and let it run on core 1) :
Example (Nurbs curve) :
Example (Circle as a Nurbs curve):
Example (Calculating length and velocity of MovePath):
To run the path, you have to hand it over to the corresponding McRobot module which is responsible for the selected axes. Note that the RunPath command used for that is a different overload than the one visible in the INCO tree: The one called from Lua is CINOSMcRobot::eCmdRunPath and takes arguments (CINOSMovePath Path, string SpeedSet). The one in the INCO tree is CINOSMcRobot::eCmdRunPathStr and takes arguments (string PathName, string SpeedSet, string Param) (where Param is currently ignored).
You do not have to destroy the path yourself after the run, the system is doing that for you.
There is more or less a one to one relation between C++ methods and Lua functions. To work with movepath functionality, you need to import the 'MovePath' module :
In Lua we differ between library and path functions. You can use direct or named parameters. We suggest to use named parameters. The used abbreviations have the following meaning :
- nnn a number is required
- sss a string is required
- Flags the strings "Absolute", "Incremental" and "NotLengthRelevant" are allowed
The following library functions are available in Lua :
Click on the method to get directed to the corresponding description.
The following path methods are available in Lua :
Click on the method to get directed to the corresponding description.
