SoftMC-Wiki - User contributions [en]

Dynamic Models

2019-09-11T05:34:11Z

Itay:

This page gives an overview over all implemented dynamic models.

'''General considerations'''
* Friction is handled on axis basis. The parameters for friction are set for each axis separately.
* Torque (Force) is always expressed in '''[Nm]''' ([N]) 

== Rotational Axes ==

=== Dynamic Model 1 - simple rotary axis ===
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|}
;Model equation
: <math>T = (I + I_{payload}) \cdot acc</math>

 
=== Dynamic Model 2 - horizontal crank-arm axis ===
[[File:Axystems;Motion Dynamics - Horizontal Crank-Arm Axis.png|Horizontal crank-arm axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|-
|2
|<math>L^2</math>
|Square of length of crank arm (axis to payload)
|}
;Model equation
: <math>T = (I + I_{payload} + L^2 \cdot M_{payload}) \cdot acc</math>

 
=== Dynamic Model 3 - vertical crank-arm axis ===
[[File:Axystems;Motion Dynamics - Vertical Crank-Arm Axis.png|Vertical crank-arm axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|-
|2
|<math>L^2</math>
|Square of length of crank arm (axis to payload)
|-
|3
|<math>M \cdot g \cdot A</math>
|Mass (without payload) * Gravity * Distance to center of mass
|-
|4
|<math>g \cdot L</math>
|Gravity * Distance to Payload
|}
;Model equation
: <math>T = (I + I_{payload} + L^2 \cdot M_{payload}) \cdot acc - (M \cdot g \cdot A + M_{payload} \cdot g \cdot L) \cdot \sin(pos)</math>

== Linear Axes ==

=== Dynamic Model 1 - horizontal axis ===
[[File:Axystems;Motion Dynamics - Horizontal Axis.png|Horizontal linear axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part.
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot acc</math>

 
=== Dynamic Model 2 - vertical or tilted axis ===
[[File:Axystems;Motion Dynamics - Vertical Axis.png|Vertical linear axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part.
|-
|2
|<math>M \cdot g \cdot \cos(\alpha)</math>
|Constant force due to gravity.
|-
|3
|<math>g \cdot \cos(\alpha)</math>
|Gravity coefficient used to consider payload mass. ('''g = 9.80665''')
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot acc + M \cdot g \cdot \cos(\alpha) + M_{payload} \cdot g \cdot \cos(\alpha)</math>

 
=== Dynamic Model 3 - vertical axis with a spring ===
[[File:Axystems;Motion_Dynamics_-_Vertical_Axis_with_spring.png|Vertical linear axis with a spring|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part. [kg]
|-
|2
|<math>K</math>
|The stiffness constant of the spring. [kg/s^2]
|-
|3
|<math>K \cdot X_{0}</math>
|The stiffness constant times the relaxation position of the spring. [kg*m/s^2]
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot (acc + g) + K\cdot (X-X_{0})</math>

== Traverse Arm Robots ==

=== Dynamic Model 1 ===
[[File:Inverse dynamic model for Traverse Arm kinematics - Definitions.png|Traverse Arm robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M_1 + M_2</math>
|-
|2
|<math>A_2 \cdot M_2</math>
|-
|3
|<math>A_2^2 \cdot M_2 + I_2</math>
|-
|4
|<math>M_3</math>
|-
|5
|<math>g \cdot M_3</math>
|-
|6
|<math>I_4</math>
|-
|7
|<math>J_4</math>
|}

== Scara Robots ==

=== Dynamic Model 1 ===
[[File:scara.PNG|scara robot|thumb]]
For non-coupled SCARA robots (axis 3 and 4 are not coupled). 
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>L_1^2 \cdot M_2 + I_1</math>
|-
|2
|<math>A_2^2 \cdot M_2 + I_2</math>
|-
|3
|<math>J_2</math>
|-
|4
|<math>L_1 \cdot A_2 \cdot M_2</math>
|-
|5
|<math>M_3</math>
|-
|6
|<math>g \cdot M_3</math>
|-
|7
|<math>I_4</math>
|-
|8
|<math>J_4</math>
|}

=== Dynamic Model 2 ===
For coupled SCARA robots (axis 3 and 4 are coupled) and for concentric payloads (concentric with axis 4). 
Note: <math>M_3</math> includes both the masses of link 3 and link 4 
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|9
|<math>L_1^2 \cdot (M_2+M_3) + I_1 + J_1</math>
|-
|10
|<math>A_2^2 \cdot M_2 + L_2^2 \cdot M_3 + I_2</math>
|-
|11
|<math>L_1 \cdot A_2 \cdot M_2 + L_1 \cdot L_2 \cdot M_3</math>
|-
|12
|<math>M_3</math>
|-
|13
|<math>I_4</math>
|-
|14
|<math>J_2</math>
|-
|15
|<math>J_3</math>
|-
|16
|<math>J_4</math>
|}

The payload parameters are:
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|payloadMass
|The mass of the payload
|-
|2
|payloadInertia
|The Inertia of the payload relative to its center of mass
|}

=== Dynamic Model 3 ===
For coupled SCARA robots (axis 3 and 4 are coupled) and for non-concentric payloads (non-concentric with axis 4). 
The dynamic parameters are the same as model 2. 

The payload parameters are:
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|payloadMass
|The mass of the payload
|-
|2
|payloadInertia
|The Inertia of the payload relative to its center of mass
|-
|4
|payloadLx
|The distance to the center of mass from the 4th axis in the x direction
|}

When using identification with this model, all of the payload parameters can be found. 

=== Dynamic Model 4 ===

Same as Dynamic Model 3. This model is used in identification process in order to identify the '''payloadMass''' parameter only, by moving only joint number 3.

=== Dynamic Model 5 ===

Same as Dynamic Model 3. This model is used in identification process in order to identify the '''payloadInertia''' and '''payloadLx''' parameters, by moving only joint number 4 and very small movements in joints 1 and 2.

== Delta Robots ==

=== Dynamic Model 1 ===
[[File:Control;Rod forces model for Delta kinematics - Introduction.png|Delta robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>\Theta_{AB}</math>
|kg*m2
|-
|2
|<math>g \cdot L_{AB} \cdot M_{AB}</math>
| kg*m2/sec2
|-
|3
|<math>M_{BC}</math>
|kg
|-
|4
|<math>\Theta_{BC}</math>
|kg*m2
|-
|5
|<math>M_P</math>
|kg
|-
|6
|<math>M_T</math>
|kg
|-
|7
|<math>\Theta_T</math>
|kg*m2
|-
|8
|<math>\Theta_{T\phi}</math>
|kg*m2
|-
|9
|<math>L_{TO}</math>
| m
|-
|10
|<math>L_{TP}</math>
| m
|-
|11
|<math>D</math>
|-
|12
|<math>C_r</math>
|-
|13
|<math>Fr_{max}</math>
|-
|14
|<math>R_{ext}</math>
|}

== Puma Robots ==
=== Dynamic Model 1 ===
[[File:puma.PNG|Puma robot|thumb]]

Description:
:* <math> g </math> - Gravity constant
:* <math> m_{i} </math> - Mass of the ith link
:* <math> a_{i} </math> - length of the common normal between the ith and ith+1 joints
:* <math> d_{i} </math> - offset along z axis between the ith and ith+1 joints
:* <math> l_{i} </math> - The distance from the ith joint to the center of mass of the ith link

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I_{1} = I_{1,zz}+m_{1}*l_{1,y}^2 +m_{2}*d_{2}^2+(m_{4}+m_{5}+m_{6})*a_{3}^2+m_{2}*l_{2,z}^2+</math> <math>(m_{3}+m_{4}+m_{5}+m_{6})*(d_{2}+d_{3})^2+I_{2,xx}+I_{3,yy}+2*m_{2}*d_{2}*l_{2,z}+m_{2}*l_{2,y}^2+m_{3}*l_{3,z}^2+2*m_{3}*(d_{2}+d_{3})*l_{3,z}+I_{4,zz}+I_{4,yy}+I_{6,zz}</math>
|kg*m^2
|-
|2
|<math>I_{2} = I_{2,zz}+m_{2}*(l_{2,x}^2+l_{2,y}^2)+(m_{3}+m_{4}+m_{5}+m_{6}*a_{2}^2</math>
|kg*m^2
|-
|3
|<math>I_{3} = -I_{2,xx}+I_{2,yy}+(m_{3}+m_{4}+m_{5}+m_{6})*a_{2}^2+m_{2}*l_{2,x}^2-m_{2}*l_{2,y}^2</math>
|kg*m^2
|-
|4
|<math>I_{4} = m_{2}*l_{2,x}*(d_{2}+l_{2,z})+m_{3}*a_{2}*l_{3,z}+(m_{3}+m_{4}+m_{5}+m_{6})*a_{2}*(d_{2}+d_{3})</math>
|kg*m^2
|-
|5
|<math>I_{5} = -m_{3}*a_{2}*l_{3,y}+(m_{4}+m_{5}+m_{6})*a_{2}*d_{4}+m_{4}*a_{2}*l_{4,z}</math>
|kg*m^2
|-
|6
|<math>I_{6} = I_{3,zz}+m_{3}*l_{3,y}^2+m_{4}*a_{3}^2+m_{4}*(d_{4}+l_{4,z})^2+I_{4,yy}+m_{5}*a_{3}^2+m_{5}*d_{4}^2+I_{5,zz}+m_{6}*a_{3}^2+m_{6}*d_{4}^2+m_{6}*l_{6,z}^2+I_{6,xx}</math>
|kg*m^2
|-
|7
|<math>I_{7} = m_{3}*l_{3,y}^2+I_{3,xx}-I_{3,yy}+m_{4}*l_{4,z}^2+2*m_{4}*d_{4}*l_{4,z}+(m_{4}+m_{5}+m_{6})*(d_{4}^2-a_{3}^2)+I_{4,yy}-I_{4,yy}+I_{5,zz}-I_{5,yy}+m_{6}*l_{6,z}^2-I_{6,zz}+I_{6,xx}</math>
|kg*m^2
|-
|8
|<math>I_{8} = -m_{4}*(d_{2}+d_{3})*(d_{4}+l_{4,z})-(m_{3}+m_{6})*(d_{2}+d_{3})*d_{4}+m_{3}*l_{3,y}*l_{3,z}+m_{3}*(d_{2}+d_{3})*l_{3,y}</math>
|kg*m^2
|-
|9
|<math>I_{9} = m_{2}*l_{2,y}*(d_{2}+l_{2,z})</math>
|kg*m^2
|-
|10
|<math>I_{10} = 2*m_{4}*a_{5}*l_{4,z}+2*(m_{4}+m_{5}+m_{6})*a_{3}*d_{4}</math>
|kg*m^2
|-
|11
|<math>I_{11} = -2*m_{2}*l_{2,x}*l_{2,y}</math>
|kg*m^2
|-
|12
|<math>I_{12} = (m_{4}+m_{5}+m_{6})*a_{2}*a_{3}</math>
|kg*m^2
|-
|13
|<math>I_{13} = (m_{4}+m_{5}+m_{6})*a_{3}*(d_{2}+d_{3})</math>
|kg*m^2
|-
|14
|<math>I_{14} = I_{4,zz}+I_{5,yy}+I_{6,zz}</math>
|kg*m^2
|-
|15
|<math>I_{15} = m_{6}*d_{4}*l_{6,z}</math>
|kg*m^2
|-
|16
|<math>I_{16} = m_{6}*a_{2}*l_{6,z}</math>
|kg*m^2
|-
|17
|<math>I_{17} = I_{5,zz}+I_{6,xx}+m_{6}*l_{6,z}^2</math>
|kg*m^2
|-
|18
|<math>I_{18} = m_{6}*(d_{2}+d_{3})*l_{6,z}</math>
|kg*m^2
|-
|19
|<math>I_{19} = I_{4,yy}-I_{4,xx}+I_{5,zz}-i_{5,yy}+m_{6}*l_{6,z}^2+I_{6,xx}-I_{6,zz}</math>
|kg*m^2
|-
|20
|<math>I_{20} = I_{5,yy}-I_{5,xx}-m_{6}*l_{6,z}^2+I_{6,zz}-I_{6,xx}</math>
|kg*m^2
|-
|21
|<math>I_{21} = I_{4,xx}-I_{4,yy}+I_{5,xx}-I_{5,zz}</math>
|kg*m^2
|-
|22
|<math>I_{22} = m_{6}*a_{3}*l_{6,z}</math>
|kg*m^2
|-
|23
|<math>I_{23} = I_{6,zz}</math>
|kg*m^2
|}

=== Dynamic Model 2 - Gravity ===
This dynamic model is for cases where the robot moves very slowly. 
In such cases, the accelerations and velocities of the joints of the robot have little effect on the joints torques. The joints torques are mainly affected by gravity and friction. 
This model includes only the gravity and friction part of the PUMA robot dynamic model. 

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>g(m_{2}l_{2}+a_{2}(m_{3}+m_{4}+m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|2
|<math>g(m_{3}l_{3,y}+a_{3}(m_{4}+m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|3
|<math>g(m_{3}l_{3,y}+m_{4}(l_{4}+d_{4}(m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|4
|<math>gl_{56}(m_{5}+m_{6})</math>
|kg*m^2/s^2

|}

== Galileo Spherical Robots (GSR) ==

=== Dynamic Model 1 ===

[[File:GSR-SETUP.JPG|Galileo robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|mP
|Payload mass [kg]
|-
|2
|mB
|Balance mass [kg]
|-
|3
|TP
|Payload mass center distance from the flange [mm]
|-
|4
|TB
|Balance mass center distance from the (0,0) [mm]
|-
|5
|IR
|Inertia of the payload around roll [kg*m2
|}

[[Category:Motion Dynamics]]

Dynamic Models

2019-09-11T05:33:26Z

Itay:

This page gives an overview over all implemented dynamic models.

'''General considerations'''
* Friction is handled on axis basis. The parameters for friction are set for each axis separately.
* Torque (Force) is always expressed in '''[Nm]''' ([N]) 

== Rotational Axes ==

=== Dynamic Model 1 - simple rotary axis ===
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|}
;Model equation
: <math>T = (I + I_{payload}) \cdot acc</math>

 
=== Dynamic Model 2 - horizontal crank-arm axis ===
[[File:Axystems;Motion Dynamics - Horizontal Crank-Arm Axis.png|Horizontal crank-arm axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|-
|2
|<math>L^2</math>
|Square of length of crank arm (axis to payload)
|}
;Model equation
: <math>T = (I + I_{payload} + L^2 \cdot M_{payload}) \cdot acc</math>

 
=== Dynamic Model 3 - vertical crank-arm axis ===
[[File:Axystems;Motion Dynamics - Vertical Crank-Arm Axis.png|Vertical crank-arm axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|-
|2
|<math>L^2</math>
|Square of length of crank arm (axis to payload)
|-
|3
|<math>M \cdot g \cdot A</math>
|Mass (without payload) * Gravity * Distance to center of mass
|-
|4
|<math>g \cdot L</math>
|Gravity * Distance to Payload
|}
;Model equation
: <math>T = (I + I_{payload} + L^2 \cdot M_{payload}) \cdot acc - (M \cdot g \cdot A + M_{payload} \cdot g \cdot L) \cdot \sin(pos)</math>

== Linear Axes ==

=== Dynamic Model 1 - horizontal axis ===
[[File:Axystems;Motion Dynamics - Horizontal Axis.png|Horizontal linear axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part.
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot acc</math>

 
=== Dynamic Model 2 - vertical or tilted axis ===
[[File:Axystems;Motion Dynamics - Vertical Axis.png|Vertical linear axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part.
|-
|2
|<math>M \cdot g \cdot \cos(\alpha)</math>
|Constant force due to gravity.
|-
|3
|<math>g \cdot \cos(\alpha)</math>
|Gravity coefficient used to consider payload mass. ('''g = 9.80665''')
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot acc + M \cdot g \cdot \cos(\alpha) + M_{payload} \cdot g \cdot \cos(\alpha)</math>

 
=== Dynamic Model 3 - vertical axis with a spring ===
[[File:Axystems;Motion_Dynamics_-_Vertical_Axis_with_spring.png|Vertical linear axis with a spring|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part. [kg]
|-
|2
|<math>K</math>
|The stiffness constant of the spring. [kg/s^2]
|-
|3
|<math>K \cdot X_{0}</math>
|The stiffness constant times the relaxation position of the spring. [kg*m/s^2]
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot (acc + g) + K\cdot (X-X_{0})</math>

== Traverse Arm Robots ==

=== Dynamic Model 1 ===
[[File:Inverse dynamic model for Traverse Arm kinematics - Definitions.png|Traverse Arm robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M_1 + M_2</math>
|-
|2
|<math>A_2 \cdot M_2</math>
|-
|3
|<math>A_2^2 \cdot M_2 + I_2</math>
|-
|4
|<math>M_3</math>
|-
|5
|<math>g \cdot M_3</math>
|-
|6
|<math>I_4</math>
|-
|7
|<math>J_4</math>
|}

== Scara Robots ==

=== Dynamic Model 1 ===
[[File:scara.PNG|scara robot|thumb]]
For non-coupled SCARA robots (axis 3 and 4 are not coupled). 
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>L_1^2 \cdot M_2 + I_1</math>
|-
|2
|<math>A_2^2 \cdot M_2 + I_2</math>
|-
|3
|<math>J_2</math>
|-
|4
|<math>L_1 \cdot A_2 \cdot M_2</math>
|-
|5
|<math>M_3</math>
|-
|6
|<math>g \cdot M_3</math>
|-
|7
|<math>I_4</math>
|-
|8
|<math>J_4</math>
|}

=== Dynamic Model 2 ===
For coupled SCARA robots (axis 3 and 4 are coupled) and for concentric payloads (concentric with axis 4). 
Note: <math>M_3</math> includes both the masses of link 3 and link 4 
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|9
|<math>L_1^2 \cdot (M_2+M_3) + I_1 + J_1</math>
|-
|10
|<math>A_2^2 \cdot M_2 + L_2^2 \cdot M_3 + I_2</math>
|-
|11
|<math>L_1 \cdot A_2 \cdot M_2 + L_1 \cdot L_2 \cdot M_3</math>
|-
|12
|<math>M_3</math>
|-
|13
|<math>I_4</math>
|-
|14
|<math>J_2</math>
|-
|15
|<math>J_3</math>
|-
|16
|<math>J_4</math>
|}

The payload parameters are:
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|payloadMass
|The mass of the payload
|-
|2
|payloadInertia
|The Inertia of the payload relative to its center of mass
|}

=== Dynamic Model 3 ===
For coupled SCARA robots (axis 3 and 4 are coupled) and for non-concentric payloads (non-concentric with axis 4). 
The dynamic parameters are the same as model 2. 

The payload parameters are:
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|payloadMass
|The mass of the payload
|-
|2
|payloadInertia
|The Inertia of the payload relative to its center of mass
|-
|4
|payloadLx
|The distance to the center of mass from the 4th axis in the x direction
|}

When using identification with this model, all of the payload parameters can be found. 

=== Dynamic Model 4 ===

Same as Dynamic Model 3. This model is used in identification process in order to identify the '''payloadMass''' parameter only, by moving only joint number 3.

=== Dynamic Model 5 ===
Same as Dynamic Model 3. 
This model is used in identification process in order to identify the payloadInertia and payloadLx parameters, by moving only joint number 4 and very small movements in joints 1 and 2. 

== Delta Robots ==

=== Dynamic Model 1 ===
[[File:Control;Rod forces model for Delta kinematics - Introduction.png|Delta robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>\Theta_{AB}</math>
|kg*m2
|-
|2
|<math>g \cdot L_{AB} \cdot M_{AB}</math>
| kg*m2/sec2
|-
|3
|<math>M_{BC}</math>
|kg
|-
|4
|<math>\Theta_{BC}</math>
|kg*m2
|-
|5
|<math>M_P</math>
|kg
|-
|6
|<math>M_T</math>
|kg
|-
|7
|<math>\Theta_T</math>
|kg*m2
|-
|8
|<math>\Theta_{T\phi}</math>
|kg*m2
|-
|9
|<math>L_{TO}</math>
| m
|-
|10
|<math>L_{TP}</math>
| m
|-
|11
|<math>D</math>
|-
|12
|<math>C_r</math>
|-
|13
|<math>Fr_{max}</math>
|-
|14
|<math>R_{ext}</math>
|}

== Puma Robots ==
=== Dynamic Model 1 ===
[[File:puma.PNG|Puma robot|thumb]]

Description:
:* <math> g </math> - Gravity constant
:* <math> m_{i} </math> - Mass of the ith link
:* <math> a_{i} </math> - length of the common normal between the ith and ith+1 joints
:* <math> d_{i} </math> - offset along z axis between the ith and ith+1 joints
:* <math> l_{i} </math> - The distance from the ith joint to the center of mass of the ith link

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I_{1} = I_{1,zz}+m_{1}*l_{1,y}^2 +m_{2}*d_{2}^2+(m_{4}+m_{5}+m_{6})*a_{3}^2+m_{2}*l_{2,z}^2+</math> <math>(m_{3}+m_{4}+m_{5}+m_{6})*(d_{2}+d_{3})^2+I_{2,xx}+I_{3,yy}+2*m_{2}*d_{2}*l_{2,z}+m_{2}*l_{2,y}^2+m_{3}*l_{3,z}^2+2*m_{3}*(d_{2}+d_{3})*l_{3,z}+I_{4,zz}+I_{4,yy}+I_{6,zz}</math>
|kg*m^2
|-
|2
|<math>I_{2} = I_{2,zz}+m_{2}*(l_{2,x}^2+l_{2,y}^2)+(m_{3}+m_{4}+m_{5}+m_{6}*a_{2}^2</math>
|kg*m^2
|-
|3
|<math>I_{3} = -I_{2,xx}+I_{2,yy}+(m_{3}+m_{4}+m_{5}+m_{6})*a_{2}^2+m_{2}*l_{2,x}^2-m_{2}*l_{2,y}^2</math>
|kg*m^2
|-
|4
|<math>I_{4} = m_{2}*l_{2,x}*(d_{2}+l_{2,z})+m_{3}*a_{2}*l_{3,z}+(m_{3}+m_{4}+m_{5}+m_{6})*a_{2}*(d_{2}+d_{3})</math>
|kg*m^2
|-
|5
|<math>I_{5} = -m_{3}*a_{2}*l_{3,y}+(m_{4}+m_{5}+m_{6})*a_{2}*d_{4}+m_{4}*a_{2}*l_{4,z}</math>
|kg*m^2
|-
|6
|<math>I_{6} = I_{3,zz}+m_{3}*l_{3,y}^2+m_{4}*a_{3}^2+m_{4}*(d_{4}+l_{4,z})^2+I_{4,yy}+m_{5}*a_{3}^2+m_{5}*d_{4}^2+I_{5,zz}+m_{6}*a_{3}^2+m_{6}*d_{4}^2+m_{6}*l_{6,z}^2+I_{6,xx}</math>
|kg*m^2
|-
|7
|<math>I_{7} = m_{3}*l_{3,y}^2+I_{3,xx}-I_{3,yy}+m_{4}*l_{4,z}^2+2*m_{4}*d_{4}*l_{4,z}+(m_{4}+m_{5}+m_{6})*(d_{4}^2-a_{3}^2)+I_{4,yy}-I_{4,yy}+I_{5,zz}-I_{5,yy}+m_{6}*l_{6,z}^2-I_{6,zz}+I_{6,xx}</math>
|kg*m^2
|-
|8
|<math>I_{8} = -m_{4}*(d_{2}+d_{3})*(d_{4}+l_{4,z})-(m_{3}+m_{6})*(d_{2}+d_{3})*d_{4}+m_{3}*l_{3,y}*l_{3,z}+m_{3}*(d_{2}+d_{3})*l_{3,y}</math>
|kg*m^2
|-
|9
|<math>I_{9} = m_{2}*l_{2,y}*(d_{2}+l_{2,z})</math>
|kg*m^2
|-
|10
|<math>I_{10} = 2*m_{4}*a_{5}*l_{4,z}+2*(m_{4}+m_{5}+m_{6})*a_{3}*d_{4}</math>
|kg*m^2
|-
|11
|<math>I_{11} = -2*m_{2}*l_{2,x}*l_{2,y}</math>
|kg*m^2
|-
|12
|<math>I_{12} = (m_{4}+m_{5}+m_{6})*a_{2}*a_{3}</math>
|kg*m^2
|-
|13
|<math>I_{13} = (m_{4}+m_{5}+m_{6})*a_{3}*(d_{2}+d_{3})</math>
|kg*m^2
|-
|14
|<math>I_{14} = I_{4,zz}+I_{5,yy}+I_{6,zz}</math>
|kg*m^2
|-
|15
|<math>I_{15} = m_{6}*d_{4}*l_{6,z}</math>
|kg*m^2
|-
|16
|<math>I_{16} = m_{6}*a_{2}*l_{6,z}</math>
|kg*m^2
|-
|17
|<math>I_{17} = I_{5,zz}+I_{6,xx}+m_{6}*l_{6,z}^2</math>
|kg*m^2
|-
|18
|<math>I_{18} = m_{6}*(d_{2}+d_{3})*l_{6,z}</math>
|kg*m^2
|-
|19
|<math>I_{19} = I_{4,yy}-I_{4,xx}+I_{5,zz}-i_{5,yy}+m_{6}*l_{6,z}^2+I_{6,xx}-I_{6,zz}</math>
|kg*m^2
|-
|20
|<math>I_{20} = I_{5,yy}-I_{5,xx}-m_{6}*l_{6,z}^2+I_{6,zz}-I_{6,xx}</math>
|kg*m^2
|-
|21
|<math>I_{21} = I_{4,xx}-I_{4,yy}+I_{5,xx}-I_{5,zz}</math>
|kg*m^2
|-
|22
|<math>I_{22} = m_{6}*a_{3}*l_{6,z}</math>
|kg*m^2
|-
|23
|<math>I_{23} = I_{6,zz}</math>
|kg*m^2
|}

=== Dynamic Model 2 - Gravity ===
This dynamic model is for cases where the robot moves very slowly. 
In such cases, the accelerations and velocities of the joints of the robot have little effect on the joints torques. The joints torques are mainly affected by gravity and friction. 
This model includes only the gravity and friction part of the PUMA robot dynamic model. 

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>g(m_{2}l_{2}+a_{2}(m_{3}+m_{4}+m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|2
|<math>g(m_{3}l_{3,y}+a_{3}(m_{4}+m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|3
|<math>g(m_{3}l_{3,y}+m_{4}(l_{4}+d_{4}(m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|4
|<math>gl_{56}(m_{5}+m_{6})</math>
|kg*m^2/s^2

|}

== Galileo Spherical Robots (GSR) ==

=== Dynamic Model 1 ===

[[File:GSR-SETUP.JPG|Galileo robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|mP
|Payload mass [kg]
|-
|2
|mB
|Balance mass [kg]
|-
|3
|TP
|Payload mass center distance from the flange [mm]
|-
|4
|TB
|Balance mass center distance from the (0,0) [mm]
|-
|5
|IR
|Inertia of the payload around roll [kg*m2
|}

[[Category:Motion Dynamics]]

Dynamic Models

2019-09-11T05:19:57Z

Itay:

This page gives an overview over all implemented dynamic models.

'''General considerations'''
* Friction is handled on axis basis. The parameters for friction are set for each axis separately.
* Torque (Force) is always expressed in '''[Nm]''' ([N]) 

== Rotational Axes ==

=== Dynamic Model 1 - simple rotary axis ===
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|}
;Model equation
: <math>T = (I + I_{payload}) \cdot acc</math>

 
=== Dynamic Model 2 - horizontal crank-arm axis ===
[[File:Axystems;Motion Dynamics - Horizontal Crank-Arm Axis.png|Horizontal crank-arm axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|-
|2
|<math>L^2</math>
|Square of length of crank arm (axis to payload)
|}
;Model equation
: <math>T = (I + I_{payload} + L^2 \cdot M_{payload}) \cdot acc</math>

 
=== Dynamic Model 3 - vertical crank-arm axis ===
[[File:Axystems;Motion Dynamics - Vertical Crank-Arm Axis.png|Vertical crank-arm axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|-
|2
|<math>L^2</math>
|Square of length of crank arm (axis to payload)
|-
|3
|<math>M \cdot g \cdot A</math>
|Mass (without payload) * Gravity * Distance to center of mass
|-
|4
|<math>g \cdot L</math>
|Gravity * Distance to Payload
|}
;Model equation
: <math>T = (I + I_{payload} + L^2 \cdot M_{payload}) \cdot acc - (M \cdot g \cdot A + M_{payload} \cdot g \cdot L) \cdot \sin(pos)</math>

== Linear Axes ==

=== Dynamic Model 1 - horizontal axis ===
[[File:Axystems;Motion Dynamics - Horizontal Axis.png|Horizontal linear axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part.
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot acc</math>

 
=== Dynamic Model 2 - vertical or tilted axis ===
[[File:Axystems;Motion Dynamics - Vertical Axis.png|Vertical linear axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part.
|-
|2
|<math>M \cdot g \cdot \cos(\alpha)</math>
|Constant force due to gravity.
|-
|3
|<math>g \cdot \cos(\alpha)</math>
|Gravity coefficient used to consider payload mass. ('''g = 9.80665''')
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot acc + M \cdot g \cdot \cos(\alpha) + M_{payload} \cdot g \cdot \cos(\alpha)</math>

 
=== Dynamic Model 3 - vertical axis with a spring ===
[[File:Axystems;Motion_Dynamics_-_Vertical_Axis_with_spring.png|Vertical linear axis with a spring|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part. [kg]
|-
|2
|<math>K</math>
|The stiffness constant of the spring. [kg/s^2]
|-
|3
|<math>K \cdot X_{0}</math>
|The stiffness constant times the relaxation position of the spring. [kg*m/s^2]
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot (acc + g) + K\cdot (X-X_{0})</math>

== Traverse Arm Robots ==

=== Dynamic Model 1 ===
[[File:Inverse dynamic model for Traverse Arm kinematics - Definitions.png|Traverse Arm robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M_1 + M_2</math>
|-
|2
|<math>A_2 \cdot M_2</math>
|-
|3
|<math>A_2^2 \cdot M_2 + I_2</math>
|-
|4
|<math>M_3</math>
|-
|5
|<math>g \cdot M_3</math>
|-
|6
|<math>I_4</math>
|-
|7
|<math>J_4</math>
|}

== Scara Robots ==

=== Dynamic Model 1 ===
[[File:scara.PNG|scara robot|thumb]]
For non-coupled SCARA robots (axis 3 and 4 are not coupled). 
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>L_1^2 \cdot M_2 + I_1</math>
|-
|2
|<math>A_2^2 \cdot M_2 + I_2</math>
|-
|3
|<math>J_2</math>
|-
|4
|<math>L_1 \cdot A_2 \cdot M_2</math>
|-
|5
|<math>M_3</math>
|-
|6
|<math>g \cdot M_3</math>
|-
|7
|<math>I_4</math>
|-
|8
|<math>J_4</math>
|}

=== Dynamic Model 2 ===
For coupled SCARA robots (axis 3 and 4 are coupled) and for concentric payloads (concentric with axis 4). 
Note: <math>M_3</math> includes both the masses of link 3 and link 4 
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|9
|<math>L_1^2 \cdot (M_2+M_3) + I_1 + J_1</math>
|-
|10
|<math>A_2^2 \cdot M_2 + L_2^2 \cdot M_3 + I_2</math>
|-
|11
|<math>L_1 \cdot A_2 \cdot M_2 + L_1 \cdot L_2 \cdot M_3</math>
|-
|12
|<math>M_3</math>
|-
|13
|<math>I_4</math>
|-
|14
|<math>J_2</math>
|-
|15
|<math>J_3</math>
|-
|16
|<math>J_4</math>
|}

The payload parameters are:
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|payloadMass
|The mass of the payload
|-
|2
|payloadInertia
|The Inertia of the payload relative to its center of mass
|}

=== Dynamic Model 3 ===
For coupled SCARA robots (axis 3 and 4 are coupled) and for non-concentric payloads (non-concentric with axis 4). 
The dynamic parameters are the same as model 2. 

The payload parameters are:
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|payloadMass
|The mass of the payload
|-
|2
|payloadInertia
|The Inertia of the payload relative to its center of mass
|-
|4
|payloadLx
|The distance to the center of mass from the 4th axis in the x direction
|}

When using identification with this model, all of the payload parameters can be found. 

=== Dynamic Model 4 ===

Same as Dynamic Model 3. This model is used in identification process in order to identify the payloadMass parameter only, by moving only joint number 3.

=== Dynamic Model 5 ===
Same as Dynamic Model 3. 
This model is used in identification process in order to identify the payloadInertia and payloadLx parameters, by moving only joint number 4 and very small movements in joints 1 and 2. 

== Delta Robots ==

=== Dynamic Model 1 ===
[[File:Control;Rod forces model for Delta kinematics - Introduction.png|Delta robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>\Theta_{AB}</math>
|kg*m2
|-
|2
|<math>g \cdot L_{AB} \cdot M_{AB}</math>
| kg*m2/sec2
|-
|3
|<math>M_{BC}</math>
|kg
|-
|4
|<math>\Theta_{BC}</math>
|kg*m2
|-
|5
|<math>M_P</math>
|kg
|-
|6
|<math>M_T</math>
|kg
|-
|7
|<math>\Theta_T</math>
|kg*m2
|-
|8
|<math>\Theta_{T\phi}</math>
|kg*m2
|-
|9
|<math>L_{TO}</math>
| m
|-
|10
|<math>L_{TP}</math>
| m
|-
|11
|<math>D</math>
|-
|12
|<math>C_r</math>
|-
|13
|<math>Fr_{max}</math>
|-
|14
|<math>R_{ext}</math>
|}

== Puma Robots ==
=== Dynamic Model 1 ===
[[File:puma.PNG|Puma robot|thumb]]

Description:
:* <math> g </math> - Gravity constant
:* <math> m_{i} </math> - Mass of the ith link
:* <math> a_{i} </math> - length of the common normal between the ith and ith+1 joints
:* <math> d_{i} </math> - offset along z axis between the ith and ith+1 joints
:* <math> l_{i} </math> - The distance from the ith joint to the center of mass of the ith link

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I_{1} = I_{1,zz}+m_{1}*l_{1,y}^2 +m_{2}*d_{2}^2+(m_{4}+m_{5}+m_{6})*a_{3}^2+m_{2}*l_{2,z}^2+</math> <math>(m_{3}+m_{4}+m_{5}+m_{6})*(d_{2}+d_{3})^2+I_{2,xx}+I_{3,yy}+2*m_{2}*d_{2}*l_{2,z}+m_{2}*l_{2,y}^2+m_{3}*l_{3,z}^2+2*m_{3}*(d_{2}+d_{3})*l_{3,z}+I_{4,zz}+I_{4,yy}+I_{6,zz}</math>
|kg*m^2
|-
|2
|<math>I_{2} = I_{2,zz}+m_{2}*(l_{2,x}^2+l_{2,y}^2)+(m_{3}+m_{4}+m_{5}+m_{6}*a_{2}^2</math>
|kg*m^2
|-
|3
|<math>I_{3} = -I_{2,xx}+I_{2,yy}+(m_{3}+m_{4}+m_{5}+m_{6})*a_{2}^2+m_{2}*l_{2,x}^2-m_{2}*l_{2,y}^2</math>
|kg*m^2
|-
|4
|<math>I_{4} = m_{2}*l_{2,x}*(d_{2}+l_{2,z})+m_{3}*a_{2}*l_{3,z}+(m_{3}+m_{4}+m_{5}+m_{6})*a_{2}*(d_{2}+d_{3})</math>
|kg*m^2
|-
|5
|<math>I_{5} = -m_{3}*a_{2}*l_{3,y}+(m_{4}+m_{5}+m_{6})*a_{2}*d_{4}+m_{4}*a_{2}*l_{4,z}</math>
|kg*m^2
|-
|6
|<math>I_{6} = I_{3,zz}+m_{3}*l_{3,y}^2+m_{4}*a_{3}^2+m_{4}*(d_{4}+l_{4,z})^2+I_{4,yy}+m_{5}*a_{3}^2+m_{5}*d_{4}^2+I_{5,zz}+m_{6}*a_{3}^2+m_{6}*d_{4}^2+m_{6}*l_{6,z}^2+I_{6,xx}</math>
|kg*m^2
|-
|7
|<math>I_{7} = m_{3}*l_{3,y}^2+I_{3,xx}-I_{3,yy}+m_{4}*l_{4,z}^2+2*m_{4}*d_{4}*l_{4,z}+(m_{4}+m_{5}+m_{6})*(d_{4}^2-a_{3}^2)+I_{4,yy}-I_{4,yy}+I_{5,zz}-I_{5,yy}+m_{6}*l_{6,z}^2-I_{6,zz}+I_{6,xx}</math>
|kg*m^2
|-
|8
|<math>I_{8} = -m_{4}*(d_{2}+d_{3})*(d_{4}+l_{4,z})-(m_{3}+m_{6})*(d_{2}+d_{3})*d_{4}+m_{3}*l_{3,y}*l_{3,z}+m_{3}*(d_{2}+d_{3})*l_{3,y}</math>
|kg*m^2
|-
|9
|<math>I_{9} = m_{2}*l_{2,y}*(d_{2}+l_{2,z})</math>
|kg*m^2
|-
|10
|<math>I_{10} = 2*m_{4}*a_{5}*l_{4,z}+2*(m_{4}+m_{5}+m_{6})*a_{3}*d_{4}</math>
|kg*m^2
|-
|11
|<math>I_{11} = -2*m_{2}*l_{2,x}*l_{2,y}</math>
|kg*m^2
|-
|12
|<math>I_{12} = (m_{4}+m_{5}+m_{6})*a_{2}*a_{3}</math>
|kg*m^2
|-
|13
|<math>I_{13} = (m_{4}+m_{5}+m_{6})*a_{3}*(d_{2}+d_{3})</math>
|kg*m^2
|-
|14
|<math>I_{14} = I_{4,zz}+I_{5,yy}+I_{6,zz}</math>
|kg*m^2
|-
|15
|<math>I_{15} = m_{6}*d_{4}*l_{6,z}</math>
|kg*m^2
|-
|16
|<math>I_{16} = m_{6}*a_{2}*l_{6,z}</math>
|kg*m^2
|-
|17
|<math>I_{17} = I_{5,zz}+I_{6,xx}+m_{6}*l_{6,z}^2</math>
|kg*m^2
|-
|18
|<math>I_{18} = m_{6}*(d_{2}+d_{3})*l_{6,z}</math>
|kg*m^2
|-
|19
|<math>I_{19} = I_{4,yy}-I_{4,xx}+I_{5,zz}-i_{5,yy}+m_{6}*l_{6,z}^2+I_{6,xx}-I_{6,zz}</math>
|kg*m^2
|-
|20
|<math>I_{20} = I_{5,yy}-I_{5,xx}-m_{6}*l_{6,z}^2+I_{6,zz}-I_{6,xx}</math>
|kg*m^2
|-
|21
|<math>I_{21} = I_{4,xx}-I_{4,yy}+I_{5,xx}-I_{5,zz}</math>
|kg*m^2
|-
|22
|<math>I_{22} = m_{6}*a_{3}*l_{6,z}</math>
|kg*m^2
|-
|23
|<math>I_{23} = I_{6,zz}</math>
|kg*m^2
|}

=== Dynamic Model 2 - Gravity ===
This dynamic model is for cases where the robot moves very slowly. 
In such cases, the accelerations and velocities of the joints of the robot have little effect on the joints torques. The joints torques are mainly affected by gravity and friction. 
This model includes only the gravity and friction part of the PUMA robot dynamic model. 

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>g(m_{2}l_{2}+a_{2}(m_{3}+m_{4}+m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|2
|<math>g(m_{3}l_{3,y}+a_{3}(m_{4}+m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|3
|<math>g(m_{3}l_{3,y}+m_{4}(l_{4}+d_{4}(m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|4
|<math>gl_{56}(m_{5}+m_{6})</math>
|kg*m^2/s^2

|}

== Galileo Spherical Robots (GSR) ==

=== Dynamic Model 1 ===

[[File:GSR-SETUP.JPG|Galileo robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|mP
|Payload mass [kg]
|-
|2
|mB
|Balance mass [kg]
|-
|3
|TP
|Payload mass center distance from the flange [mm]
|-
|4
|TB
|Balance mass center distance from the (0,0) [mm]
|-
|5
|IR
|Inertia of the payload around roll [kg*m2
|}

[[Category:Motion Dynamics]]

Dynamic Models

2019-09-10T08:22:20Z

Itay:

This page gives an overview over all implemented dynamic models.

'''General considerations'''
* Friction is handled on axis basis. The parameters for friction are set for each axis separately.
* Torque (Force) is always expressed in '''[Nm]''' ([N]) 

== Rotational Axes ==

=== Dynamic Model 1 - simple rotary axis ===
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|}
;Model equation
: <math>T = (I + I_{payload}) \cdot acc</math>

 
=== Dynamic Model 2 - horizontal crank-arm axis ===
[[File:Axystems;Motion Dynamics - Horizontal Crank-Arm Axis.png|Horizontal crank-arm axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|-
|2
|<math>L^2</math>
|Square of length of crank arm (axis to payload)
|}
;Model equation
: <math>T = (I + I_{payload} + L^2 \cdot M_{payload}) \cdot acc</math>

 
=== Dynamic Model 3 - vertical crank-arm axis ===
[[File:Axystems;Motion Dynamics - Vertical Crank-Arm Axis.png|Vertical crank-arm axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|-
|2
|<math>L^2</math>
|Square of length of crank arm (axis to payload)
|-
|3
|<math>M \cdot g \cdot A</math>
|Mass (without payload) * Gravity * Distance to center of mass
|-
|4
|<math>g \cdot L</math>
|Gravity * Distance to Payload
|}
;Model equation
: <math>T = (I + I_{payload} + L^2 \cdot M_{payload}) \cdot acc - (M \cdot g \cdot A + M_{payload} \cdot g \cdot L) \cdot \sin(pos)</math>

== Linear Axes ==

=== Dynamic Model 1 - horizontal axis ===
[[File:Axystems;Motion Dynamics - Horizontal Axis.png|Horizontal linear axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part.
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot acc</math>

 
=== Dynamic Model 2 - vertical or tilted axis ===
[[File:Axystems;Motion Dynamics - Vertical Axis.png|Vertical linear axis|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part.
|-
|2
|<math>M \cdot g \cdot \cos(\alpha)</math>
|Constant force due to gravity.
|-
|3
|<math>g \cdot \cos(\alpha)</math>
|Gravity coefficient used to consider payload mass. ('''g = 9.80665''')
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot acc + M \cdot g \cdot \cos(\alpha) + M_{payload} \cdot g \cdot \cos(\alpha)</math>

 
=== Dynamic Model 3 - vertical axis with a spring ===
[[File:Axystems;Motion_Dynamics_-_Vertical_Axis_with_spring.png|Vertical linear axis with a spring|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part. [kg]
|-
|2
|<math>K</math>
|The stiffness constant of the spring. [kg/s^2]
|-
|3
|<math>K \cdot X_{0}</math>
|The stiffness constant times the relaxation position of the spring. [kg*m/s^2]
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot (acc + g) + K\cdot (X-X_{0})</math>

== Traverse Arm Robots ==

=== Dynamic Model 1 ===
[[File:Inverse dynamic model for Traverse Arm kinematics - Definitions.png|Traverse Arm robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M_1 + M_2</math>
|-
|2
|<math>A_2 \cdot M_2</math>
|-
|3
|<math>A_2^2 \cdot M_2 + I_2</math>
|-
|4
|<math>M_3</math>
|-
|5
|<math>g \cdot M_3</math>
|-
|6
|<math>I_4</math>
|-
|7
|<math>J_4</math>
|}

== Scara Robots ==

=== Dynamic Model 1 ===
[[File:scara.PNG|scara robot|thumb]]
For non-coupled SCARA robots (axis 3 and 4 are not coupled). 
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>L_1^2 \cdot M_2 + I_1</math>
|-
|2
|<math>A_2^2 \cdot M_2 + I_2</math>
|-
|3
|<math>J_2</math>
|-
|4
|<math>L_1 \cdot A_2 \cdot M_2</math>
|-
|5
|<math>M_3</math>
|-
|6
|<math>g \cdot M_3</math>
|-
|7
|<math>I_4</math>
|-
|8
|<math>J_4</math>
|}

=== Dynamic Model 2 ===
For coupled SCARA robots (axis 3 and 4 are coupled) and for concentric payloads (concentric with axis 4). 
Note: <math>M_3</math> includes both the masses of link 3 and link 4 
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|9
|<math>L_1^2 \cdot (M_2+M_3) + I_1 + J_1</math>
|-
|10
|<math>A_2^2 \cdot M_2 + L_2^2 \cdot M_3 + I_2</math>
|-
|11
|<math>L_1 \cdot A_2 \cdot M_2 + L_1 \cdot L_2 \cdot M_3</math>
|-
|12
|<math>M_3</math>
|-
|13
|<math>I_4</math>
|-
|14
|<math>J_2</math>
|-
|15
|<math>J_3</math>
|-
|16
|<math>J_4</math>
|}

The payload parameters are:
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|payloadMass
|The mass of the payload
|-
|2
|payloadInertia
|The Inertia of the payload relative to its center of mass
|}

=== Dynamic Model 3 ===
For coupled SCARA robots (axis 3 and 4 are coupled) and for non-concentric payloads (non-concentric with axis 4). 
The dynamic parameters are the same as model 2. 

The payload parameters are:
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|payloadMass
|The mass of the payload
|-
|2
|payloadInertia
|The Inertia of the payload relative to its center of mass
|-
|4
|payloadLx
|The distance to the center of mass from the 4th axis in the x direction
|}

When using identification with this model, all of the payload parameters can be found. 

=== Dynamic Model 4 ===

Same as Dynamic Model 3. This model is used in identification process in order to identify the payloadMass parameter only, by moving only joints number 3 and 4.

=== Dynamic Model 5 ===
Same as Dynamic Model 3. 
This model is used in identification process in order to identify the payloadInertia and payloadLx parameters, by moving only joint number 4 and very small movements in joints 1 and 2. 

== Delta Robots ==

=== Dynamic Model 1 ===
[[File:Control;Rod forces model for Delta kinematics - Introduction.png|Delta robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>\Theta_{AB}</math>
|kg*m2
|-
|2
|<math>g \cdot L_{AB} \cdot M_{AB}</math>
| kg*m2/sec2
|-
|3
|<math>M_{BC}</math>
|kg
|-
|4
|<math>\Theta_{BC}</math>
|kg*m2
|-
|5
|<math>M_P</math>
|kg
|-
|6
|<math>M_T</math>
|kg
|-
|7
|<math>\Theta_T</math>
|kg*m2
|-
|8
|<math>\Theta_{T\phi}</math>
|kg*m2
|-
|9
|<math>L_{TO}</math>
| m
|-
|10
|<math>L_{TP}</math>
| m
|-
|11
|<math>D</math>
|-
|12
|<math>C_r</math>
|-
|13
|<math>Fr_{max}</math>
|-
|14
|<math>R_{ext}</math>
|}

== Puma Robots ==
=== Dynamic Model 1 ===
[[File:puma.PNG|Puma robot|thumb]]

Description:
:* <math> g </math> - Gravity constant
:* <math> m_{i} </math> - Mass of the ith link
:* <math> a_{i} </math> - length of the common normal between the ith and ith+1 joints
:* <math> d_{i} </math> - offset along z axis between the ith and ith+1 joints
:* <math> l_{i} </math> - The distance from the ith joint to the center of mass of the ith link

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I_{1} = I_{1,zz}+m_{1}*l_{1,y}^2 +m_{2}*d_{2}^2+(m_{4}+m_{5}+m_{6})*a_{3}^2+m_{2}*l_{2,z}^2+</math> <math>(m_{3}+m_{4}+m_{5}+m_{6})*(d_{2}+d_{3})^2+I_{2,xx}+I_{3,yy}+2*m_{2}*d_{2}*l_{2,z}+m_{2}*l_{2,y}^2+m_{3}*l_{3,z}^2+2*m_{3}*(d_{2}+d_{3})*l_{3,z}+I_{4,zz}+I_{4,yy}+I_{6,zz}</math>
|kg*m^2
|-
|2
|<math>I_{2} = I_{2,zz}+m_{2}*(l_{2,x}^2+l_{2,y}^2)+(m_{3}+m_{4}+m_{5}+m_{6}*a_{2}^2</math>
|kg*m^2
|-
|3
|<math>I_{3} = -I_{2,xx}+I_{2,yy}+(m_{3}+m_{4}+m_{5}+m_{6})*a_{2}^2+m_{2}*l_{2,x}^2-m_{2}*l_{2,y}^2</math>
|kg*m^2
|-
|4
|<math>I_{4} = m_{2}*l_{2,x}*(d_{2}+l_{2,z})+m_{3}*a_{2}*l_{3,z}+(m_{3}+m_{4}+m_{5}+m_{6})*a_{2}*(d_{2}+d_{3})</math>
|kg*m^2
|-
|5
|<math>I_{5} = -m_{3}*a_{2}*l_{3,y}+(m_{4}+m_{5}+m_{6})*a_{2}*d_{4}+m_{4}*a_{2}*l_{4,z}</math>
|kg*m^2
|-
|6
|<math>I_{6} = I_{3,zz}+m_{3}*l_{3,y}^2+m_{4}*a_{3}^2+m_{4}*(d_{4}+l_{4,z})^2+I_{4,yy}+m_{5}*a_{3}^2+m_{5}*d_{4}^2+I_{5,zz}+m_{6}*a_{3}^2+m_{6}*d_{4}^2+m_{6}*l_{6,z}^2+I_{6,xx}</math>
|kg*m^2
|-
|7
|<math>I_{7} = m_{3}*l_{3,y}^2+I_{3,xx}-I_{3,yy}+m_{4}*l_{4,z}^2+2*m_{4}*d_{4}*l_{4,z}+(m_{4}+m_{5}+m_{6})*(d_{4}^2-a_{3}^2)+I_{4,yy}-I_{4,yy}+I_{5,zz}-I_{5,yy}+m_{6}*l_{6,z}^2-I_{6,zz}+I_{6,xx}</math>
|kg*m^2
|-
|8
|<math>I_{8} = -m_{4}*(d_{2}+d_{3})*(d_{4}+l_{4,z})-(m_{3}+m_{6})*(d_{2}+d_{3})*d_{4}+m_{3}*l_{3,y}*l_{3,z}+m_{3}*(d_{2}+d_{3})*l_{3,y}</math>
|kg*m^2
|-
|9
|<math>I_{9} = m_{2}*l_{2,y}*(d_{2}+l_{2,z})</math>
|kg*m^2
|-
|10
|<math>I_{10} = 2*m_{4}*a_{5}*l_{4,z}+2*(m_{4}+m_{5}+m_{6})*a_{3}*d_{4}</math>
|kg*m^2
|-
|11
|<math>I_{11} = -2*m_{2}*l_{2,x}*l_{2,y}</math>
|kg*m^2
|-
|12
|<math>I_{12} = (m_{4}+m_{5}+m_{6})*a_{2}*a_{3}</math>
|kg*m^2
|-
|13
|<math>I_{13} = (m_{4}+m_{5}+m_{6})*a_{3}*(d_{2}+d_{3})</math>
|kg*m^2
|-
|14
|<math>I_{14} = I_{4,zz}+I_{5,yy}+I_{6,zz}</math>
|kg*m^2
|-
|15
|<math>I_{15} = m_{6}*d_{4}*l_{6,z}</math>
|kg*m^2
|-
|16
|<math>I_{16} = m_{6}*a_{2}*l_{6,z}</math>
|kg*m^2
|-
|17
|<math>I_{17} = I_{5,zz}+I_{6,xx}+m_{6}*l_{6,z}^2</math>
|kg*m^2
|-
|18
|<math>I_{18} = m_{6}*(d_{2}+d_{3})*l_{6,z}</math>
|kg*m^2
|-
|19
|<math>I_{19} = I_{4,yy}-I_{4,xx}+I_{5,zz}-i_{5,yy}+m_{6}*l_{6,z}^2+I_{6,xx}-I_{6,zz}</math>
|kg*m^2
|-
|20
|<math>I_{20} = I_{5,yy}-I_{5,xx}-m_{6}*l_{6,z}^2+I_{6,zz}-I_{6,xx}</math>
|kg*m^2
|-
|21
|<math>I_{21} = I_{4,xx}-I_{4,yy}+I_{5,xx}-I_{5,zz}</math>
|kg*m^2
|-
|22
|<math>I_{22} = m_{6}*a_{3}*l_{6,z}</math>
|kg*m^2
|-
|23
|<math>I_{23} = I_{6,zz}</math>
|kg*m^2
|}

=== Dynamic Model 2 - Gravity ===
This dynamic model is for cases where the robot moves very slowly. 
In such cases, the accelerations and velocities of the joints of the robot have little effect on the joints torques. The joints torques are mainly affected by gravity and friction. 
This model includes only the gravity and friction part of the PUMA robot dynamic model. 

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>g(m_{2}l_{2}+a_{2}(m_{3}+m_{4}+m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|2
|<math>g(m_{3}l_{3,y}+a_{3}(m_{4}+m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|3
|<math>g(m_{3}l_{3,y}+m_{4}(l_{4}+d_{4}(m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|4
|<math>gl_{56}(m_{5}+m_{6})</math>
|kg*m^2/s^2

|}

== Galileo Spherical Robots (GSR) ==

=== Dynamic Model 1 ===

[[File:GSR-SETUP.JPG|Galileo robot|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|mP
|Payload mass [kg]
|-
|2
|mB
|Balance mass [kg]
|-
|3
|TP
|Payload mass center distance from the flange [mm]
|-
|4
|TB
|Balance mass center distance from the (0,0) [mm]
|-
|5
|IR
|Inertia of the payload around roll [kg*m2
|}

[[Category:Motion Dynamics]]

MediaWiki:Sidebar

2018-08-26T07:34:57Z

Itay:

MediaWiki:Sidebar

2018-08-26T07:34:28Z

Itay: add RoboDK to the sidebar

Inverse Dynamic Model

2018-08-22T14:49:15Z

Itay: /* Rotary motors with lead screws / pulleys / or different type of mechanism used to translate turning motion into linear motion */

{{Languages|Inverse_Dynamic_Model}}
<div id="BackToTop" class="noprint" style="background-color:; position:fixed; bottom:32px; left:95%; z-index:9999; padding:0; margin:0;">

[[Image:TOP2.png|50px|link=#top]] </div>

=Introduction - what is it good for and how does it work=

The inverse dynamic model (IDM) feature is used to compensate friction and dynamic effects for motion elements, otherwise leading to positioning errors and suboptimal settling and tracking behavior.

The motivation of the IDM feature is to use additional knowledge about the motion than just the position – i.e. velocity and torque – to offset the command values of the torque controller in order to make them react faster and thereby reduce the final positioning error and improve the settling behavior.

The term ''inverse dynamic model'' (often named computed torque control) means that the softMC takes a cartesian motion of a motion element and not only computes the joint position for the next Cartesian setpoint, but also the joint torque required for the motion. In order to be able to do that, it needs a dynamic model – i.e., a model of the masses and inertias – of the motion element. The joint velocity and torque are then sent to the drives as additional torque command data (see Figure 1).

In most cases, the user doesn’t have the parameters of the dynamic model. In such cases, those parameters can be estimated using the softMC identification process. The softMC allows to perform measurements and estimate the dynamic model parameters of some common robot models. The identification process is performed as follows: while the robot is commanded to perform a certain movement, the movement parameters and internal motors torques are recorded. Then, the dynamic model parameters of the robot are extracted based on the robot model and the measurements.

[[file:DM_1.png|center|650px|frame|<center><big>''Figure 1 - A schematic drawing of the control system and the feedforward part of the Taddcmd''</big></center>]]

=Torque Units=
The MKS system of units defines the torque unit as [Nm] (Newton*meter). When dealing with motors, the torque is usually modeled as proportional to the current in the motors. Therefore, the torque can be defined with different units in each system. This section describes the torque units for each system and how they relate to each other.

The softMC reads the motor's torque through the drives, but not in [Nm] units. Therefore, the softMC contains an axis property called TorqueFactor (TFac) which divides the motor's torque parameter in order to convert it to desirable units. The result of this operation is stored in an axis property called [[MC-Basic:element.TORQUEFEEDBACK| TorqueFeedback]].

==CDHD Drive setup==
The CDHD drives have the following parameters to define the motor's current properties:
* '''MICONT''' – in units of Ampere [A], but being read in units of milli-Ampere [mA], defines the motor continuous current. This is the maximum allowed value for long operation cycles.
* '''MIPEAK''' – in units of Ampere [A], but being read in units of milli-Ampere [mA], defines the motor peak current. This is the maximum allowed value for very short operation cycles.
* '''MKT''' – for rotary motors, being read in units of [Nm/A], defines the torque constant, i.e. how much torque the motor gives per Ampere unit.
* '''MKF''' – for linear motors, being read in units of [N/A], defines the force constant, i.e. how much force the motor gives per Ampere unit.
* '''I''' – being read in units of milli-MICONT [0.001*MICONT]. It indicates the actual value of the current. It corresponds to the current in the motor.

The TorqueFeedback property is calculated as follows: 
<center> <math> TFb = \frac{Current Actual Value}{Tfac}\ </math> </center>

Therefore, the TorqueFactor property should be set appropriately in order to convert the TorqueFeedback value to units of [Nm]: 
<center> <math> TFac = \frac{1000000}{MKT*MICONT}\ </math> </center>

The 1 million is in order to compensate for the MICONT being in units of [mA] and the Current Actual Value being in units of [0.001*MICONT]. Defining the TorqueFactor this way will convert the Current Actual Value to unit of [Nm] (and the value is assigned to TorqueFeedback). After setting Tfac, all values of torque (Tfb,TCmd,Tmax, TorqueThreshold, Te) will always be in units of [Nm] ([N] for linear axes). An example for this calculation in MC-Basic is presented in Figure 2.

==EtherCAT and CANopen standart (DS402)==
The EtherCAT standard defines the following parameters which are equivalent to the above parameters:

{|class="wikitable" style="text-align: center"
!CDHD parameter
!EtherCAT parameter
!EtherCat index
|-
|MICONT
|Motor Rated Current
|0x6075
|-
|MIPEAK
|Motor Peak Current
|0x2036
|-
|MKT
|Torque Constant
|0x2039
|-
|MKF
|Torque Constant for Linear Motors
|0x2038
|-
|I
|Current Actual Value
|0x6078

|}

==softMC torque related properties==

The softMC has the following torque related properties:

* '''''<axis>''.TorqueMax''' 
* '''''<axis>''.TorqueThreshold''' 

These parameters are used to define the limit of the '''TADDCOMMAND''' value. 
The difference between those parameters is that '''TorqueMax''' is taken into account when the motion is being planned and '''TorqueThreshold''' limits the torque feedback. 
For example, if the planned motion exceeds TorqueMax, then an error will be thrown before the motion has started. However, if the planned motion is O.K, and the axis/robot started the motion, if the torque feedback crosses the TorqueThreshold, the robot motion will be stopped and an error will be thrown. 
One can set these parameters to some user desired value, or to a value matching the drive MICONT or MIPEAK values. 

For example, setting the TorqueThreshold to a value that matches '''MICONT''': 
<center> <math> <axis>.TorqueThreshold = \frac{1000}{TFac}\ </math> </center>

Setting the TorqueThreshold to a value that matches '''MIPEAK''':
<center> <math> TorqueThreshold=\frac{1000*MIPEAK}{TFac*MICONT}\ </math> </center>

* '''''<axis>''.AdditiveTorqueDelay''' - The calculated additive torque command is based on ''pcmd'' and ''vcmd''. Since there is a delay between the commands and the actual position and velocity of the axis, the same delay should be presented to the additive torque. The '''AdditiveTorqueDelay''' is used for this purpose. This property is in units of cycle time and it accepts positive integer values. The '''AdditiveTorqueDelay''' works as follows: the calculated additive torque command for a certain time would be sent to the drives only “AdditiveTorqueDelay” steps later. The default value of this property is 3.

==How to include gear ratio==

Usually, the motors are connected to the joints through a gear system. The gear system affects the torque loads the motors carry and therefore the torque factors should be compensated appropriately. After this compensation, the TorqueFactor parameter transforms the Current Actual Value parameter from current inside the motors ([mMICONT] units) to the torques the joints are carrying (in [Nm] units).
<center> <math> TFac = \frac{1000000}{MKT*MICONT*GR}\ </math></center>

where GR stands for Gear Ratio. Figure 3 shows an example of a gear ratio.

[[file:DM 2.png|80px|frame|left|<big><center> ''figure 2 - Setting the torque factor(TFac) property for all axes in MC-Basic for WtherCAT drive''</center></big>]]

[[file:DM 3.png|150px|frame|left|<big><center> ''figure 3 - An example of a gear mechanism with a ratio of 1:2''</center></big>]]
==Linear Axes==
All of the above refers to rotary axes. Linear axes, in contrast to rotary axes, carry force and not torque. These forces are measured in units of Newton [N]. Therefore, some modifications should be made when dealing with Linear axes. Basically, there are two types of linear axes - Rotary motors with lead screws/pulleys/others, and Linear Motors.

===Rotary motors with lead screws / pulleys / or different type of mechanism used to translate turning motion into linear motion===
This type is treated the same as the regular rotary axes with a single modification. The mechanism used to translate turning motion into linear motion transforms the torque load, carried by the motor, to a force load on the linear axis. Therefore, the TorqueFactor should be multiplied by another factor. This parameter should contain the ratio between the amount of linear motion made per one rotation of the rotary motor (after the gear). For a lead screw, it would be the Screw Lead [mm/rev]. For a pulley, it would be the radius of the pulley multiplied by 2π [mm/rev]. The TorqueFactor would be: 

<center> <math> TFac = \frac{1000000*SL}{MKT*MICONT*GR*\pi} </math></center>

Where '''SL''' stands for Screw Lead or an equivalent parameter. figure 4 shows an example of a lead-screw lead. 
'''NOTE:''' '''SL''' is in units of [m/rev] -> meters per revolution. 

[[file: DM_4.png|center|300px|frame|<big><center>''figure 4 - An example of a lead-screw (top) and a lead-screw lead (bottom)'' </center></big>]]

===Linear Motors===
This type is treated the same as the regular rotary axes, but the '''MKT''' is switched with the '''MKF''' property, which is in units of [N/A] and there is no gear, therefore the TorqueFactor would be: 
<center> <math> TFac = \frac{1000000}{MKF*MICONT}\ </math></center>

===Operation Mode and PDOs===
The operation mode of the drives while using the dynamic model should be '''cyclic synchronous position'''. The dynamic model is used to compute the required torque (or current) for each motor, however the results are never precise. The additive torque command is used only as a feed forward signal as mentioned in section 3. 
Here is the list of additional PDOs (additional to the ‘cyclic synchronous position’ PDOs) that are necessary to use the dynamic model: 
{| class = "wikitable" style="text-align: center"
!PDO index
!Description
|-
|RX: 0x60B2
|Torque Offset – the additive torque signal
|-
|TX 0x6078
|Current Actual Value – the torque feedback signal
|}

=How to perform the dynamic model parameters identification=
==Data acquisition==
The process of identification is done by moving the robot while recording the movement parameters and internal motors torques. Then, the recorded data is used to extract the dynamic model parameters based on the robot model and the measurements.

A good-quality data is important for obtaining good identification results. A high-quality data contains data points that are scattered over the movement space of the robot with varying velocities and accelerations. The scattered data yields a better fit of the parameters for a wide range of movements of the robot, allowing to predict the additive torque command with good accuracy.

The recommended type of movement is using the sinewave command. This command moves each joint of the robot in a specified amplitude and frequency. In order to receive a good scattered data, the amplitude of each joint should be close to its full position range and the frequency of each joint should be different from the other joints. The frequency of each joint determined the correlation of movement between the joints. If two or more joints have the same frequency, they will always be in the same phase together and this will result in a non-scattered data. Furthermore, if the frequency of some joint is a multiplication of the frequency of another joint, the same motion will be repeated after a few cycles (more precisely, the factor of multiplication) of the faster joint. Actually, the motion will be repeated after a few cycles for any rational frequency values. However, in order to obtain good result, it is recommended to obtain data for at least three cycles for each joint. Therefore, as long as the motion does not repeat itself in this recorded time, the frequency selections is just fine. Here are some examples for a three joints robot:

{| class = "wikitable" |style:align-text="center"
!J1
!J2
!J3
!comment
!Quality
|-
|1
|2
|1.2
|j1 and j2 will repeat after 1 cycle o j1 and 2 cycles of j2
|Bad
|-
|1
|1.2
|1.2
|j2 and j3 will repeat after 3 cycles of j2 and 2 cycles of j3
|Medium
|-
|1.1
|1.3
|1.5
|j1, j2 and j3 will repeat after 11 cycles of j1, 13 cycles of j2 and 15 cycles of j3
|Good

|}

The first example is not a good choice of frequencies, the second example is fine, and the last example is a good choice of parameters. Graphs showing these combinations of sinewaves are presented in Figure 5. 

Finally, the velocities of the joints are also important. The peak velocity during the motion should be close to the maximum velocity of each joint. In high velocities, the acceleration and velocity objects of the dynamic model are significant, thus allowing more accurate identification process. The peak velocities of the joints can be managed by the amplitude and frequency of the movement. It is more convenient to first define the amplitude of each joint, then set some arbitrary frequencies, for example {1.1,1.3,1.5}, and multiply the frequencies vector by a scalar factor: factor*{1.1,1.3,1.5}. '''By changing the factor, one can control the velocities of the joints.'''

[[file: DM_5.png|700px|center|frame|<center><big>''Figure 5 – Graphs of different combinations of sinewaves corresponding to Table 2. In each graph, the location where the sinewaves start repeating themselves (as mentioned in Table 2) is pointed out with an orange circle (the last graph has no repetitions)''</big></center>]]

==Example of an identification task==

Figure 6 shows a schematic graph of the identification procedure. 

Example of a program that executes the identification process, this program is for a delta robot:
<syntaxhighlight lang='VB'>
1. program
2. dim startPoint as generic joint
3. dim sineTarget as generic joint
4. dim SWfreq as generic joint
5.
6. startPoint = {-30,-30,-30,-200}
7. sineTarget = {70,70,70,200}
8. SWfreq = 0.3*{1,1.27,1.43,1.13}
9.
10. with robot
11. attach
11. En = 0
12. while En
13. sleep 100
14. end while
15. DynamicModel = 1
16. En = 1
17. while not En
18. sleep 100
19. end while
20.
21. Move startPoint Abs = 1
22. while IsMoving
23. sleep 100
24. end while
25.
26. SineWave sineTarget SineWaveFreq = SWfreq
27. sleep 2000
28. ' IdentFilterFreq is a Low pass filter.Frequency should be below 125 Hz
29. IdentificationStart IdentFilterFreq = 80
30. ' the time of the identification, you can change time.
31. sleep 20000
32. IdentificationFinish
33.
34. stop
35. while IsMoving
36. sleep 100
37. end while
38. proceed
39. En = 0
40.
41. detach
42. end with
43. end program

</syntaxhighlight>
Here is an explanation of the program shown: 
{|class="wikitable"
!Line
!Description
|-
|6
|Defines the starting position of each joint of the system
|-
|7
|Defines the ending position
|-
|8
|Defines the frequency of the sinewave of each joint (note that the frequencies are multiplied by a factor of 0.3). Overall, these are the joints location in time: 
{{{!}} class = "wikitable"
!Joints
!Location in time [deg]
{{!}}-
{{!}}J1
{{!}}<math> 20+50*sin(0.3*t) </math>
{{!}}-
{{!}}J2
{{!}}<math> 20+50*sin(0.381*t) </math>
{{!}}-
{{!}}J3
{{!}}<math> 20+50*sin(0.429*t)</math>
{{!}}-
{{!}}J4
{{!}}<math> 200*sin(0.339)</math>

{{!}}}
|-
|15
|Defines the appropriate dynamic model of the robot, this will be discussed later on. '''Note, this parameter can be modified only when the robot is disabled'''.
|-
|21
|Moves the robot to the starting position
|-
|26
|Starts the sinewave movement with the target – sineTarget and freque ncy – SWfreq
|-
|29
|starts the recording of the data with the IdentificationStart command. At this line, one can also set a low pass filter over the collected data (over pfb and tfb) with a cutoff frequency set to IdentFilterFreq. The cutoff frequency must be larger than the largest sinewave frequency. One can try several cutoff frequencies and compare between the raw and filtered data, then choose the one that filters most of the noise without changing the real data. Please look for the identification wiki page for more information regarding the parameters that could be set for IdentificationStart command
|-
|31
|sets a sleeping time – the recording time
|-
|32
|stops the recording and apply the dynamic model parameters identification

|}

[[file: DM_6.png|600px|thumb|<center><big>''Figure 6 - Schematic graph showing the identification process''</big></center>]]

At the end of this task, a files named IDNT<group num>.PRG and IDNT<group num>.REC will be created in the MC folder. 
The PRG file contains the identified parameters and the REC file contains the recorded data used for the identification. 
The following subsections explain how to apply the identification for different robot models.

==Identification process for different robot models==
===Single axis model===
There are two types of single axis joints, linear and rotary. Each of these types has several different dynamic models as can be viewed in the Dynamic Models wiki page (and in section 5.4). Here are the different models in short:
====Linear axis====
The linear axis type has 2 dynamic model types: 
# Horizontal axis
# Tilted axis – an axis with angle α relative to the vertical axis, ranging between 0 and 90 degrees (figure 7). When α = 0 the axis is vertical, and when α = 90 the axis is horizontal (the α parameter is found by the identification (i.e. it is not a user input). [[file: DM_8.png|200px|right|thumb|<center><big>''figure 7 - tilted linear axis''</big></center>]]

====Rotary axis====
The rotary axis type has 3 dynamic model types: 
# Simple rotary axis - which its center of mass is located on the rotation axis.
# Horizontal crank-arm axis (figure 8 left).
# Vertical crank-arm axis (figure 8 right).

[[file:DM_9.png|400px|thumb|right|<center><big>''figure 8 - (left) Horizontal crank-arm axis, (right) vertical crank-arm axis''</big></center>]]

Example for an identification task that will work for all types mentioned above:
<syntaxhighlight lang='VB'>
1. program
2. dim startPoint as generic joint
3. dim sineTarget as generic joint
4. dim SWfreq as generic joint
5.
6. startPoint = -350
7. sineTarget = 350
8. SWfreq = 1.5
9.
10. with axis
11. attach
11. En = 0
12. while En
13. sleep 100
14. end while
15. DynamicModel = 2
16. En = 1
17. while not En
18. sleep 100
19. end while
20.
21. Move startPoint Abs = 1
22. while IsMoving
23. sleep 100
24. end while
25.
26. SineWave sineTarget SineWaveFreq = SWfreq Abs = 1
27. sleep 2000
28. ' IdentFilterFreq is a Low pass filter.Frequency should be below 125 Hz
29. IdentificationStart IdentFilterFreq = 80
30. ' the time of the identification, you can change time.
31. sleep 20000
32. IdentificationFinish
33.
34. stop
35. while IsMoving
36. sleep 100
37. end while
38. proceed
39. En = 0
40.
41. detach
42. end with
43. end program

</syntaxhighlight>

To reuse this code, remember to use frequency and amplitude values that are suited for the application, and also use the suitable dynamic model type.

===SCARA robot===
The SARA robot has two kinematic models, one with 3 axes (XYZ) and the other with four axes (XYZR). 
However, there is only one type of dynamic model which fits both of these kinematics models.
Example for an identification task that will work for 3 axes SCARA:

<syntaxhighlight lang='VB'>
1. program
2. dim startPoint as generic joint
3. dim sineTarget as generic joint
4. dim SWfreq as generic joint
5.
6. startPoint = {-160,-160,0}
7. sineTarget = {160,160,150}
8. SWfreq = 0.3*{1,1.27,1.43}
9.
10. with SCARA
11. attach
11. En = 0
12. while En
13. sleep 100
14. end while
15. DynamicModel = 1
16. En = 1
17. while not En
18. sleep 100
19. end while
20.
21. Move startPoint Abs = 1
22. while IsMoving
23. sleep 100
24. end while
25.
26. SineWave sineTarget SineWaveFreq = SWfreq
27. sleep 2000
28. ' IdentFilterFreq is a Low pass filter.Frequency should be below 125 Hz
29. IdentificationStart IdentFilterFreq = 80
30. ' the time of the identification, you can change time.
31. sleep 20000
32. IdentificationFinish
33.
34. stop
35. while IsMoving
36. sleep 100
37. end while
38. proceed
39. En = 0
40.
41. detach
42. end with
43. end program
</syntaxhighlight>

Example for an identification task that will work for 4 axes SCARA:

<syntaxhighlight lang='VB'>
1. program
2. dim startPoint as generic joint
3. dim sineTarget as generic joint
4. dim SWfreq as generic joint
5.
6. startPoint = {-160,-160,0,-350}
7. sineTarget = {160,160,150,350}
8. SWfreq = 0.3*{1,1.27,1.43,1.13}
9.
10. with SCARA
11. attach
11. En = 0
12. while En
13. sleep 100
14. end while
15. DynamicModel = 1
16. En = 1
17. while not En
18. sleep 100
19. end while
20.
21. Move startPoint Abs = 1
22. while IsMoving
23. sleep 100
24. end while
25.
26. SineWave sineTarget SineWaveFreq = SWfreq
27. sleep 2000
28. ' IdentFilterFreq is a Low pass filter.Frequency should be below 125 Hz
29. IdentificationStart IdentFilterFreq = 80
30. ' the time of the identification, you can change time.
31. sleep 20000
32. IdentificationFinish
33.
34. stop
35. while IsMoving
36. sleep 100
37. end while
38. proceed
39. En = 0
40.
41. detach
42. end with
43. end program

</syntaxhighlight>

To reuse this code, remember to use frequency and amplitude values that are suited for the application. 
Some SCARA robots have coupled joints, usually the 3rd and 4th joints. Currently, the dynamic model of the SCARA robot does not take the coupling into account. Therefore, there may be large errors for coupled joints

===DELTA robot===
The Delta robot has two kinematic models, one with 3 axes (XYZ) and the other with four axes (XYZR). 
However, there is only one type of dynamic model which fits both of these kinematics models.
Example for an identification task that will work for 3 axes Delta:
<syntaxhighlight lang='VB'>
1. program
2. dim startPoint as generic joint
3. dim sineTarget as generic joint
4. dim SWfreq as generic joint
5.
6. startPoint = {-30,-30,-30}
7. sineTarget = {70,70,70}
8. SWfreq = 0.3*{1,1.27,1.43}
9.
10. with DELTA
11. attach
11. En = 0
12. while En
13. sleep 100
14. end while
15. DynamicModel = 1
16. En = 1
17. while not En
18. sleep 100
19. end while
20.
21. Move startPoint Abs = 1
22. while IsMoving
23. sleep 100
24. end while
25.
26. SineWave sineTarget SineWaveFreq = SWfreq
27. sleep 2000
28. ' IdentFilterFreq is a Low pass filter.Frequency should be below 125 Hz
29. IdentificationStart IdentFilterFreq = 80
30. ' the time of the identification, you can change time.
31. sleep 20000
32. IdentificationFinish
33.
34. stop
35. while IsMoving
36. sleep 100
37. end while
38. proceed
39. En = 0
40.
41. detach
42. end with
43. end program

</syntaxhighlight>

Example for an identification task that will work for 4 axes Delta:

<syntaxhighlight lang='VB'>
1. program
2. dim startPoint as generic joint
3. dim sineTarget as generic joint
4. dim SWfreq as generic joint
5.
6. startPoint = {-30,-30,-30,-350}
7. sineTarget = {70,70,70,350}
8. SWfreq = 0.3*{1,1.27,1.43,1.13}
9.
10. with DELTA
11. attach
11. En = 0
12. while En
13. sleep 100
14. end while
15. DynamicModel = 1
16. En = 1
17. while not En
18. sleep 100
19. end while
20.
21. Move startPoint Abs = 1
22. while IsMoving
23. sleep 100
24. end while
25.
26. SineWave sineTarget SineWaveFreq = SWfreq
27. sleep 2000
28. ' IdentFilterFreq is a Low pass filter.Frequency should be below 125 Hz
29. IdentificationStart IdentFilterFreq = 80
30. ' the time of the identification, you can change time.
31. sleep 20000
32. IdentificationFinish
33.
34. stop
35. while IsMoving
36. sleep 100
37. end while
38. proceed
39. En = 0
40.
41. detach
42. end with
43. end program

</syntaxhighlight>

To reuse this code, remember to use frequency and amplitude values that are suited for the application.

===PUMA robot===
The PUMA robot has only one kinematic model but it has two different dynamic models. 
The first dynamic model is a regular model like the other robots. 
The second model is a semi-static model, meaning it will work only for slow movements and static positions. This model takes into account only the gravity and friction forces / torques.
====Full regular model====
This model identification rules are just like the previous models. 
Example for an identification task that will work for PUMA:
<syntaxhighlight lang='Vb'>
1. program
2. dim startPoint as generic joint
3. dim sineTarget as generic joint
4. dim SWfreq as generic joint
5.
6. startPoint = {-100,-170,100,-60,-60,-100}
7. sineTarget = {100,-40,235,60,60,100}
8. SWfreq = 0.15*{1.56,1,1.31,1.47,1.21,1.17}
9.
10. with PUMA
11. attach
11. En = 0
12. while En
13. sleep 100
14. end while
15. DynamicModel = 1
16. En = 1
17. while not En
18. sleep 100
19. end while
20.
21. Move startPoint Abs = 1
22. while IsMoving
23. sleep 100
24. end while
25.
26. SineWave sineTarget SineWaveFreq = SWfreq
27. sleep 2000
28. ' IdentFilterFreq is a Low pass filter.Frequency should be below 125 Hz
29. IdentificationStart IdentFilterFreq = 80
30. ' the time of the identification, you can change time.
31. sleep 20000
32. IdentificationFinish
33.
34. stop
35. while IsMoving
36. sleep 100
37. end while
38. proceed
39. En = 0
40.
41. detach
42. end with
43. end program

</syntaxhighlight>

To reuse this code, remember to use frequency and amplitude values that are suited for the application.

====Semi-static model====
The semi-static model identification is a little bit different from all of the examples so far. This model takes into account only gravity and friction forces, in other words it neglects dynamic forces. Therefore, the measurement should include negligible dynamic forces, and this is possible by moving slow. 
This identification process is longer than the usual identification progress, it takes approximately 2-3 minutes. In addition, it is advised to perform less than 3 cycles, 1 cycle should be enough. 
Also, similar to the previous examples, the semi-static model threshold the velocity of the data points. But unlike the previous examples, here there are two thresholds, one for avoiding very low velocities avoiding numeric errors) and the other for avoiding high velocities (avoiding significant dynamic forces).
Example for such an identification process:
<syntaxhighlight lang='VB'>
1. program
2. dim startPoint as generic joint
3. dim sineTarget as generic joint
4. dim SWfreq as generic joint
5.
6. startPoint = {-100,-170,100,-60,-60,-100}
7. sineTarget = {100,-40,235,60,60,100}
8. SWfreq = 0.02*{1.56,1,1.31,1.47,1.21,1.17}
9.
10. with PUMA
11. attach
11. En = 0
12. while En
13. sleep 100
14. end while
15. DynamicModel = 1
16. En = 1
17. while not En
18. sleep 100
19. end while
20.
21. Move startPoint Abs = 1
22. while IsMoving
23. sleep 100
24. end while
25.
26. SineWave sineTarget SineWaveFreq = SWfreq
27. sleep 2000
28. ' IdentFilterFreq is a Low pass filter.Frequency should be below 125 Hz
29. IdentificationStart IdentFilterFreq = 80
30. ' the time of the identification, you can change time.
31. sleep 20000
32. IdentificationFinish
33.
34. stop
35. while IsMoving
36. sleep 100
37. end while
38. proceed
39. En = 0
40.
41. detach
42. end with
43. end program

</syntaxhighlight>

Note the significant low frequencies which cause slow movement.

[[file:DM_17.png|1100px|center|thumb|<center><big>''Figure 9 – An example of the path made by a puma robot during the identification process'' </big></center>]]

==The Dynamic Models Parameters==
This section lists the dynamic parameters for each type of dynamic model.
===Rotary Axis===
====Dynamic Model 1 – simple rotary axis====
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|}
;Model equation
: <math>T = (I + I_{payload}) \cdot acc</math>
 
====Dynamic Model 2 - horizontal crank-arm axis ====
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|-
|2
|<math>L^2</math>
|Square of length of crank arm (axis to payload)
|}
;Model equation
: <math>T = (I + I_{payload} + L^2 \cdot M_{payload}) \cdot acc</math>

 
==== Dynamic Model 3 - vertical crank-arm axis ====
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I</math>
|Total moment of inertia around the rotation axis of the moved part
|-
|2
|<math>L^2</math>
|Square of length of crank arm (axis to payload)
|-
|3
|<math>M \cdot g \cdot A</math>
|Mass (without payload) * Gravity * Distance to center of mass
|-
|4
|<math>g \cdot L</math>
|Gravity * Distance to Payload
|}
;Model equation
: <math>T = (I + I_{payload} + L^2 \cdot M_{payload}) \cdot acc - (M \cdot g \cdot A + M_{payload} \cdot g \cdot L) \cdot \sin(pos)</math>

===Linear Axis===

==== Dynamic Model 1 - horizontal axis ====
[[File:Axystems;Motion Dynamics - Horizontal Axis.png|''Figure 10 - Horizontal linear axis''|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part.
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot acc</math>

 
==== Dynamic Model 2 - vertical or tilted axis ====
[[File:Axystems;Motion Dynamics - Vertical Axis.png|''Figure 11 - Vertical linear axis''|thumb]]
{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>M</math>
|Total mass of the moved part.
|-
|2
|<math>M \cdot g \cdot \cos(\alpha)</math>
|Constant force due to gravity.
|-
|3
|<math>g \cdot \cos(\alpha)</math>
|Gravity coefficient used to consider payload mass. ('''g = 9.80665''')
|}
;Model equation
: <math>T = (M + M_{payload}) \cdot acc + M \cdot g \cdot \cos(\alpha) + M_{payload} \cdot g \cdot \cos(\alpha)</math>

===SCARA robot===

==== Dynamic Model 1 ====
[[File:scara.PNG|''Figure 12 - scara robot''|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>L_1^2 \cdot M_2 + I_1</math>
|-
|2
|<math>A_2^2 \cdot M_2 + I_2</math>
|-
|3
|<math>J_2</math>
|-
|4
|<math>L_1 \cdot A_2 \cdot M_2</math>
|-
|5
|<math>M_3</math>
|-
|6
|<math>g \cdot M_3</math>
|-
|7
|<math>I_4</math>
|-
|8
|<math>J_4</math>
|}

===DELTA robot===

==== Dynamic Model 1 ====
[[File:Control;Rod forces model for Delta kinematics - Introduction.png|''Figure 13 - Delta robot''|thumb]]

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>\Theta_{AB}</math>
|kg*m2
|-
|2
|<math>g \cdot L_{AB} \cdot M_{AB}</math>
| kg*m2/sec2
|-
|3
|<math>M_{BC}</math>
|kg
|-
|4
|<math>\Theta_{BC}</math>
|kg*m2
|-
|5
|<math>M_P</math>
|kg
|-
|6
|<math>M_T</math>
|kg
|-
|7
|<math>\Theta_T</math>
|kg*m2
|-
|8
|<math>\Theta_{T\phi}</math>
|kg*m2
|-
|9
|<math>L_{TO}</math>
| m
|-
|10
|<math>L_{TP}</math>
| m
|-
|11
|<math>D</math>
|-
|12
|<math>C_r</math>
|-
|13
|<math>Fr_{max}</math>
|-
|14
|<math>R_{ext}</math>
|}

===PUMA robot===
==== Dynamic Model 1 ====
[[File:puma.PNG|''Figure 14 - Puma robot''|thumb]]

Description:
:* <math> g </math> - Gravity constant
:* <math> m_{i} </math> - Mass of the ith link
:* <math> a_{i} </math> - length of the common normal between the ith and ith+1 joints
:* <math> d_{i} </math> - offset along z axis between the ith and ith+1 joints
:* <math> l_{i} </math> - The distance from the ith joint to the center of mass of the ith link

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>I_{1} = I_{1,zz}+m_{1}*l_{1,y}^2 +m_{2}*d_{2}^2+(m_{4}+m_{5}+m_{6})*a_{3}^2+m_{2}*l_{2,z}^2+</math> <math>(m_{3}+m_{4}+m_{5}+m_{6})*(d_{2}+d_{3})^2+I_{2,xx}+I_{3,yy}+2*m_{2}*d_{2}*l_{2,z}+m_{2}*l_{2,y}^2+m_{3}*l_{3,z}^2+2*m_{3}*(d_{2}+d_{3})*l_{3,z}+I_{4,zz}+I_{4,yy}+I_{6,zz}</math>
|kg/m^2
|-
|2
|<math>I_{2} = I_{2,zz}+m_{2}*(l_{2,x}^2+l_{2,y}^2)+(m_{3}+m_{4}+m_{5}+m_{6}*a_{2}^2</math>
|kg/m^2
|-
|3
|<math>I_{3} = -I_{2,xx}+I_{2,yy}+(m_{3}+m_{4}+m_{5}+m_{6})*a_{2}^2+m_{2}*l_{2,x}^2-m_{2}*l_{2,y}^2</math>
|kg/m^2
|-
|4
|<math>I_{4} = m_{2}*l_{2,x}*(d_{2}+l_{2,z})+m_{3}*a_{2}*l_{3,z}+(m_{3}+m_{4}+m_{5}+m_{6})*a_{2}*(d_{2}+d_{3})</math>
|kg/m^2
|-
|5
|<math>I_{5} = -m_{3}*a_{2}*l_{3,y}+(m_{4}+m_{5}+m_{6})*a_{2}*d_{4}+m_{4}*a_{2}*l_{4,z}</math>
|kg/m^2
|-
|6
|<math>I_{6} = I_{3,zz}+m_{3}*l_{3,y}^2+m_{4}*a_{3}^2+m_{4}*(d_{4}+l_{4,z})^2+I_{4,yy}+m_{5}*a_{3}^2+m_{5}*d_{4}^2+I_{5,zz}+m_{6}*a_{3}^2+m_{6}*d_{4}^2+m_{6}*l_{6,z}^2+I_{6,xx}</math>
|kg/m^2
|-
|7
|<math>I_{7} = m_{3}*l_{3,y}^2+I_{3,xx}-I_{3,yy}+m_{4}*l_{4,z}^2+2*m_{4}*d_{4}*l_{4,z}+(m_{4}+m_{5}+m_{6})*(d_{4}^2-a_{3}^2)+I_{4,yy}-I_{4,yy}+I_{5,zz}-I_{5,yy}+m_{6}*l_{6,z}^2-I_{6,zz}+I_{6,xx}</math>
|kg/m^2
|-
|8
|<math>I_{8} = -m_{4}*(d_{2}+d_{3})*(d_{4}+l_{4,z})-(m_{3}+m_{6})*(d_{2}+d_{3})*d_{4}+m_{3}*l_{3,y}*l_{3,z}+m_{3}*(d_{2}+d_{3})*l_{3,y}</math>
|kg/m^2
|-
|9
|<math>I_{9} = m_{2}*l_{2,y}*(d_{2}+l_{2,z})</math>
|kg/m^2
|-
|10
|<math>I_{10} = 2*m_{4}*a_{5}*l_{4,z}+2*(m_{4}+m_{5}+m_{6})*a_{3}*d_{4}</math>
|kg/m^2
|-
|11
|<math>I_{11} = -2*m_{2}*l_{2,x}*l_{2,y}</math>
|kg/m^2
|-
|12
|<math>I_{12} = (m_{4}+m_{5}+m_{6})*a_{2}*a_{3}</math>
|kg/m^2
|-
|13
|<math>I_{13} = (m_{4}+m_{5}+m_{6})*a_{3}*(d_{2}+d_{3})</math>
|kg/m^2
|-
|14
|<math>I_{14} = I_{4,zz}+I_{5,yy}+I_{6,zz}</math>
|kg/m^2
|-
|15
|<math>I_{15} = m_{6}*d_{4}*l_{6,z}</math>
|kg/m^2
|-
|16
|<math>I_{16} = m_{6}*a_{2}*l_{6,z}</math>
|kg/m^2
|-
|17
|<math>I_{17} = I_{5,zz}+I_{6,xx}+m_{6}*l_{6,z}^2</math>
|kg/m^2
|-
|18
|<math>I_{18} = m_{6}*(d_{2}+d_{3})*l_{6,z}</math>
|kg/m^2
|-
|19
|<math>I_{19} = I_{4,yy}-I_{4,xx}+I_{5,zz}-i_{5,yy}+m_{6}*l_{6,z}^2+I_{6,xx}-I_{6,zz}</math>
|kg/m^2
|-
|20
|<math>I_{20} = I_{5,yy}-I_{5,xx}-m_{6}*l_{6,z}^2+I_{6,zz}-I_{6,xx}</math>
|kg/m^2
|-
|21
|<math>I_{21} = I_{4,xx}-I_{4,yy}+I_{5,xx}-I_{5,zz}</math>
|kg/m^2
|-
|22
|<math>I_{22} = m_{6}*a_{3}*l_{6,z}</math>
|kg/m^2
|-
|23
|<math>I_{23} = I_{6,zz}</math>
|kg/m^2
|}

==== Dynamic Model 2 - Gravity ====

{|border="1" width="80%"
!width="100"|Number
!width="250"|Parameter
!Comments
|-
|1
|<math>g(m_{2}l_{2}+a_{2}(m_{3}+m_{4}+m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|2
|<math>g(m_{3}l_{3,y}+a_{3}(m_{4}+m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|3
|<math>g(m_{3}l_{3,y}+m_{4}(l_{4}+d_{4}(m_{5}+m_{6}))</math>
|kg*m^2/s^2
|-
|4
|<math>gl_{56}(m_{5}+m_{6})</math>
|kg*m^2/s^2

|}

==Identification with a Payload==
The IdentificationStart command has a boolean parameter called ‘IdentPayload’. If this parameter is set to false, the identification process is performed regularly. If this parameter is set to true, the identification process identifies only the payload mass or inertia. 

In order to identify the payload, one must follow these steps:
# Perform an identification process without the payload.
# Set the dynamic model parameters (by running the identification PRG file).
# Set ‘IdentPayload’ to true and perform an identification process with the payload.

{{Note| After performing an identification process with the payload and setting ‘IdentPayload’ to true, the identification PRG file will contain the dynamic model parameters form step 1, and the payload parameters from step 3}}

{{Note| This procedure is valid to all dynamic models except dynamic model 1 of the PUMA robot.}}

=Explanation of the identification output file=
Example of an identification output PRG file. The file is generated at the end of the identification process, and is named: IDNT<group num>.PRG: 

<syntaxhighlight lang='VB'>
1. 'Dynamic parameter identification for PUMA succeeded!
2. 'Identification date and time: 29/03/17 08:17:08
3. 'Max relative torque error: axis 1 = 13.86 %; axis 2 = 8.70 %; axis 3 = 7.79 %; axis 4 = 17.87 %; axis 5 = 23.87 %; axis 6 = 43.85 %; (maximal allowed = 50.00 %)
4. 'Mean relative torque error: axis 1 = 3.18 %; axis 2 = 1.71 %; axis 3 = 1.88 %; axis 4 = 3.59 %; axis 5 = 5.88 %; axis 6 = 12.41 %;
5. 'Signal filter cutoff frequency = 20.000 Hz
6. 'Signal data length = 49876 samples (raw record length = 50000 samples)
7. 'Moving data length: axis 1 = 35998 samples (threshold = 0.038770 rad/s); axis 2 = 35405 samples (threshold = 0.031481 rad/s); axis 3 = 36032 samples (threshold = 0.039294 rad/s); axis 4 = 36785 samples (threshold = 0.041069 rad/s); axis 5 = 34931 samples (threshold = 0.038757 rad/s); axis 6 = 29759 samples (threshold = 0.062830 rad/s);

8. PROGRAM CONTINUE
9. ATTACH PUMA

10. PUMA.DynamicParameter[1] = 8.759309007e+01
11. PUMA.DynamicParameter[2] = 1.021832253e+01
12. PUMA.DynamicParameter[3] = 3.042091725e+01
13. PUMA.DynamicParameter[4] = 1.560383089e+00
14. PUMA.DynamicParameter[5] = 0.000000000e+00
15. PUMA.DynamicParameter[6] = 0.000000000e+00

16. A1.ViscousFriction = -1.547427791e+02
17. A1.CoulombFriction = -2.018153298e+01

18. A2.ViscousFriction = -1.603287029e+02
19. A2.CoulombFriction = -4.658045702e+01

20. A3.ViscousFriction = -1.085257604e+02
21. A3.CoulombFriction = -1.961987594e+01

22. A4.ViscousFriction = -1.142833743e+01
23. A4.CoulombFriction = -9.124446870e+00

24. A5.ViscousFriction = -2.468491129e+01
25. A5.CoulombFriction = -3.713111266e+00

26. A6.ViscousFriction = -2.173025205e+00
27. A6.CoulombFriction = -9.724658207e-01

29. PUMA.DynamicModel = 2

30. DETACH PUMA
31. TERMINATE PROGRAM

</syntaxhighlight>

Line 1-7 give information about the identification process. Line 1 reports if the identification was successful or not.

<syntaxhighlight lang='VB'>
2. 'Identification date and time: 29/03/17 08:17:08
3. 'Max relative torque error: axis 1 = 13.86 %; axis 2 = 8.70 %; axis 3 = 7.79 %; axis 4 = 17.87 %; axis 5 = 23.87 %; axis 6 = 43.85 %; (maximal allowed = 50.00 %)

</syntaxhighlight>

Line 2 reports the date and time the identification was made. 
Line 3 reports the recorded max relative torque error. The torque error is taken as the TorqueAdditiveCommand (Taddcmd) minus the measured TorqueFeedback. The Taddcmd for this calculation is taken as the Taddcmd that would have been calculated with the identified dynamic parameters as if this movement was performed. In other words, the error is the difference between the real data and the fitted model. The relative torque error is calculated as the torque error divided by the max measured TorqueFeedback (each joint and its max TorqueFeedback value). The max relative torque error, is the maximum value of the relative value for each joint. The formula for the max relative torque error is: 

<center> <math> max relative torque error =max(\frac{TaddCMD-Tfb}{max(Tfb)}\ </math></center>

If this value is larger than 50% for one of the joints than the identification is regarded as failed.

<syntaxhighlight lang='VB'>
4. 'Mean relative torque error: axis 1 = 3.18 %; axis 2 = 1.71 %; axis 3 = 1.88 %; axis 4 = 3.59 %; axis 5 = 5.88 %; axis 6 = 12.41 %;
5. 'Signal filter cutoff frequency = 20.000 Hz
6. 'Signal data length = 49876 samples (raw record length = 50000 samples)

</syntaxhighlight>

Line 4 reports the mean relative torque error, the mean of the relative torque error over all of the recorded time is taken and displayed for each joint. 
Line 5 reports the cutoff frequency that was used for the low pass filter. 
Line 6 reports how many data points were recorded.

<syntaxhighlight lang='VB'>
7. 'Moving data length: axis 1 = 35998 samples (threshold = 0.038770 rad/s); axis 2 = 35405 samples (threshold = 0.031481 rad/s); axis 3 = 36032 samples (threshold = 0.039294 rad/s);
'axis 4 = 36785 samples (threshold = 0.041069 rad/s); axis 5 = 34931 samples (threshold = 0.038757 rad/s); axis 6 = 29759 samples (threshold = 0.062830 rad/s);
</syntaxhighlight>

Line 7 reports how many data points from each joint were taken for the model fitting. Some data points are discarded if the velocity of the joint in these point is below some threshold (the threshold for each joint is also reported in this line). This is done because the data points with low velocities are causing numerical errors to the model fitting. Therefore, all of the relative errors explained above are calculated only for those points which are taken into account for the model fitting.

<syntaxhighlight lang='VB'>
10. PUMA.DynamicParameter[1] = 8.759309007e+01
11. PUMA.DynamicParameter[2] = 1.021832253e+01
12. PUMA.DynamicParameter[3] = 3.042091725e+01
13. PUMA.DynamicParameter[4] = 1.560383089e+00
14. PUMA.DynamicParameter[5] = 0.000000000e+00
15. PUMA.DynamicParameter[6] = 0.000000000e+00

</syntaxhighlight>

Lines 10-15 (for this file) sets the fitted dynamic model parameters.

<syntaxhighlight lang='VB'>
16. A1.ViscousFriction = -1.547427791e+02
17. A1.CoulombFriction = -2.018153298e+01
18. A2.ViscousFriction = -1.603287029e+02
19. A2.CoulombFriction = -4.658045702e+01
20. A3.ViscousFriction = -1.085257604e+02
21. A3.CoulombFriction = -1.961987594e+01
22. A4.ViscousFriction = -1.142833743e+01
23. A4.CoulombFriction = -9.124446870e+00
24. A5.ViscousFriction = -2.468491129e+01
25. A5.CoulombFriction = -3.713111266e+00
26. A6.ViscousFriction = -2.173025205e+00
27. A6.CoulombFriction = -9.724658207e-01

</syntaxhighlight>

Lines 16-27 (for this file) sets the fitted friction parameters.

<syntaxhighlight lang='VB'>

29. PUMA.DynamicModel = 2
</syntaxhighlight>

Line 29 (for this file) sets the dynamic model that was used for this identification process.

==Success condition==
The success condition is based on the relative torque error. Each axis should have a max relative torque error value below 50% in order for the identification to be considered as successful.

The torque error is taken as the TorqueAdditiveCommand (Taddcmd) minus the measured TorqueFeedback. The Taddcmd for this calculation is taken as the Taddcmd that would have been calculated with the identified dynamic parameters as if this movement was performed. In other words, the error is the difference between the real data and the fitted model.

The relative torque error is calculated as the torque error divided by the max measured TorqueFeedback (each joint and its max TorqueFeedback value). The max relative torque error, is the maximum value of the relative value for each joint. If this value is larger than 50% for one of the joints than the identification is regarded as failed. Line 4 reports the mean relative torque error, the mean of the relative torque error over all of the recorded time is taken and displayed for each joint. Please note that the relative torque error is evaluated only for the points that stand in a minimum velocity limitation.

The max relative torque error may vary between the different joint. Typically, small joints (with small motors) have larger relative error. This is because the applied torque for these motors is small and the noise in measurement is in the same order of magnitude of the applied torque.

'''For example:''' Let’s assume that for a certain point j1.TorqueFeedback = 80 and the j1.TorqueAdditiveCommand = 100. For this point, the j1.TorqueError = 20. Let’s assume that the maximum j1.TorqueFeedback during the recording was 160, then the relative torque error for this point would be: j1.TorqueError/max(j1.TorqueFeedback) = 20/160 = 0.125 = 12.5%

==Parameters==
Robot models which are supported for dynamic model, have at least one type of dynamic model. These models can be found in the wiki page Dynamic Models. Each model is based on some parameters which are composed of the mass, length and inertia of the different parts of the robot. These are the parameters that are being evaluated with the help of the identification process. The parameters are saved as robot.DynamicParameter[i], where robot is the robot name and i is the number of the parameter as stated in the Dynamic Models page. Each model may have different number of parameters.

After the dynamic parameter, appear the viscous friction and coulomb friction parameters: axis.ViscousFriction, axis.CoulombFriction . Each joint of the robot has these two parameters which define its friction coefficients.

In addition to these parameters, the user should consider to set the maximum allowed value for the additive torque command. This could be set with the property TorqueThreshold, e.g. a1.TorqueThreshold = 200. If the Taddcmd exceeds this value, than the softMC reports an error.

==Including the identification output file in setup==
In order for the dynamic model to take effect you should simply run the IDNT<group num>.PRG file while the robot is disabled (en = 0). Note that this should come after the robot setup. In order to automatically load the dynamic model configuration during the system initialization and robot setup, simply add the line: 

Load IDNT<group num>.PRG
To the end of your AUTOEXEC.PRG or STARTPRG.PRG file, '''after''' the robot setup.

=Explanation of the identification process recording file=
Another file that is generated at the end of the identification process is the data recording file. This file is named: IDNT<group num>.REC. This file contains all of the relevant data that was used by the identification process. Here are the parameters which are displayed for each joint: 

* tfbRaw – The raw recorded data of the TorqueFeedback (tfb) property.
* pfbRaw – The raw recorded data of the PositionFeedback (pfb) property.
* tfb – The filtered recorded data of the TorqueFeedback (tfb) property.
* pfb – The filtered recorded data of the PositionFeedback (pfb) property.
* vfb – The filtered recorded data of the VelocityFeedback (vfb) property.
* afb – The filtered recorded data of the AccelerationFeedback (afb) property.
* tcmd – The torque command generated by the fitted model. The found dynamic parameters and the collected data are used to calculate this property. In regular mode, this property will actually be TorqueAdditiveCommand (Taddcmd).
* te – The TorqueError (te) calculated by the difference of the tcmd and tfb data.

This file can be used for better debugging and troubleshooting, as well as for better understanding the identification process. At figure 15 you can find example of an identification output REC file:

[[file: DM_19.png|1000px|thumb|center|<center><big>''Figure 15 - An example of an identification output REC file of a semi-static PUMA model''</big></center>]]

=Demonstration of tracking improvements (settling, position error)=
==SCARA Robot==
An experiment was made for a 4 axes scara robot with and without dynamic model. The robot was commanded to move 600[mm] in a straight line with linear velocity of 900[mm/s]. The cartesian velocity of the robot and the ISSETTLED property were recorded during this motion (figure 16 and 17, the ISSETTLED property is scaled by 3000). 
The ISSETTLED property indicates whether the actual element position is within the specified settling range. The settling range is defined by the PESETTLE property and is further qualified by the TIMESETTLE property. When the motion profiler has completed, the absolute value of the position error (Target Position – Actual Position) is compared to the PESETTLE property. When the result is less than or equal to this property for the time given by TIMESETTLE, the ISSETTLED flag is set. For this example, the PESETTLE was taken as 0.001.
Therefore, one could expect that a shorter settling time indicates on better performance. 
Figures 16 and 17 display the recorded data from the experiment. The results are that the settling time for this motion without dynamic model is 300 ms, and the settling time with dynamic model is 260 ms – ~86.7% of the original settling time. 

[[file:DM_20.png|850px|thumb|center|<center><big>''Figure 15 - An example of settling time improvement for SCARA robot. This graph is for the case without dynamic model, the settling time is 300[ms]''</big></center>]]

[[file:DM_21.png|850px|thumb|center|<center><big>''Figure 16 - An example of settling time improvement for Delta robot. This graph is for the case with dynamic model, the settling time is reduced to 260[ms]''</big></center>]]

==DELTA Robot==
An experiment was made for a 3 axes delta robot with and without dynamic model. The robot was commanded to move 550[mm] in a straight line with linear velocity of 3000[mm/s]. The cartesian velocity of the robot and the ISSETTLED property were recorded during this motion (figure 17 and 18, the ISSETTLED property is scaled by 3000). 

The ISSETTLED property indicates whether the actual element position is within the specified settling range. The settling range is defined by the PESETTLE property and is further qualified by the TIMESETTLE property. When the motion profiler has completed, the absolute value of the position error (Target Position – Actual Position) is compared to the PESETTLE property. When the result is less than or equal to this property for the time given by TIMESETTLE, the ISSETTLED flag is set. For this example, the PESETTLE was taken as 0.05. 

Therefore, one could expect that a shorter settling time indicates on better performance. 

Figures 17 and 18 display the recorded data from the experiment. The results are that the settling time for this motion without dynamic model is 268 ms, and the settling time with dynamic model is 44 ms – ~16.5% of the original settling time.

[[file:DM_22.png|850px|thumb|center|<center><big>''Figure 17 - An example of settling time improvement for Delta robot. This graph is for the case without dynamic model, the settling time is 268[ms]''</big></center>]]

[[file:DM_23.png|850px|thumb|center|<center><big>''Figure 18 - An example of settling time improvement for Delta robot. This graph is for the case with dynamic model, the settling time is reduced to 44[ms]''</big></center>]]

==PUMA Robot==
An experiment was made with and without dynamic model. Axis 3 was commanded to oscillate with the SineWave command while axis 2 was commanded to stay at 0. 
Figure 19 shows axis 2 position error for the cases with (top) and without (bottom) dynamic model. The peak to peak amplitude for the cases with and without dynamic model are ~0.6e-3 and ~1e-3 correspondingly. It means that using the dynamic model reduced ~40% of the error for this example.

[[file:DM_24.png|850px|thumb|center|<center><big>''Figure 19 - An example of tracking improvement for PUMA robot. Top - case with dynamic model 0.627e-3 peak to peak amplitude, Bottom - case without dynamic model 1.04e-3 peak to peak amplitude''</big></center>]]

=Collision detection=
The dynamic model allows to enable a more delicate collision detection feature. Without the dynamic model, the softMC can detect a collision by thresholding the position error of the robot or joints. However, when using the dynamic model of the robot, a collision can be detected by thresholding the torque error. The torque error reacts quicker than the position error, hence enabling a more delicate collision detection. 

In order to activate the thresholding over the torque error for a certain joint, set the property TorqueErrorEnable (Teen) to 1, e.g. a1.Teen = 1. One more property to set is the TorqueErrorMax (Temax), e.g. a1.Temax = 10. This property set the maximum allowed torque error which above it softMC reports an error. Note that the Temax property may vary between joints, usually the bigger the joint’s motor the bigger Temax that the user should allow. Also note that as the dynamic model identification results get more accurate, the Temax can be decreased as the torque error gets smaller. 

One last property to consider is the TorqueErrorFilter property. If the torque feedback is noisy, the Temax value can be exceed due to noise which causes false collision triggering. Filtering this noise helps to achieve better collision detection procedure. This property gets values in the range of 0.0 to 1.0. The filter is a very simple averaging filter, it performs as follows: 

<center><math>TE=TEF*TE_{current} +(1-TEF)*TE_{previous}</math></center>

when TE is the TorqueError property, and TEF is the TorqueErrorFilter property. 

Note that usually the largest error occurs in the beginning, ending or direction changing of the movement. Therefore, the magnitude of the errors in these cases determine what the Temax value will be. Nevertheless, these cases are also characterized with very low velocities. Hence, it is possible to write an application that monitors the torque error and joint velocities, and ignore the cases when the velocity is small, or perhaps increase the Temax just for these cases. As a result, the collision detection feature can become very sensitive

=Review of the possible reasons for an identification failure=
This section reviews some possible reasons that may cause poor results or a failure of the identification process. The next section reviews how to identify these reasons.
==Movement is too slow==
The dynamic identification model requires that the robot joints will move in a high velocity, as mentioned in section 3. When the joints move at a low velocity, the developed torque in the joints opposes mainly the joints friction and gravity torques, and the acceleration and inertia terms are relatively small. Therefore, the dynamic model parameters identification will perform poorly. Furthermore, the identification process ignores data that is under certain minimal velocity, so moving slowly can also cause for lack of data. 

That being said, in such a case, the output PRG identification file may report that the identification process was successful and the resulting max relative errors can be small. However, later, when attempting to move at higher velocities than the velocities used during the identification process, the additive torque command predictions will most likely perform poorly. 

Figure 20 shows an example for an identification output REC file for a 3 axes delta robot where the motion was slow during the identification. It is noticeable that the data is very noisy. The reason for that is that the movement is slow, hence the developed torques are small and the relative noise is large

[[file:DM_25.png|900px|thumb|center|<center><big>''Figure 20 - An example of a slow identification output REC file for a 3 axes delta robot''</big></center>]]

Figure 21 shows the torque error for the same delta robot and the same motion. The top figure is the result of the motion using the retrieved parameters from a slow identification process and the bottom figure is the result of the motion using the retrieved parameters from a good identification process. One can see that the torque errors increase dramatically for the case with slow identification process

[[file:DM_26.png|900px|thumb|center|<center><big>''Figure 21 – top – the torque error for the 3 axes of the delta robot using the retrieved dynamic parameters from a slow identification process. Botoom – the torque error for the 3 axes of the delta robot using the retrieved dynamic parameters from a slow identification process.''</big></center>]]

==Movement is too fast==
This problem is less likely to happen, but still, it can cause poor results or a failure of the identification process. 
If the robot joints are brought to their limits, the motor torque can reach to a saturation value. The current dynamic model does not take saturation into account, therefore, if saturation occurred, it will cause poor identification results

==Movement duration is too short==
The identification is based on the collected data that is recorded during the robot movement. If there is not enough data, the identification may overfit the data and will predict accurately just for the region of the collected data. In such case the identification may be reported as successful, hence the user has to judge if the collected data is sufficient. A rule of thumb is that each joint should complete at least 3 cycles.

==Movement region is too small==
The identification is based on the collected data that is recorded during the robot movement. If the data is not scattered over the entire work area of the robot, the identification may overfit the data and will predict accurately just for the region of the collected data. 
In such case the identification may be reported as successful, hence the user has to judge if the collected data is sufficient. A rule of thumb is that each joint should reach position values closely to its negative and positive position limits.

==TorqueFactor properties are not configured well==
The dynamic model of each robot is based on the MKS system of units defines, hence the torque feedback values should be in units of [Nm]. If the TorqueFactor properties are not configured well than the torque feedback will not have suitable values and the model equations will be wrong. 
In such a case, the identification process will perform poorly and the identified model parameters will not be correct.

==Wrong type of DynamicModel property==
Some kinematic models are assigned with more than one type of dynamic model. These different models are in order to deal with different configurations. For example, a linear axis may be horizontal, vertical, or tilted in a certain angle, each of those configurations has a different dynamic model and different DynamicModel property value. 
If a wrong DynamicModel value is set, the identification process will perform poorly.

=How to assess what is the failure reason based on the output files=
This section reviews some possible failure results of the generated identification files and the identification process. The failures may be the failure of the identification process, or successful identification process with poor performance results.

==Identification process failure==
An identification failure is the case where one of the joints results with a max relative error larger than 50%. Here are some reasons that may cause this result: 
* One or more of the joints moved too slow. This can be identified in the output PRG file in lines 6 and 7. Line 6 reports how many data points were collected for each joint. Line 7 reports how many points are with a velocity larger than the velocity threshold. If the data points number after thresholding for one or more of the joints is significantly smaller than the total number of collected points, then it means that this joint moved too slow. 
* One or more of the joints reached saturation. This can be identified in the output REC file. Open the output REC file and observe only the following properties of the joint in subject: tfb, tcmd and te. Saturation can be identified by seeing that the tfb reaches a sudden plateau while the tdcmd continues regularly.
* Large noise for small joints. For some systems, the noise can be in the same order of magnitude of the mean operation currents. In such cases, the relative torque error may be very big although the net torque error is small. In such cases it is recommended to use the resultant dynamic parameters as received in the output PRG file even though the identification failed (taking into account that there aren’t any more problems). In order to indicate that this is the problem, open the output REC file and observe only the following properties of the joint in subject: tfb, tcmd and te. Then it is possible to observe if the large error occurs due to noise. Figure 22 shows an example of noise in the same order of magnitude of the mean operation currents and figure 23 shows an example of relative small noise magnitude

[[file:DM_27.png|800px|thumb|center|<center><big>''Figure 22 - An example of a large relative noise magnitude. Legend: Yellow – TFb, Orange – TCmd, Turquoise - TE''</big></center>]]

[[file:DM_28.png|800px|thumb|center|<center><big>''Figure 23 - An example of small relative noise magnitude. Legend: Red – TFb, Orange – TCmd, Green – TE''</big></center>]]

==Identification process success but poor real time prediction results==

An identification process can be reported as successful but perform poorly in real time. For some reason, the model was able to fit the data well enough, but the model is not good enough for other movements during regular operation. This usually happens because the robot did not cover major parts of its working space during identification process. Here are some reasons that may cause this result: 
* The amplitude of one or more of the joints is not big enough and does not cover the range of movement of the joint. This could be viewed in the output REC file, or simply rechecking that the commanded amplitude is large enough.
* The identification process duration was too short (relative to the joints velocity). It can be identified by looking at the output REC file. Look at each joint’s pfb property. If one or more of the joints doesn’t complete at least 3 cycles, increasing the identification duration time (or the joints velocity) should help.
* The chosen frequencies are overlapping or don’t allow enough diversity of locations. It can be identified by looking at the output REC file. Look at all joints pfb properties together. If two or more joints seems to oscillate together, or overlap after small amount of cycles, or oscillate very similarly, try to change the frequencies of the problematic joints.

=Test specifications=
This section describes how to test the dynamic model feature and check that it works properly. The test procedures are comprised of recording specific properties while performing some kind of a robot motion. The minimum required properties to record are Tfb, Taddcmd, Te. Testing can be divided into two types: one is checking that the torques predictions accuracy is reasonably small for all types of movements; and the other is checking that the robot performance (e.g. settling time, vibration, etc.) improves with the dynamic model activated. 

Testing the accuracy is equivalent to testing the torque error. In order to test the torque error, simply generate a task that generates some variation of movements and record the required properties while it’s running. Alternatively, if the robot application task is already known, one can use this task in order to perform this testing. Simply run the task while recording the Tfb, Taddcmd and Te properties. Then, observe the recording (especially Te property) and decide if the achieved accuracy if satisfactory or not.

How to setup Position Error Delay

2018-08-22T05:34:08Z

Itay: /* Expected Values For Different Devices */

= How to SetUp Position Error Delay =

{{Note/Warning| If working with CDHD Servotronix family of drives over EtherCAT pay attention that in order to get position proper error values it is extremely important to '''switch off''' the CDHD's smoothing feature by setting '''MOVESMOOTHMODE''' to '''0'''. The CDHD's position smoothing is obsolete in applications with SoftMC as the SoftMC already smoothenizes its output (PCMD values).}}

== First Step ==

* set [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] to 1 (minimum value)
* set high value in PeMax
* Run the axis back and forth and record PE and VCMD as :

[[Image:PE_VCMD.PNG |800px]] 
Command Velocity recordings
 
[[Image:PE_PEDEL1.PNG|800px]] 
Position Error recordings

Compute [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] as PE/VCMD, in this case it will be:

<pre>
PE/VCMD = 0.94/57.74*1000 = 16.2 ms
</pre>

Taking into account the used value of [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] (1) and the sampling time of 4ms we get the new [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] value of 5, e.i. '''PEDEL = 1 + 4 = 5''' 

{{Note| in case of a simulated axis the same procedure will work, typically results will show round cycle of 1.
eg, <pre>
PE/VCMD = 0.4 / 100.0 * 1000.0 = 4 ms = 1 bus cycle
</pre>
}}

== Second Step ==

Change the [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]](5) to the integer value estimated before and run the test again:

[[Image:PE_PEDEL5.PNG|800px]] 

again estimate the error:

<pre>
PE/VCMD = 0.18/57.74*1000 = 0.317 ms
</pre>

{{Note/Important|This means the non-integer communication delay of the drive is '''317 micro-seconds'''.}}
 

which is in units of one sample equal:
<pre>
317/4000 = 0.078
</pre>

==Final ==

So setting '''[[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] to 5.078''' we get: 

[[Image:PE_PEDEL5078.PNG|800px]] 

== Example File ==

'''PDLtune.prg'''
<syntaxhighlight lang="vb">

'
common shared Ax as generic Axis

program

dim i as long

Ax = A1
with Ax
Attach
Pedel = 1 ' first run
Pedel = 1 + round(1.68 / 100.0 * 1000.0 / (bus[0].cycleTime/1000)) ' 2nd run. extracted from recordings
Pedel = Pedel + 0.075 / 100.0 * 1000.0 / (bus[0].cycleTime/1000) ' 3rd run. extracted from recordings
PeMax = 10
En=1
Sleep 100
Move 0 Vcruise=100 Abs=TRUE
call waitMotion
Record ax_PE.rec 100000 Gap=1 RecData = Ax.Pe, Ax.Vcmd
RecordOn
Sleep 100
for i = 1 to 3
Move 100 Vcruise=100 Abs=TRUE
call waitMotion
Sleep 100
Move 0 Vcruise=100 Abs=TRUE
call waitMotion
Sleep 100
next
RecordClose
En=FALSE
Sleep 100
PeMax = 0.1
Detach
end with

terminate program

sub waitMotion
while Ax.IsMoving
Sleep 1
end while
end sub

</syntaxhighlight>

= Expected Values For Different Devices =
{{Note| These values are approximations to the values expected to be obtained with the script provided, and the values may vary depending on the system settings used.}}

{|class="wikitable" style="text-align: center"
|'''Drivel Model'''
|'''PEDEL''' [Motion-Bus cycle times]
|'''Derive Version'''
|-
|CDHD CAN
|5.23
|1.41.17
|-
|CDHD ETH
|4.11
|1.41.17
|-
|CDHD2 ETH
|4.404
|2.15.3a9.2.22
|-
|DDHD CAN
|5.06
|1.41.16L0.0.58BOCHU
|-
|stepIM CAN
|4.37
|23: 0.0.3.38
|}

How to setup Position Error Delay

2018-08-22T05:33:31Z

Itay: /* Expected Values For Different Devices */

= How to SetUp Position Error Delay =

{{Note/Warning| If working with CDHD Servotronix family of drives over EtherCAT pay attention that in order to get position proper error values it is extremely important to '''switch off''' the CDHD's smoothing feature by setting '''MOVESMOOTHMODE''' to '''0'''. The CDHD's position smoothing is obsolete in applications with SoftMC as the SoftMC already smoothenizes its output (PCMD values).}}

== First Step ==

* set [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] to 1 (minimum value)
* set high value in PeMax
* Run the axis back and forth and record PE and VCMD as :

[[Image:PE_VCMD.PNG |800px]] 
Command Velocity recordings
 
[[Image:PE_PEDEL1.PNG|800px]] 
Position Error recordings

Compute [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] as PE/VCMD, in this case it will be:

<pre>
PE/VCMD = 0.94/57.74*1000 = 16.2 ms
</pre>

Taking into account the used value of [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] (1) and the sampling time of 4ms we get the new [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] value of 5, e.i. '''PEDEL = 1 + 4 = 5''' 

{{Note| in case of a simulated axis the same procedure will work, typically results will show round cycle of 1.
eg, <pre>
PE/VCMD = 0.4 / 100.0 * 1000.0 = 4 ms = 1 bus cycle
</pre>
}}

== Second Step ==

Change the [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]](5) to the integer value estimated before and run the test again:

[[Image:PE_PEDEL5.PNG|800px]] 

again estimate the error:

<pre>
PE/VCMD = 0.18/57.74*1000 = 0.317 ms
</pre>

{{Note/Important|This means the non-integer communication delay of the drive is '''317 micro-seconds'''.}}
 

which is in units of one sample equal:
<pre>
317/4000 = 0.078
</pre>

==Final ==

So setting '''[[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] to 5.078''' we get: 

[[Image:PE_PEDEL5078.PNG|800px]] 

== Example File ==

'''PDLtune.prg'''
<syntaxhighlight lang="vb">

'
common shared Ax as generic Axis

program

dim i as long

Ax = A1
with Ax
Attach
Pedel = 1 ' first run
Pedel = 1 + round(1.68 / 100.0 * 1000.0 / (bus[0].cycleTime/1000)) ' 2nd run. extracted from recordings
Pedel = Pedel + 0.075 / 100.0 * 1000.0 / (bus[0].cycleTime/1000) ' 3rd run. extracted from recordings
PeMax = 10
En=1
Sleep 100
Move 0 Vcruise=100 Abs=TRUE
call waitMotion
Record ax_PE.rec 100000 Gap=1 RecData = Ax.Pe, Ax.Vcmd
RecordOn
Sleep 100
for i = 1 to 3
Move 100 Vcruise=100 Abs=TRUE
call waitMotion
Sleep 100
Move 0 Vcruise=100 Abs=TRUE
call waitMotion
Sleep 100
next
RecordClose
En=FALSE
Sleep 100
PeMax = 0.1
Detach
end with

terminate program

sub waitMotion
while Ax.IsMoving
Sleep 1
end while
end sub

</syntaxhighlight>

= Expected Values For Different Devices =
{{Note| These values are approximations to the values expected to be obtained with the script provided, and the values may vary depending on the system settings used.}}

{|class="wikitable" style="text-align: center"
|'''Drivel Model'''
|'''PEDEL''' [Motion-Bus cycle times]
|'''Derive Version'''
|-
|CDHD CAN
|5.23
|1.41.18
|-
|CDHD ETH
|4.11
|1.41.17
|-
|CDHD2 ETH
|4.404
|2.15.3a9.2.22
|-
|DDHD CAN
|5.06
|1.41.16L0.0.58BOCHU
|-
|stepIM CAN
|4.37
|23: 0.0.3.38
|}

How to setup Position Error Delay

2018-08-21T14:26:23Z

Itay: /* Expected Values For Different Devices */

= How to SetUp Position Error Delay =

{{Note/Warning| If working with CDHD Servotronix family of drives over EtherCAT pay attention that in order to get position proper error values it is extremely important to '''switch off''' the CDHD's smoothing feature by setting '''MOVESMOOTHMODE''' to '''0'''. The CDHD's position smoothing is obsolete in applications with SoftMC as the SoftMC already smoothenizes its output (PCMD values).}}

== First Step ==

* set [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] to 1 (minimum value)
* set high value in PeMax
* Run the axis back and forth and record PE and VCMD as :

[[Image:PE_VCMD.PNG |800px]] 
Command Velocity recordings
 
[[Image:PE_PEDEL1.PNG|800px]] 
Position Error recordings

Compute [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] as PE/VCMD, in this case it will be:

<pre>
PE/VCMD = 0.94/57.74*1000 = 16.2 ms
</pre>

Taking into account the used value of [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] (1) and the sampling time of 4ms we get the new [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] value of 5, e.i. '''PEDEL = 1 + 4 = 5''' 

{{Note| in case of a simulated axis the same procedure will work, typically results will show round cycle of 1.
eg, <pre>
PE/VCMD = 0.4 / 100.0 * 1000.0 = 4 ms = 1 bus cycle
</pre>
}}

== Second Step ==

Change the [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]](5) to the integer value estimated before and run the test again:

[[Image:PE_PEDEL5.PNG|800px]] 

again estimate the error:

<pre>
PE/VCMD = 0.18/57.74*1000 = 0.317 ms
</pre>

{{Note/Important|This means the non-integer communication delay of the drive is '''317 micro-seconds'''.}}
 

which is in units of one sample equal:
<pre>
317/4000 = 0.078
</pre>

==Final ==

So setting '''[[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] to 5.078''' we get: 

[[Image:PE_PEDEL5078.PNG|800px]] 

== Example File ==

'''PDLtune.prg'''
<syntaxhighlight lang="vb">

'
common shared Ax as generic Axis

program

dim i as long

Ax = A1
with Ax
Attach
Pedel = 1 ' first run
Pedel = 1 + round(1.68 / 100.0 * 1000.0 / (bus[0].cycleTime/1000)) ' 2nd run. extracted from recordings
Pedel = Pedel + 0.075 / 100.0 * 1000.0 / (bus[0].cycleTime/1000) ' 3rd run. extracted from recordings
PeMax = 10
En=1
Sleep 100
Move 0 Vcruise=100 Abs=TRUE
call waitMotion
Record ax_PE.rec 100000 Gap=1 RecData = Ax.Pe, Ax.Vcmd
RecordOn
Sleep 100
for i = 1 to 3
Move 100 Vcruise=100 Abs=TRUE
call waitMotion
Sleep 100
Move 0 Vcruise=100 Abs=TRUE
call waitMotion
Sleep 100
next
RecordClose
En=FALSE
Sleep 100
PeMax = 0.1
Detach
end with

terminate program

sub waitMotion
while Ax.IsMoving
Sleep 1
end while
end sub

</syntaxhighlight>

= Expected Values For Different Devices =
{{Note| These values are approximations to the values expected to be obtained with the script provided, and the values may vary depending on the system settings used.}}

{|class="wikitable" style="text-align: center"
|'''Drivel Model'''
|'''PEDEL''' [Motion-Bus cycle times]
|'''Derive Version'''
|-
|CDHD CAN
|5.23
|1.41.18
|-
|CDHD ETH
|4.11
|
|-
|CDHD2 ETH
|4.404
|2.15.3a9.2.22
|-
|DDHD CAN
|5.06
|1.41.16L0.0.58BOCHU
|-
|stepIM CAN
|4.37
|
|}

How to setup Position Error Delay

2018-08-21T13:34:09Z

Itay: /* Expected Values For Different Devices */

= How to SetUp Position Error Delay =

{{Note/Warning| If working with CDHD Servotronix family of drives over EtherCAT pay attention that in order to get position proper error values it is extremely important to '''switch off''' the CDHD's smoothing feature by setting '''MOVESMOOTHMODE''' to '''0'''. The CDHD's position smoothing is obsolete in applications with SoftMC as the SoftMC already smoothenizes its output (PCMD values).}}

== First Step ==

* set [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] to 1 (minimum value)
* set high value in PeMax
* Run the axis back and forth and record PE and VCMD as :

[[Image:PE_VCMD.PNG |800px]] 
Command Velocity recordings
 
[[Image:PE_PEDEL1.PNG|800px]] 
Position Error recordings

Compute [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] as PE/VCMD, in this case it will be:

<pre>
PE/VCMD = 0.94/57.74*1000 = 16.2 ms
</pre>

Taking into account the used value of [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] (1) and the sampling time of 4ms we get the new [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] value of 5, e.i. '''PEDEL = 1 + 4 = 5''' 

{{Note| in case of a simulated axis the same procedure will work, typically results will show round cycle of 1.
eg, <pre>
PE/VCMD = 0.4 / 100.0 * 1000.0 = 4 ms = 1 bus cycle
</pre>
}}

== Second Step ==

Change the [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]](5) to the integer value estimated before and run the test again:

[[Image:PE_PEDEL5.PNG|800px]] 

again estimate the error:

<pre>
PE/VCMD = 0.18/57.74*1000 = 0.317 ms
</pre>

{{Note/Important|This means the non-integer communication delay of the drive is '''317 micro-seconds'''.}}
 

which is in units of one sample equal:
<pre>
317/4000 = 0.078
</pre>

==Final ==

So setting '''[[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] to 5.078''' we get: 

[[Image:PE_PEDEL5078.PNG|800px]] 

== Example File ==

'''PDLtune.prg'''
<syntaxhighlight lang="vb">

'
common shared Ax as generic Axis

program

dim i as long

Ax = A1
with Ax
Attach
Pedel = 1 ' first run
Pedel = 1 + round(1.68 / 100.0 * 1000.0 / (bus[0].cycleTime/1000)) ' 2nd run. extracted from recordings
Pedel = Pedel + 0.075 / 100.0 * 1000.0 / (bus[0].cycleTime/1000) ' 3rd run. extracted from recordings
PeMax = 10
En=1
Sleep 100
Move 0 Vcruise=100 Abs=TRUE
call waitMotion
Record ax_PE.rec 100000 Gap=1 RecData = Ax.Pe, Ax.Vcmd
RecordOn
Sleep 100
for i = 1 to 3
Move 100 Vcruise=100 Abs=TRUE
call waitMotion
Sleep 100
Move 0 Vcruise=100 Abs=TRUE
call waitMotion
Sleep 100
next
RecordClose
En=FALSE
Sleep 100
PeMax = 0.1
Detach
end with

terminate program

sub waitMotion
while Ax.IsMoving
Sleep 1
end while
end sub

</syntaxhighlight>

= Expected Values For Different Devices =
{{Note| These values are approximations to the values expected to be obtained with the script provided, and the values may vary depending on the system settings used.}}

{|class="wikitable" style="text-align: center"
|'''Drivel Model'''
|'''PEDEL''' [Motion-Bus cycle times]
|-
|CDHD CAN
|5.23
|-
|CDHD ETH
|4.11
|-
|CDHD2 ETH
| 4.404
|-
|DDHD CAN
|4.06
|-
|stepIM CAN
|4.37
|}

How to setup Position Error Delay

2018-08-21T12:08:02Z

Itay: expected value table

= How to SetUp Position Error Delay =

{{Note/Warning| If working with CDHD Servotronix family of drives over EtherCAT pay attention that in order to get position proper error values it is extremely important to '''switch off''' the CDHD's smoothing feature by setting '''MOVESMOOTHMODE''' to '''0'''. The CDHD's position smoothing is obsolete in applications with SoftMC as the SoftMC already smoothenizes its output (PCMD values).}}

== First Step ==

* set [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] to 1 (minimum value)
* set high value in PeMax
* Run the axis back and forth and record PE and VCMD as :

[[Image:PE_VCMD.PNG |800px]] 
Command Velocity recordings
 
[[Image:PE_PEDEL1.PNG|800px]] 
Position Error recordings

Compute [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] as PE/VCMD, in this case it will be:

<pre>
PE/VCMD = 0.94/57.74*1000 = 16.2 ms
</pre>

Taking into account the used value of [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] (1) and the sampling time of 4ms we get the new [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] value of 5, e.i. '''PEDEL = 1 + 4 = 5''' 

{{Note| in case of a simulated axis the same procedure will work, typically results will show round cycle of 1.
eg, <pre>
PE/VCMD = 0.4 / 100.0 * 1000.0 = 4 ms = 1 bus cycle
</pre>
}}

== Second Step ==

Change the [[MC-Basic:element.POSITIONERRORDELAY|PEDEL]](5) to the integer value estimated before and run the test again:

[[Image:PE_PEDEL5.PNG|800px]] 

again estimate the error:

<pre>
PE/VCMD = 0.18/57.74*1000 = 0.317 ms
</pre>

{{Note/Important|This means the non-integer communication delay of the drive is '''317 micro-seconds'''.}}
 

which is in units of one sample equal:
<pre>
317/4000 = 0.078
</pre>

==Final ==

So setting '''[[MC-Basic:element.POSITIONERRORDELAY|PEDEL]] to 5.078''' we get: 

[[Image:PE_PEDEL5078.PNG|800px]] 

== Example File ==

'''PDLtune.prg'''
<syntaxhighlight lang="vb">

'
common shared Ax as generic Axis

program

dim i as long

Ax = A1
with Ax
Attach
Pedel = 1 ' first run
Pedel = 1 + round(1.68 / 100.0 * 1000.0 / (bus[0].cycleTime/1000)) ' 2nd run. extracted from recordings
Pedel = Pedel + 0.075 / 100.0 * 1000.0 / (bus[0].cycleTime/1000) ' 3rd run. extracted from recordings
PeMax = 10
En=1
Sleep 100
Move 0 Vcruise=100 Abs=TRUE
call waitMotion
Record ax_PE.rec 100000 Gap=1 RecData = Ax.Pe, Ax.Vcmd
RecordOn
Sleep 100
for i = 1 to 3
Move 100 Vcruise=100 Abs=TRUE
call waitMotion
Sleep 100
Move 0 Vcruise=100 Abs=TRUE
call waitMotion
Sleep 100
next
RecordClose
En=FALSE
Sleep 100
PeMax = 0.1
Detach
end with

terminate program

sub waitMotion
while Ax.IsMoving
Sleep 1
end while
end sub

</syntaxhighlight>

= Expected Values For Different Devices =
{{Note| These values are approximations to the values expected to be obtained with the script provided, and the values may vary depending on the system settings used.}}

{|class="wikitable" style="text-align: center"
|'''Drivel Model'''
|'''PEDEL''' [Motion-Bus cycle times]
|-
|CDHD CAN
|5.23
|-
|CDHD ETH
|5.078
|-
|CDHD2 ETH
| 4.404
|-
|DDHD CAN
|4.06
|-
|stepIM CAN
|4.37
|}

MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8/zh-hans

2018-08-20T09:06:29Z

Itay: /* 参见 */

{{Languages|MC-Basic:COMMON_SHARED_..._AS_LONG_or_DOUBLE_or_STRING_or_STRING_OF_UTF8}}
== 缩写 ==

== 格式 ==
Common Shared ''<variable>'' As Long <nowiki>|</nowiki> Double <nowiki>|</nowiki> String <nowiki>|</nowiki> String of UTF8

== 适用版本 ==
所有版本，自版本4.5.10起可用UTF-8字符串的声明。

== 描述 ==
此命令用于定义系统变量。系统变量在配置文件（CONFIG.PRG）或终端中定义。这些变量具有系统范围的可见性。这意味着它们可以在终端和任务中使用。所有的任务都可以使用这些变量，变量可以用于协调任务之间的活动。

被定义的变量可以是标量或数组。阵列可以定义为最多10个维度。字符串变量的长度只受可用内存空间的限制。

变量可能是三种类型之一。 Long类型表示变量为32位有符号整数，Double表示为双精度浮点，字符串表示字符串由ASCII-8字符组成，字符串为UTF8，表示字符串以UTF- 8为规则。

== 类型 ==
Long, Double, or String

== 取值范围 ==

== 单位 ==

== 默认 ==

== 使用范围 ==
Configuration Terminal or Task ( 在Program … End Program block之前 )
从4.5.17版起，全局（common shared）声明也可以从库上下文中获得。

== 限制 ==
只写. 在配置文件中使用时，声明必须位于Program关键字之前。

== 例子 ==
Common Shared Var1 as long ‘整形变量 

Common Shared Var2 as double ‘双精度的变量 

Common Shared Var3 as string ‘字符串变量 

Common Shared MyArray[4][5] as long ‘整形数组

== 参见 ==
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:VARLIST|VARLIST]]

[[Category:MC-Basic:Declarations|COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]

MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8

2018-08-20T09:06:07Z

Itay:

{{Languages|MC-Basic:COMMON_SHARED_..._AS_LONG_or_DOUBLE_or_STRING_or_STRING_OF_UTF8}}
{{MC-Basic
|SHORT FORM=

|SYNTAX=
Common Shared ''<variable>'' As Long <nowiki>|</nowiki> Double <nowiki>|</nowiki> String <nowiki>|</nowiki> String of UTF8

|AVAILABILITY=
All versions. Declaration of UTF-8 strings is available since Version 4.5.10.

|DESCRIPTION=
This command is used to define a system variable. System variables are defined either in the configuration file (CONFIG.PRG) or from the terminal. These variables have system-wide visibility. This means they may be used at the terminal and in tasks. All tasks may use the variables and the variables may be used to coordinate activities among tasks.

A variable being defined may be scalar or array. An array may be defined with up to 10 dimensions. The length of a string variable is only limited by the amount of free memory space.

Variables may be one of three types. A Long type indicates that the variable is a 32-bit signed integer, Double indicates that it is double precision floating point, String indicates that the string is composed of ASCII-8 characters and String of UTF8 indicates that the string is encoded according UTF-8 rules.

|TYPE=
Long, Double, or String

|RANGE=

|UNITS=

|DEFAULT=

|SCOPE=
Configuration Terminal or Task ( before Program … End Program block )

Since Version 4.5.17 the global (common shared ) declaration is also possible from the Library context.

|LIMITATIONS=
Write only. When used in the Configuration file, the declaration must come before the Program keyword.

|EXAMPLE=
Common Shared Var1 as long ‘Integer variable 

Common Shared Var2 as double ‘Double precision variable 

Common Shared Var3 as string ‘String variable 

Common Shared MyArray[4][5] as long ‘Integer array

|SEE ALSO=
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:VARLIST|VARLIST]]

[[Category:MC-Basic:Declarations|COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
}}

MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS GENERIC AXIS/zh-hans

2018-08-20T09:05:11Z

Itay: /* 参见 */

{{Languages|MC-Basic:COMMON_SHARED_or_DIM_SHARED_or_DIM_..._AS_GENERIC_AXIS}}
== 缩写 ==

== 格式 ==
Common Shared<nowiki>|</nowiki>Dim Shared<nowiki>|</nowiki>Dim ''<axis_name>''As Generic Axis {[ ]…}

== 适用版本 ==
所有版本

== 描述 ==
通用轴是一种设计用于作为参考（容器）类型的变量，（或者是暂时的或永久的）到另一个轴（实际或通用）。

通用轴可以在所有作用域中定义，即在配置文件中，也可以在终端（全局轴）中，或任务内，静态轴之间以及Program …End Program段（本地轴）内定义。

通用轴也可以定义为子程序和函数的“副参考”参数，以及函数的返回值。通用轴可以是标量或数组。阵列最多可以有10个维度。通用轴在分配有“实际”轴之前没有任何意义（见下面的示例）。

== 类型 ==

== 取值范围 ==

== 单位 ==

== 默认 ==

== 使用范围 ==
Configuration, Task or Terminal 
从4.5.17版起，全局（common shared）声明也可以从库上下文中获得。

== 限制 ==
只写

== 例子 ==
-->?axislist

A1,A2,A3,A4

-->Common Shared GenAxis1 As Generic Axis

-->Common Shared GenAxesArray [5][5] Generic Axis

-->GenAxis1 = A2 ‘ assign real axis to generic axis

-->GenAxesArray [2][3] = A4 ‘ assign real axis to generic axis

move GenAxis1 100

== 参见 ==
* [[MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS GENERIC GROUP|COMMON SHARED or DIM SHARED or DIM ... AS GENERIC GROUP]]
* [[MC-Basic:GENERIC AXIS DEFINITION|GENERIC AXIS DEFINITION]]

[[Category:MC-Basic:Declarations|COMMON SHARED or DIM SHARED or DIM ... AS GENERIC AXIS]]

MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS GENERIC AXIS

2018-08-20T09:04:38Z

Itay: fixed broken links

{{Languages|MC-Basic:COMMON_SHARED_or_DIM_SHARED_or_DIM_..._AS_GENERIC_AXIS}}
{{MC-Basic
|SHORT FORM=

|SYNTAX=
Common Shared<nowiki>|</nowiki>Dim Shared<nowiki>|</nowiki>Dim ''<axis_name>''As Generic Axis {[ ]…}

|AVAILABILITY=
All versions

|DESCRIPTION=
A generic axis is a type of variable designed to serve as a reference (container) - either temporal or permanent - to another axis (real or generic).

Generic axes can be defined in all scopes, i.e., either in configuration file and from terminal (global axes), or within tasks, before (static axes) and within the Program …End Program block (local axes).

Generic axes can also be defined as “by-reference” parameters of subroutines and functions, as well as returned-values of functions. A generic axis may be a scalar or an array. An array may have up to 10 dimensions. Generic axis has no meaning until assigned with “real” axis (see below example).

|TYPE=

|RANGE=

|UNITS=

|DEFAULT=

|SCOPE=
Configuration, Task or Terminal

Since Version 4.5.17 the global (common shared) declaration is also possible from the Library context.

|LIMITATIONS=
Write only.

|EXAMPLE=
-->?axislist

A1,A2,A3,A4

-->Common Shared GenAxis1 As Generic Axis

-->Common Shared GenAxesArray [5][5] Generic Axis

-->GenAxis1 = A2 ‘ assign real axis to generic axis

-->GenAxesArray [2][3] = A4 ‘ assign real axis to generic axis

move GenAxis1 100

|SEE ALSO=
* [[MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS GENERIC GROUP|COMMON SHARED or DIM SHARED or DIM ... AS GENERIC GROUP]]
* [[MC-Basic:GENERIC AXIS DEFINITION|GENERIC AXIS DEFINITION]]

[[Category:MC-Basic:Declarations|COMMON SHARED or DIM SHARED or DIM ... AS GENERIC AXIS]]

}}

MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS TYPE/zh-hans

2018-08-20T09:03:47Z

Itay: /* 参见 */

{{Languages|MC-Basic:COMMON_SHARED_or_DIM_SHARED_or_DIM_..._AS_TYPE}}
== 缩写 ==

== 格式 ==
COMMON SHARED<nowiki>|</nowiki>DIM SHARED<nowiki>|</nowiki>DIM ''<structure_name>'' AS ''<structure type>''

对于结构数组:

COMMON SHARED<nowiki>|</nowiki>DIM SHARED<nowiki>|</nowiki>DIM ''<structure_name>''[ ]＃ AS ''<structure type>''

== 适用版本 ==
所有版本

== 描述 ==
因为结构是新的数据类型，所以必须先在配置文件中定义。只有这样，新数据类型结构的名称才能用于声明一个结构变量。

结构变量可以在所有范围内定义，即在配置文件和终端（全局变量）中，或在任务之前（静态变量）和程序块（局部变量）内定义。结构也可以定义为子程序和函数的参数，以及函数的返回值。结构变量可以是标量或数组。数组最多可以有10个维度。

用于分配单个元素的结构语法:

''<structure_name>-><structure element name> =<expression>''

查询单个元素的结构语法 :

?'' <structure_name>-><structure element name>''

== 类型 ==
<Structure type> 是声明的结构类型

== 使用范围 ==

== 单位 ==

== 默认 ==

== 使用范围 ==
Configuration or Terminal

从4.5.17版起，全局（common shared）声明也可以从库上下文中获得。

== 限制 ==
只写。结构类型必须在配置文件中预先定义。

== 例子 ==
In config file ->

Type X

L1 as Long

Length as Long

End Type

In application file ->

Dim shared S1 as X

Program

S1->Length =2

?S1->Length

End program

== 参见 ==
* [[MC-Basic:STRUCTURE TYPE DEFINITION|STRUCTURE TYPE DEFINITION]]
* [[MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS JOINT OF ...|COMMON SHARED or DIM SHARED or DIM ... AS JOINT OF ...]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS LOCATION OF ...|COMMON SHARED or DIM SHARED or DIM ... AS LOCATION OF ...]]

[[Category:MC-Basic:Declarations|COMMON SHARED or DIM SHARED or DIM ... AS TYPE]]

MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS GENERIC GROUP/zh-hans

2018-08-20T09:02:40Z

Itay: /* 参见 */

{{Languages|MC-Basic:COMMON_SHARED_or_DIM_SHARED_or_DIM_..._AS_GENERIC_GROUP}}
== 缩写 ==

== 格式 ==
Common Shared <''group''>As Generic Group {[ ]…}

== 适用版本 ==
所有版本

== 描述 ==
通用组是一种旨在作为暂时或永久的引用（容器）（另一个组（实际或通用））类型的变量，。可以在所有作用域中定义通用组，即在配置文件和终端（全局组）中，或在任务之前（静态组）之前和Program …End Program （本地组）中定义通用组。通用组还可以定义为子程序和函数的“副参考”参数，以及函数的返回值。通用组可以是标量或数组，阵列最多可以有10个维度。在分配“真实”组之前，通用组才有意义（见下面的示例）。

== 类型 ==

== 取值范围 ==

== 单位 ==

== 默认 ==

== 使用范围 ==
Configuration, Task or Terminal. 
从4.5.17版起，全局（common shared）声明也可以从库上下文中获得。

== 限制 ==
只写

== 例子 ==
Common Shared XYTable as group AxisName=X_axis AxisName=Y_axis

Common Shared Scara as group axnm = a1 axnm = a2 axnm = a3 axnm = a4

Common Shared GenGroup1 As Generic Group

Common Shared GenGroupArray [5][5] Generic Group

GenGroup1 = Scara

GenGroupArray [5][5] = XYTable

== 参见 ==
* [[MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS GENERIC AXIS|COMMON SHARED or DIM SHARED or DIM ... AS GENERIC AXIS]]
* [[MC-Basic:GENERIC GROUP DEFINITION|GENERIC GROUP DEFINITION]]

[[Category:MC-Basic:Declarations|COMMON SHARED or DIM SHARED or DIM ... AS GENERIC GROUP]]

MC-Basic:COMMON or DIM SHARED or DIM ... AS CONST LONG or DOUBLE or STRING or STRING OF UTF8 or JOINT OF or LOCATION OF/zh-hans

2018-08-20T09:01:37Z

Itay: /* 参见 */

{{Languages|MC-Basic:COMMON_or_DIM_SHARED_or_DIM_..._AS_CONST_LONG_or_DOUBLE_or_STRING_or_STRING_OF_UTF8_or_JOINT_OF_or_LOCATION_OF}}
== 缩写 ==

== 格式 ==
Common Shared <nowiki>|</nowiki> Dim Shared <nowiki>|</nowiki> Dim ''<const_name>''As Const Long <nowiki>|</nowiki> Double <nowiki>|</nowiki> String <nowiki>|</nowiki> String of UTF8 <nowiki>|</nowiki> Joint <nowiki>|</nowiki> Location = ''<const_value>''

== 适用版本 ==
所有版本 
从版本4.5.10起声明UTF-8字符串是用的

== 描述 ==
这些命令用于定义各种范围中的用户常量。

'''System'''常量通过配置文件中的 '''Common Shared'''命令（程序块之前），用户任务（程序块之前）和终端进行定义。

'''Task'''常量是通过用户任务中的 '''Dim Shared''' 定义的（程序块之前）。

'''Local''' 常量通过程序，子程序和功能块中用户任务中的'''Dim''' 命令进行定义。

与点变量不同，点常量不与特定机器人类型相关联，因为它们实际上是仅由坐标数定义的向量

== 类型 ==
Long, Double, String, Joint or Location

== 取值范围 ==

== 单位 ==
关节和位置常量：用户定义位置单位

== 默认 ==

== 使用范围 ==
Configuration, Task or Terminal

从4.5.17版起，全局（common shared）声明也可以从库上下文中获得。

== 限制 ==
* 不支持数组和子程序或函数定义（参数和返回值）。
* 用户常量必须在声明中给出值
* 用户常量只能在声明语句中写入。之后，他们变成只读。
* 用户常量不能通过“by-reference”传递给子程序和函数。他们必须始终被“by value”传递。

== 例子 ==
‘SCARA robot Declaration :

common shared scara as group axnm=a1 axnm=a2 axnm=a3 axnm=a4 model = 4 

Common Shared LConst as Const Long = 100

Dim Shared SConst as Const String = “Task1.Prg”

Program

Dim JConst as Const Joint of XYZR = {0.0, 0.0, 0.0}

Dim LocConst as Const Location of XYZR = #{0.0, 0.0, 0.0}

<nowiki><code></nowiki>

End Program

== 参见 ==
* [[MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS JOINT OF ...|COMMON SHARED or DIM SHARED or DIM ... AS JOINT OF ...]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS LOCATION OF ...|COMMON SHARED or DIM SHARED or DIM ... AS LOCATION OF ...]]

[[Category:MC-Basic:Declarations|COMMON or DIM SHARED or DIM ... AS CONST LONG or DOUBLE or STRING or STRING OF UTF8 or JOINT OF or LOCATION OF]]

MC-Basic:COMMON or DIM SHARED or DIM ... AS CONST LONG or DOUBLE or STRING or STRING OF UTF8 or JOINT OF or LOCATION OF

2018-08-20T09:01:03Z

Itay: fixed broken links

{{Languages|MC-Basic:COMMON_or_DIM_SHARED_or_DIM_..._AS_CONST_LONG_or_DOUBLE_or_STRING_or_STRING_OF_UTF8_or_JOINT_OF_or_LOCATION_OF}}
{{MC-Basic
|SHORT FORM=

|SYNTAX=
Common Shared <nowiki>|</nowiki> Dim Shared <nowiki>|</nowiki> Dim ''<const_name>''As Const Long <nowiki>|</nowiki> Double <nowiki>|</nowiki> String <nowiki>|</nowiki> String of UTF8 <nowiki>|</nowiki> Joint <nowiki>|</nowiki> Location = ''<const_value>''

|AVAILABILITY=
All versions. 
Declaration of UTF-8 strings is available since Version 4.5.10.

|DESCRIPTION=
These commands are used to define user constants in various scopes.

'''System''' constants are defined through the '''Common Shared''' command in configuration file (before program block), user tasks (before program block) and terminal.

'''Task''' constants are defined through '''Dim Shared''' in user tasks (before program block).

'''Local''' constants are defined through '''Dim''' command in user tasks within program, subroutine and function blocks.

Unlike point variables, point constants are not linked to specific robot types, since they are actually vectors, defined only by the number of coordinates.

|TYPE=
Long, Double, String, Joint or Location

|RANGE=

|UNITS=
Joint and Location constants: user defined position units.

|DEFAULT=

|SCOPE=
Configuration, Task or Terminal

Since Version 4.5.17 the global (common shared) declaration is also possible from the Library context.

|LIMITATIONS=
*Arrays and subroutine or function definitions (parameters and return values) are not supported.
*User constants must be given a value during declaration.
*User constants are writable only during declaration statement. Afterwards, they become read only.
*User constants cannot be passed “by-reference” to subroutines and functions. They must always be passed “by value”.

|EXAMPLE=
‘SCARA robot Declaration :

common shared scara as group axnm=a1 axnm=a2 axnm=a3 axnm=a4 model = 4 

Common Shared LConst as Const Long = 100

Dim Shared SConst as Const String = “Task1.Prg”

Program

Dim JConst as Const Joint of XYZR = {0.0, 0.0, 0.0}

Dim LocConst as Const Location of XYZR = #{0.0, 0.0, 0.0}

<nowiki><code></nowiki>

End Program

|SEE ALSO=
* [[MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS JOINT OF ...|COMMON SHARED or DIM SHARED or DIM ... AS JOINT OF ...]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS LOCATION OF ...|COMMON SHARED or DIM SHARED or DIM ... AS LOCATION OF ...]]

[[Category:MC-Basic:Declarations|COMMON or DIM SHARED or DIM ... AS CONST LONG or DOUBLE or STRING or STRING OF UTF8 or JOINT OF or LOCATION OF]]

}}

MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS TYPE

2018-08-20T08:59:33Z

Itay: fixed broken links

{{Languages|MC-Basic:COMMON_SHARED_or_DIM_SHARED_or_DIM_..._AS_TYPE}}
{{MC-Basic
|SHORT FORM=

|SYNTAX=
COMMON SHARED<nowiki>|</nowiki>DIM SHARED<nowiki>|</nowiki>DIM ''<structure_name>'' AS ''<structure type>''

For arrays of structures:

COMMON SHARED<nowiki>|</nowiki>DIM SHARED<nowiki>|</nowiki>DIM ''<structure_name>''[ ]… AS ''<structure type>''

|AVAILABILITY=
All versions

|DESCRIPTION=
Because a structure is a new data type, it must first be defined in configuration file. Only then the name of the new data type structure can be used to declare a structure variable.

Structure variables can be defined in all scopes, i.e., either in configuration file and from terminal (global variables), or within tasks, before (static variables) and within the Program block (local variables). Structures can also be defined as parameters of subroutines and functions, as well as returned-values of functions. A structure variable may be a scalar or an array. An array may have up to 10 dimensions.

Syntax for assigning a single element of a structure:

''<structure_name>-><structure element name> =<expression>''

Query single element of a structure syntax :

?'' <structure_name>-><structure element name>''

|TYPE=
<Structure type> is the declared structure type

|RANGE=

|UNITS=

|DEFAULT=

|SCOPE=
Configuration or Terminal

Since Version 4.5.17 the global (common shared ) declaration is possible from the Library or Task contexts also .

|LIMITATIONS=
Write only. Structure type must be pre-defined in configuration file.

|EXAMPLE=
In config file ->

Type X

L1 as Long

Length as Long

End Type

In application file ->

Dim shared S1 as X

Program

S1->Length =2

?S1->Length

End program

|SEE ALSO=
* [[MC-Basic:STRUCTURE TYPE DEFINITION|STRUCTURE TYPE DEFINITION]]
* [[MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS JOINT OF ...|COMMON SHARED or DIM SHARED or DIM ... AS JOINT OF ...]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS LOCATION OF ...|COMMON SHARED or DIM SHARED or DIM ... AS LOCATION OF ...]]

[[Category:MC-Basic:Declarations|COMMON SHARED or DIM SHARED or DIM ... AS TYPE]]
}}

MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS GENERIC GROUP

2018-08-14T06:43:38Z

Itay:

{{Languages|MC-Basic:COMMON_SHARED_or_DIM_SHARED_or_DIM_..._AS_GENERIC_GROUP}}
{{MC-Basic
|SHORT FORM=

|SYNTAX=
Common Shared <''group''>As Generic Group {[ ]…}

|AVAILABILITY=
All versions

|DESCRIPTION=
A generic group is a type of variable, designed to serve as a reference (container) - either temporal or permanent - to another group (real or generic). Generic groups can be defined in all scopes, i.e., either in configuration file and from terminal (global groups), or within tasks, before (static groups) and within the Program …End Program block (local groups). Generic groups can also be defined as “by-reference” parameters of subroutines and functions, as well as returned-values of functions. A generic group may be a scalar or an array. An array may have up to 10 dimensions. Generic grop has no meaning until assigned with “real” group (see below example).

|TYPE=

|RANGE=

|UNITS=

|DEFAULT=

|SCOPE=
Configuration, Task or Terminal.

Since Version 4.5.17 the global (common shared ) declaration is also possible from the Library context.

|LIMITATIONS=
Write only.

|EXAMPLE=
Common Shared XYTable as group AxisName=X_axis AxisName=Y_axis

Common Shared Scara as group axnm = a1 axnm = a2 axnm = a3 axnm = a4

Common Shared GenGroup1 As Generic Group

Common Shared GenGroupArray [5][5] Generic Group

GenGroup1 = Scara

GenGroupArray [5][5] = XYTable

|SEE ALSO=
* [[MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8|DIM ... AS LONG or DOUBLE or STRING or STRING OF UTF8]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS GENERIC AXIS|COMMON SHARED or DIM SHARED or DIM ... AS GENERIC AXIS]]
* [[MC-Basic:GENERIC GROUP DEFINITION|GENERIC GROUP DEFINITION]]

[[Category:MC-Basic:Declarations|COMMON SHARED or DIM SHARED or DIM ... AS GENERIC GROUP]]
}}

MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS GENERIC GROUP

2018-08-13T12:53:25Z

Itay:

{{Languages}}
{{MC-Basic
|SHORT FORM=

|SYNTAX=
Common Shared <''group''>As Generic Group {[ ]…}

|AVAILABILITY=
All versions

|DESCRIPTION=
A generic group is a type of variable, designed to serve as a reference (container) - either temporal or permanent - to another group (real or generic). Generic groups can be defined in all scopes, i.e., either in configuration file and from terminal (global groups), or within tasks, before (static groups) and within the Program …End Program block (local groups). Generic groups can also be defined as “by-reference” parameters of subroutines and functions, as well as returned-values of functions. A generic group may be a scalar or an array. An array may have up to 10 dimensions. Generic grop has no meaning until assigned with “real” group (see below example).

|TYPE=

|RANGE=

|UNITS=

|DEFAULT=

|SCOPE=
Configuration, Task or Terminal.

Since Version 4.5.17 the global (common shared ) declaration is also possible from the Library context.

|LIMITATIONS=
Write only.

|EXAMPLE=
Common Shared XYTable as group AxisName=X_axis AxisName=Y_axis

Common Shared Scara as group axnm = a1 axnm = a2 axnm = a3 axnm = a4

Common Shared GenGroup1 As Generic Group

Common Shared GenGroupArray [5][5] Generic Group

GenGroup1 = Scara

GenGroupArray [5][5] = XYTable

|SEE ALSO=
* [[MC-Basic:COMMON SHARED ... AS LONG or DOUBLE or STRING or STRING OF UTF8|COMMON SHARED ... AS LONG or DOUBLE or STRING]]
* [[MC-Basic:DIM SHARED ... AS LONG or DOUBLE or STRING|DIM SHARED ... AS LONG or DOUBLE or STRING]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING|DIM ... AS LONG or DOUBLE or STRING]]
* [[MC-Basic:DIM ... AS LONG or DOUBLE or STRING|DIM ... AS LONG or DOUBLE or STRING]]
* [[MC-Basic:COMMON SHARED or DIM SHARED or DIM ... AS GENERIC AXIS|COMMON SHARED or DIM SHARED or DIM ... AS GENERIC AXIS]]
* [[MC-Basic:GENERIC GROUP DEFINITION|GENERIC GROUP DEFINITION]]

[[Category:MC-Basic:Declarations|COMMON SHARED or DIM SHARED or DIM ... AS GENERIC GROUP]]
}}

Default IP

2018-08-12T10:58:51Z

Itay: Created page with "=Introduction= The IP address of the softMC can be defined in any of three ways. # Static IP address – factory-defined # DHCP – assigned by DHCP server # Manual IP address..."

=Introduction=
The IP address of the softMC can be defined in any of three ways.
# Static IP address – factory-defined
# DHCP – assigned by DHCP server
# Manual IP address – assigned using ControlStudio

=Default IP Address=
The softMC is factory-configured with a static default IP address '''90.0.0.1'''

=DHCP – assigned by DHCP server=
Check with the IT manager at your site, and make sure the softMC will be able to connect to your site’s LAN, and will be able to obtain an IP address from a DHCP server. 
In this case softMC will obtain "Automatic" IP address according to your network setting.

=Manual IP address=
For this procedure please refer to [[Control Studio#IP Configurator|ControlStudio IP configurator]] tool.

MC-Basic:element.POSITIONERRORDELAY

2018-08-08T06:11:19Z

Itay:

{{Languages|MC-Basic:element.POSITIONERRORDELAY}}
{{MC-Basic
|SHORT FORM=
<''axis''>.PEDel

|SYNTAX=
<''axis''>.PositionErrorDelay = <''value''> 

?<''axis''>.PositionErrorDelay

|AVAILABILITY=
All versions

|DESCRIPTION=
This property returns the delay, as a number of AnyBus cycles, between a position command and the position feedback for the calculation of the position error.

Typically this delay includes:

* At least one motion bus sample for sending the command position to the drive.
* Time used for motion preparation (micro-interpolation), typically it is one sample but could be less depends on the drive manufacturer.
* At least one sample for sending the feedback position from the drive. 

If using micro interpolation on the drive, this delay may change from 2 cycles (no micro interpolation) to 3 (with micro interpolation).

This properly must be explicitly changed when switching the micro interpolation mode on the drives. Otherwise, an erroneous position error is calculated.

Depending on drive manufacturer and type of the motion bus the sending and receiving delays can vary.

{{Note| It is important to note that the timing of internal feedback sampling inside the drive is not taken into account In all of the calculation we assume that position feedback is taken at the start of the motion bus sample, although it might be not true.}}

|TYPE=
Double (was Long in previous fw versions)

|RANGE=
1 to 32

|UNITS=
Motion-Bus cycle times

|DEFAULT=
2 (Assuming no microinterpolation)

|SCOPE=
Task or Terminal

|LIMITATIONS=
To set the value within a task, the element must be attached to that task (using the ATTACH command) and disabled (''element''.ENABLE = 0)

|EXAMPLE=
'''Axis''' 
''A1''.PEDel = 3

'''Group''' 
''G1''.PEdel =3

|SEE ALSO=
* [[MC-Basic:SERCOS.CYCLETIME|SERCOS.CYCLETIME]]
* [[SimulatedAxes| Simulated Axes]]
* [[AXY:Position Error Delay Compensation Algorithm| Position Error Delay Compensation Algorithm]]
* [[SimulatedAxes#Simulated_Axes | Simulated Axes ]]
* [[MC-Basic:element.POSITIONCOMMANDHISTORY| POSITIONCOMMANDHISTORY]]
* [[How_to_setup_Position_Error_Delay|How to setup Position Error Delay]]
}}

Supported Devices by softMC

2018-06-07T05:42:11Z

Itay: /* Input/Output */

== Introduction ==
Following present supported devices that where validate with the softMC in our lab, but is not limited. many other devices as well can operate with the softMC.

== Input/Output ==
Following table present Input/output module that where validate with the softMC 
{| class="wikitable"
|-
! scope="col"|Manufacture || ! scope="col"| PN ||! scope="col"| Description ||! scope="col"| Vendor ||! scope="col"| FieldBUS
|-
|Beckhoff ||EK1100 ||EtherCAT Coupler ||0x2 || EtherCAT
|-
|Beckhoff ||EL1008 ||8-channel digital input terminal 24 V DC, 3 ms ||0x2 ||EtherCAT
|-
|Beckhoff ||EL1088 ||8-channel digital input terminal 24 V DC, negative switching ||0x2 || EtherCAT
|-
|Beckhoff ||EL2008 ||8-channel digital output terminal 24 V DC, 0.5 A ||0x2 ||EtherCAT
|-
|Beckhoff ||EL1809 ||EtherCAT Terminal 16-channel digital, input 24 V DC ||0x2 ||EtherCAT
|-
|Beckhoff ||EL2809 ||EtherCAT Terminal 16-channel digital output 24 V DC, 0.5 A ||0x2 ||EtherCAT
|-
|Beckhoff ||EL3356 ||1-channel precise load cell analysis (resistor bridge), 16 bit ||0x2 ||EtherCAT
|-
|Beckhoff ||EL2088 ||8-channel digital output terminal 24 V DC, negative switching ||0x2 ||EtherCAT
|-
|Beckhoff ||EL3064 ||Analog Input Terminal; 4 and 8 channel, 12 bit, 0 V ... +10 V, single-ended inputs ||0x2 ||EtherCAT
|-
|Beckhoff ||EL2809 ||16-chanel digital output ||0x2 ||EtherCAT
|-
|esd ||ECX-DIO8 ||EtherCAT® Digital I/O-Module 8 digital I/Os ||0x17 ||EtherCAT
|-
|Weidmuller ||UR20-FBC-EC ||Remote I/O coupler ||0x00000230 ||EtherCAT
|-
|Weidmuller ||UR20-16DI-N ||I/O module ||0x00000230 ||EtherCAT
|-
|WAGO ||FC 750 ||module ||0x00000021 || EtherCAT
|-
|PHOENIX ||BK EC ||Bus coupler - AXL F BK EC || 0x84 ||EtherCAT
|-
|PHOENIX ||AXL F DI8/1 DO8/1 1H ||I/O module || 0x84 ||EtherCAT
|-
|PHOENIX ||AXL F AI4 U 1H ||I/O module || 0x84 || EtherCAT
|-
|PHOENIX || AXL F AI8 1F ||I/O module || 0x84 ||EtherCAT
|-
|PHOENIX ||AXL F DO 16/1 1H ||I/O module ||0x84 ||EtherCAT
|-
|PHOENIX ||AXL F DI 16/1 1H ||I/O module ||0x84 || EtherCAT
|-
|PHOENIX ||AXL F AO4 1H ||I/O module ||0x84 ||EtherCAT
|-
|PHOENIX ||AXL AI 8-ME ||I/O module ||0x84 ||EtherCAT
|-
|Empower||EIM 9100 ||EtherCAT coupler ||0x1A ||EtherCAT
|-
|Empower||EIM 1016||16 Digital inputs ||0x1A ||EtherCAT
|-
|Empower||EIM 1116||16 Digital inputs ||0x1A ||EtherCAT
|-
|Empower||EIM 2116||16 Digital outputs ||0x1A ||EtherCAT
|-
|Empower||EIM 3118||8 Analog inputs ||0x1A ||EtherCAT
|-
|Empower||EIM 4118||8 Analog outputs ||0x1A ||EtherCAT
|-
|Empower||EIM 5312||PWM module ||0x1A ||EtherCAT
|-
|Empower||EIM 5322 ||PWM module ||0x1A ||EtherCAT
|-
|FESTO||CTEU-EC 572556||EtherCAT bus node ||0x00000026 ||EtherCAT
|-
|Optoforce||HEX-70-XE ||Force Sensor ||0x5D4||EtherCAT
|}

== Cards ==
Following table present Cards that where validate with the softMC 
{| class="wikitable"
|-
! scope="col"|Manufacture || ! scope="col"| PN ||! scope="col"| Description ||! scope="col"| Vendor ||! scope="col"| FieldBUS
|-
|hilscher||CIFX 50-RE ||Communication Interface PCI Real-Time-Ethernet || || EtherCAT
|}

== HMI ==
Following table present HMI that where validate with the softMC 
{| class="wikitable"
|-
! scope="col"|Manufacture || ! scope="col"| PN ||! scope="col"| Description ||! scope="col"| Vendor ||! scope="col"| FieldBUS
|-
|Exor||+ESMA07MU301 ||7 eSMART07M" TFT 16:9 wide color display || || Modbus TCP/IP
|-
|M2i||XTOP07TW-LD-E ||7" 800x480 TFT color display || || Modbus TCP/IP
|-
|Samkon||SK-xxxAS ||5" 7.2" 10.2" with Ethernet || || Modbus TCP/IP
|-
|Kinco||MT4x3xT&TE ||4.3" 7" 10" with Ethernet || || Modbus TCP/IP
|}

Welcome

2018-06-06T07:26:27Z

Itay:

{{Languages|Welcome}}

= softMC - Multi-axis motion control =

{|style="text-align: center ;"width: 10px;" "align="center"
|[[File:SERmoc HiRes.jpg|center|100px]]
|
|[[File:703.PNG| center|100px]]
|
|[[File:MC-Exx-702-0000_1.jpg|center|150px]]
|-
|'''softMC 3 - Compact Motion controller''' The smallest motion controller in its performance class, supports 1 to 6 axes of synchronized, coordinated motion with EtherCAT or CANopen communication ||style="width: 7em;"|
|'''softMC 703 - Multi Axis Motion Controller''' Compact multi-axis control software and hardware package, that supports 1 to 64 axes with EtherCAT communication, for a variety of automation and robotics applications||style="width: 7em;"|
|'''softMC 702 - Multi Axis Motion Controller''' Multi-axis motion control software and hardware package, that supports 1 to 64 axes with EtherCAT and CANopen communication, for a variety of automation and robotics applications||style="width: 30em;"|
|}
 
Multi axis motion control software and hardware package, offering extensive programming capabilities that have been successfully implemented in a variety of automation and robotic applications. softMC is designed to seamlessly integrate with Servotronix’s servo and stepper drive-motor systems to provide a complete motion solution in a cost effective package.

* '''Open, modular, and modern machine control environment'''
* '''Linux operating system with real-time extensions'''
* '''Ethernet machine interface'''
* '''Support for EtherCAT® and CANopen® motion buses'''
* '''Controls up to 64 interpolated axes'''
* '''Extensive capabilities for both standard and non-standard robotic kinematics'''
* '''Rich programming language that allows complete flexibility to create motion programs, with support for pre-emptive multi-tasking and asynchronous event response'''
* '''Support IEC 61131 PLCopen wwith CODESYS'''
* '''Customized software solution can be embedded into the customer‘s hardware'''

= Highlight of Recent Changes/Additions (3 months) =

* [[Getting_Started_with_MC-Basic_and_ControlStudio|Getting Started with MC-Basic and ControlStudio - '''new''']]
* [[:Category:MC-Basic:Commands | Lot of commands/properties now available in Chinese!]]
* [[MC-Basic:WITHGLOBAL | WITHGLOBAL - '''new''']]
* [[Work_Space_Limits | Workspace limits - '''new''']]
* [[Program_Examples:force_sensor | Program_Examples:force_sensor - '''new''']]
* [[Program Examples: PIPEMODE library and motion commands| Program_Examples: PIPEMODE_library_and_motion_commands- '''new''']]
* [[MC-Basic:element.STOPTYPE| Explanation of different StopType's given ]]
* [[MC-Basic:element.PROFILERTYPE| Explanation of different motion profiles given ]]
* [[Motion_Project_Example:_Cartesian_Robot | Full example for a cartesian robot (configurator + Control Studio]]
* [[Motion_Project_Example:_Single_Axis_With_CDHD| Single Axis With CDHD project - complete example (configurator + Control Studio]]
* [[Modbus_Communication_API | Modbus - MB Requred files '''updated''']]
* [[Inverse_Dynamic_Model | Inverse_Dynamic_Model- '''new''' ]]
* [[Motion_Project_Example:_Scara_Robot_simulated | Motion_Project_Example:_Scara_Robot_simulated - '''new''']]
* [[WorkSpace_areas | Work-Space areas - '''new''']]
* [[Program_Examples:_WorkSpace_areas | Work-Space areas '''example - new''']]

=Contact=
==Global Headquarters==
Servotronix Motion Control Ltd. 21C Yagia Kapayim Street, P.O.B. 3919 Petach Tikva 49130, Israel 
Tel: +97239273800 
Fax: +97239228075 
info@servotronix.com 
Website: www.servotronix.com 
Technical support: tech.support@servotronix.com

== China ==
Servotronix Motion Technology Development (Shenzhen) Ltd. 
Room 202, Building A1, Kexing Science Park, No.15 Keyuan Road, Nanshan District, Shenzhen 518057, China 
Tel: +8675586626603 
Fax: +8675586626665 
info_china@servotronix.com 

==Europe==
Servotronix GmbH Dülkener Straße 5 D-41334 Nettetal, Germany 
Tel: +4921531398586

==Korea==
Servotronix Motion Control Korea 
IS BIZ Tower #1315, 57-1 Heungan-daero 427beon-gil 
Dongan-gu,Anyang-si,Gyeonggi-do (14059) South Korea 
whangsoon.joo@servotronix.com

Welcome

2018-06-06T05:47:53Z

Itay: /* softMC - Multi-axis motion control */

{{Languages}}

= softMC - Multi-axis motion control =

{|style="text-align: center ;"width: 10px;" "align="center"
|[[File:SERmoc HiRes.jpg|center|100px]]
|
|[[File:703.PNG| center|100px]]
|
|[[File:MC-Exx-702-0000_1.jpg|center|100px]]
|-
|'''softMC 3 - Compact Motion controller''' The smallest motion controller in its performance class, supports 1 to 6 axes of synchronized, coordinated motion with EtherCAT or CANopen communication ||style="width: 7em;"|
|'''softMC 703 - Multi Axis Motion Controller''' Compact multi-axis control software and hardware package, that supports 1 to 64 axes with EtherCAT communication, for a variety of automation and robotics applications||style="width: 7em;"|
|'''softMC 702 - Multi Axis Motion Controller''' Multi-axis motion control software and hardware package, that supports 1 to 64 axes with EtherCAT and CANopen communication, for a variety of automation and robotics applications||style="width: 60em;"|
|}
 
Multi axis motion control software and hardware package, offering extensive programming capabilities that have been successfully implemented in a variety of automation and robotic applications. softMC is designed to seamlessly integrate with Servotronix’s servo and stepper drive-motor systems to provide a complete motion solution in a cost effective package.

* '''Open, modular, and modern machine control environment'''
* '''Linux operating system with real-time extensions'''
* '''Ethernet machine interface'''
* '''Support for EtherCAT® and CANopen® motion buses'''
* '''Controls up to 64 interpolated axes'''
* '''Extensive capabilities for both standard and non-standard robotic kinematics'''
* '''Rich programming language that allows complete flexibility to create motion programs, with support for pre-emptive multi-tasking and asynchronous event response'''
* '''Support IEC 61131 PLCopen wwith CODESYS'''
* '''Customized software solution can be embedded into the customer‘s hardware'''

= Highlight of Recent Changes/Additions (3 months) =

* [[Getting_Started_with_MC-Basic_and_ControlStudio|Getting Started with MC-Basic and ControlStudio - '''new''']]
* [[:Category:MC-Basic:Commands | Lot of commands/properties now available in Chinese!]]
* [[MC-Basic:WITHGLOBAL | WITHGLOBAL - '''new''']]
* [[Work_Space_Limits | Workspace limits - '''new''']]
* [[Program_Examples:force_sensor | Program_Examples:force_sensor - '''new''']]
* [[Program Examples: PIPEMODE library and motion commands| Program_Examples: PIPEMODE_library_and_motion_commands- '''new''']]
* [[MC-Basic:element.STOPTYPE| Explanation of different StopType's given ]]
* [[MC-Basic:element.PROFILERTYPE| Explanation of different motion profiles given ]]
* [[Motion_Project_Example:_Cartesian_Robot | Full example for a cartesian robot (configurator + Control Studio]]
* [[Motion_Project_Example:_Single_Axis_With_CDHD| Single Axis With CDHD project - complete example (configurator + Control Studio]]
* [[Modbus_Communication_API | Modbus - MB Requred files '''updated''']]
* [[Inverse_Dynamic_Model | Inverse_Dynamic_Model- '''new''' ]]
* [[Motion_Project_Example:_Scara_Robot_simulated | Motion_Project_Example:_Scara_Robot_simulated - '''new''']]
* [[WorkSpace_areas | Work-Space areas - '''new''']]
* [[Program_Examples:_WorkSpace_areas | Work-Space areas '''example - new''']]

=Contact=
==Global Headquarters==
Servotronix Motion Control Ltd. 21C Yagia Kapayim Street, P.O.B. 3919 Petach Tikva 49130, Israel 
Tel: +97239273800 
Fax: +97239228075 
info@servotronix.com 
Website: www.servotronix.com 
Technical support: tech.support@servotronix.com

== China ==
Servotronix Motion Technology Development (Shenzhen) Ltd. 
Room 202, Building A1, Kexing Science Park, No.15 Keyuan Road, Nanshan District, Shenzhen 518057, China 
Tel: +8675586626603 
Fax: +8675586626665 
info_china@servotronix.com 

==Europe==
Servotronix GmbH Dülkener Straße 5 D-41334 Nettetal, Germany 
Tel: +4921531398586

==Korea==
Servotronix Motion Control Korea 
IS BIZ Tower #1315, 57-1 Heungan-daero 427beon-gil 
Dongan-gu,Anyang-si,Gyeonggi-do (14059) South Korea 
whangsoon.joo@servotronix.com

File:scara.zip

2018-05-16T07:15:37Z

Itay: Itay uploaded a new version of "File:scara.zip"

Program Examples: WorkSpace areas

2018-05-13T07:59:56Z

Itay:

{{Languages|Program_Examples:_WorkSpace_areas}}
<div id="BackToTop" class="noprint" style="background-color:; position:fixed; bottom:32px; left:95%; z-index:9999; padding:0; margin:0;">

[[Image:TOP2.png|50px|link=#top]] </div>

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}
{{Note|For more information about WorkSpace area definitions, and what the XML file contains please refer to [[WorkSpace areas]] page.}}
=Steps=
==Step 1==
Make sure that the relevant XML file is within your project folder. 
The XML file should be in this structure:
<syntaxhighlight lang='XML'>

<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>

<workspace number="2" name = "First_pos">
<origin x="-50" y="350" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="1" x="100" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="3" x="0" y="0" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>

<workspace number="3" name = "Second_pos">
<origin x="-50" y="-450" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="2" x="0" y="100" z="50"/>
</entry_points>
<exit_points>
<point ws_num="1" x="100" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>

</workspace_set>

</syntaxhighlight>
==Step 2==
After XML created and located at project folder, send the following commands from CS terminal: 
<syntaxhighlight lang=freebasic>
--> SEND SCARAEX.XML ' Need to get "done" message back
--> Reset all
--> load STARTPRG.PRG
</syntaxhighlight>

'''Now your system is ready to use WorkSpaces setting as you create in the XML file.'''

==Step 3==
Create task for your robot, under WorkSpaces limitations, for example: 

<syntaxhighlight lang=freebasic>

dim shared lFlag as long

program

dim lLoadXMLSeting as long
dim lRobotID as long = scara1.ElementID
dim NumWSPC as long
dim lTemp as long
dim lSecTemp as long
dim locTempExLocation as generic location
dim locTempEnLocation as generic location
dim locExCurr as location of XYZR
dim locEnCurr as location of XYZR

withglobal scara1

print RobotSetup
attach
pemax = 10

lLoadXMLSeting = WSPC_PARSE_XML(lRobotID, "SCARAEX.XML")
NumWSPC = WSPC_GET_NUM(lRobotID)

if NOT lLoadXMLSeting then
print "WorkSpace definitions completed"
end if 'if there is an error - MC will throw it's message

print str$(NumWSPC) + " WSPC defined"

lTemp = WSPC_ACTIVATE_ALL(lRobotID)
if NOT lTemp then
print "All WSPC are activate"
else
print "Failed to activate all WSPC"
end if

print ExitSet(lRobotID, 1, 2, locTempExLocation)
print EntrySet(lRobotID, 2, 1, locTempEnLocation)
lTemp = CurrectLoc(locTempExLocation, locExCurr)
lSecTemp = CurrectLoc(locTempEnLocation, locEnCurr)
print RobotMovesFromWSPCto (lFlag, locExCurr, locEnCurr)

print ExitSet(lRobotID, 2, 3, locTempExLocation)
print EntrySet(lRobotID, 3, 2, locTempEnLocation)
lTemp = CurrectLoc(locTempExLocation, locExCurr)
lSecTemp = CurrectLoc(locTempEnLocation, locEnCurr)
print RobotMovesFromWSPCto (lFlag, locExCurr, locEnCurr)

print ExitSet(lRobotID, 3, 1, locTempExLocation)
print EntrySet(lRobotID, 1, 3, locTempEnLocation)
lTemp = CurrectLoc(locTempExLocation, locExCurr)
lSecTemp = CurrectLoc(locTempEnLocation, locEnCurr)
print RobotMovesFromWSPCto (lFlag, locExCurr, locEnCurr)

try
moves #{450, 300, 0,0}
catch else
print "Can't reach a point that is not defined within WorkSpace"
end try

sleep 10
lTemp = WSPC_DEACTIVATE_ALL(lRobotID)
if NOT lTemp then
print "All WSPC deactivate"
else
print "Failed to deactivate all WSPC"
end if

detach

end program

function ExitSet (byval lRobotID as long, byval WSPCFrom as long, byval WSPCTo as long, exit_loc as generic location) as string
dim lTemp as long

lTemp = WSPC_FIND_EXIT(lRobotID, WSPCFrom, WSPCTo, exit_loc)
if NOT lTemp then
ExitSet = "exit point location setup succeeded"
lFlag = 1
else
ExitSet = "exit point location setup failed"
lFlag = 0
end if

end function

function EntrySet (byval lRobotID as long, byval WSPCTo as long, byval WSPCFrom as long, entry_loc as generic location) as string
dim lTemp as long

lTemp = WSPC_FIND_ENTRY(lRobotID, WSPCTo, WSPCFrom, entry_loc)
if NOT lTemp then
entrySet = "entry point location setup succeeded"
lFlag = 1
else
entrySet = "entry point location setup failed"
lFlag = 0
end if

end function

function RobotMovesFromWSPCto(byval lMotFlag as long, exit_Loc as generic location, entry_Loc as generic location) as string
try
if lMotFlag then
En = 1
moves exit_Loc vcruise = 5
while IsMoving <>0
sleep 1
end while

moves entry_Loc vcruise = 5
while IsMoving <>0
sleep 1
end while
en = 0
RobotMovesFromWSPCto = "movement completed"
else
RobotMovesFromWSPCto = "can't execute movement"
end if

catch else
RobotMovesFromWSPCto = "can't execute movement"
end try

end function

function CurrectLoc(old_Loc as generic location, new_Loc as generic location) as long
dim i as long

for i = 1 to 3
new_Loc{i} = old_loc{i}
next

end function

function RobotSetup as string
dim i as long
dim genAxis as generic axis
for i = 1 to 4
genAxis = SystemAxis(i)
attach genAxis
genAxis.pemax = 10
genAxis.en = 1
move genAxis 0 abs = 1 vcruise = 50
while genAxis.ismoving<> 0
sleep 1
end while
genAxis.en = 0
detach genAxis

next

RobotSetup = "Setup Done"

end function

</syntaxhighlight>

Program Examples: WorkSpace areas

2018-05-13T07:57:06Z

Itay:

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}
{{Note|For more information about WorkSpace area definitions, and what the XML file contains please refer to [[WorkSpace areas]] page.}}
=Steps=
==Step 1==
Make sure that the relevant XML file is within your project folder. 
The XML file should be in this structure:
<syntaxhighlight lang='XML'>

<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>

<workspace number="2" name = "First_pos">
<origin x="-50" y="350" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="1" x="100" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="3" x="0" y="0" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>

<workspace number="3" name = "Second_pos">
<origin x="-50" y="-450" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="2" x="0" y="100" z="50"/>
</entry_points>
<exit_points>
<point ws_num="1" x="100" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>

</workspace_set>

</syntaxhighlight>
==Step 2==
After XML created and located at project folder, send the following commands from CS terminal: 
<syntaxhighlight lang=freebasic>
--> SEND SCARAEX.XML ' Need to get "done" message back
--> Reset all
--> load STARTPRG.PRG
</syntaxhighlight>

'''Now your system is ready to use WorkSpaces setting as you create in the XML file.'''

==Step 3==
Create task for your robot, under WorkSpaces limitations, for example: 

<syntaxhighlight lang=freebasic>

dim shared lFlag as long

program

dim lLoadXMLSeting as long
dim lRobotID as long = scara1.ElementID
dim NumWSPC as long
dim lTemp as long
dim lSecTemp as long
dim locTempExLocation as generic location
dim locTempEnLocation as generic location
dim locExCurr as location of XYZR
dim locEnCurr as location of XYZR

withglobal scara1

print RobotSetup
attach
pemax = 10

lLoadXMLSeting = WSPC_PARSE_XML(lRobotID, "SCARAEX.XML")
NumWSPC = WSPC_GET_NUM(lRobotID)

if NOT lLoadXMLSeting then
print "WorkSpace definitions completed"
end if 'if there is an error - MC will throw it's message

print str$(NumWSPC) + " WSPC defined"

lTemp = WSPC_ACTIVATE_ALL(lRobotID)
if NOT lTemp then
print "All WSPC are activate"
else
print "Failed to activate all WSPC"
end if

print ExitSet(lRobotID, 1, 2, locTempExLocation)
print EntrySet(lRobotID, 2, 1, locTempEnLocation)
lTemp = CurrectLoc(locTempExLocation, locExCurr)
lSecTemp = CurrectLoc(locTempEnLocation, locEnCurr)
print RobotMovesFromWSPCto (lFlag, locExCurr, locEnCurr)

print ExitSet(lRobotID, 2, 3, locTempExLocation)
print EntrySet(lRobotID, 3, 2, locTempEnLocation)
lTemp = CurrectLoc(locTempExLocation, locExCurr)
lSecTemp = CurrectLoc(locTempEnLocation, locEnCurr)
print RobotMovesFromWSPCto (lFlag, locExCurr, locEnCurr)

print ExitSet(lRobotID, 3, 1, locTempExLocation)
print EntrySet(lRobotID, 1, 3, locTempEnLocation)
lTemp = CurrectLoc(locTempExLocation, locExCurr)
lSecTemp = CurrectLoc(locTempEnLocation, locEnCurr)
print RobotMovesFromWSPCto (lFlag, locExCurr, locEnCurr)

try
moves #{450, 300, 0,0}
catch else
print "Can't reach a point that is not defined within WorkSpace"
end try

sleep 10
lTemp = WSPC_DEACTIVATE_ALL(lRobotID)
if NOT lTemp then
print "All WSPC deactivate"
else
print "Failed to deactivate all WSPC"
end if

detach

end program

function ExitSet (byval lRobotID as long, byval WSPCFrom as long, byval WSPCTo as long, exit_loc as generic location) as string
dim lTemp as long

lTemp = WSPC_FIND_EXIT(lRobotID, WSPCFrom, WSPCTo, exit_loc)
if NOT lTemp then
ExitSet = "exit point location setup succeeded"
lFlag = 1
else
ExitSet = "exit point location setup failed"
lFlag = 0
end if

end function

function EntrySet (byval lRobotID as long, byval WSPCTo as long, byval WSPCFrom as long, entry_loc as generic location) as string
dim lTemp as long

lTemp = WSPC_FIND_ENTRY(lRobotID, WSPCTo, WSPCFrom, entry_loc)
if NOT lTemp then
entrySet = "entry point location setup succeeded"
lFlag = 1
else
entrySet = "entry point location setup failed"
lFlag = 0
end if

end function

function RobotMovesFromWSPCto(byval lMotFlag as long, exit_Loc as generic location, entry_Loc as generic location) as string
try
if lMotFlag then
En = 1
moves exit_Loc vcruise = 5
while IsMoving <>0
sleep 1
end while

moves entry_Loc vcruise = 5
while IsMoving <>0
sleep 1
end while
en = 0
RobotMovesFromWSPCto = "movement completed"
else
RobotMovesFromWSPCto = "can't execute movement"
end if

catch else
RobotMovesFromWSPCto = "can't execute movement"
end try

end function

function CurrectLoc(old_Loc as generic location, new_Loc as generic location) as long
dim i as long

for i = 1 to 3
new_Loc{i} = old_loc{i}
next

end function

function RobotSetup as string
dim i as long
dim genAxis as generic axis
for i = 1 to 4
genAxis = SystemAxis(i)
attach genAxis
genAxis.pemax = 10
genAxis.en = 1
move genAxis 0 abs = 1 vcruise = 50
while genAxis.ismoving<> 0
sleep 1
end while
genAxis.en = 0
detach genAxis

next

RobotSetup = "Setup Done"

end function

</syntaxhighlight>

Program Examples: WorkSpace areas

2018-05-13T07:56:16Z

Itay: /* Steps */

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}
=Steps=
==Step 1==
Make sure that the relevant XML file is within your project folder. 
For more information about WorkSpace area definitions, and what the XML file contains please refer to [[WorkSpace areas]] page. 
The XML file should be in this structure:
<syntaxhighlight lang='XML'>

<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>

<workspace number="2" name = "First_pos">
<origin x="-50" y="350" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="1" x="100" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="3" x="0" y="0" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>

<workspace number="3" name = "Second_pos">
<origin x="-50" y="-450" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="2" x="0" y="100" z="50"/>
</entry_points>
<exit_points>
<point ws_num="1" x="100" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>

</workspace_set>

</syntaxhighlight>
==Step 2==
After XML created and located at project folder, send the following commands from CS terminal: 
<syntaxhighlight lang=freebasic>
--> SEND SCARAEX.XML ' Need to get "done" message back
--> Reset all
--> load STARTPRG.PRG
</syntaxhighlight>

'''Now your system is ready to use WorkSpaces setting as you create in the XML file.'''

==Step 3==
Create task for your robot, under WorkSpaces limitations, for example: 

<syntaxhighlight lang=freebasic>

dim shared lFlag as long

program

dim lLoadXMLSeting as long
dim lRobotID as long = scara1.ElementID
dim NumWSPC as long
dim lTemp as long
dim lSecTemp as long
dim locTempExLocation as generic location
dim locTempEnLocation as generic location
dim locExCurr as location of XYZR
dim locEnCurr as location of XYZR

withglobal scara1

print RobotSetup
attach
pemax = 10

lLoadXMLSeting = WSPC_PARSE_XML(lRobotID, "SCARAEX.XML")
NumWSPC = WSPC_GET_NUM(lRobotID)

if NOT lLoadXMLSeting then
print "WorkSpace definitions completed"
end if 'if there is an error - MC will throw it's message

print str$(NumWSPC) + " WSPC defined"

lTemp = WSPC_ACTIVATE_ALL(lRobotID)
if NOT lTemp then
print "All WSPC are activate"
else
print "Failed to activate all WSPC"
end if

print ExitSet(lRobotID, 1, 2, locTempExLocation)
print EntrySet(lRobotID, 2, 1, locTempEnLocation)
lTemp = CurrectLoc(locTempExLocation, locExCurr)
lSecTemp = CurrectLoc(locTempEnLocation, locEnCurr)
print RobotMovesFromWSPCto (lFlag, locExCurr, locEnCurr)

print ExitSet(lRobotID, 2, 3, locTempExLocation)
print EntrySet(lRobotID, 3, 2, locTempEnLocation)
lTemp = CurrectLoc(locTempExLocation, locExCurr)
lSecTemp = CurrectLoc(locTempEnLocation, locEnCurr)
print RobotMovesFromWSPCto (lFlag, locExCurr, locEnCurr)

print ExitSet(lRobotID, 3, 1, locTempExLocation)
print EntrySet(lRobotID, 1, 3, locTempEnLocation)
lTemp = CurrectLoc(locTempExLocation, locExCurr)
lSecTemp = CurrectLoc(locTempEnLocation, locEnCurr)
print RobotMovesFromWSPCto (lFlag, locExCurr, locEnCurr)

try
moves #{450, 300, 0,0}
catch else
print "Can't reach a point that is not defined within WorkSpace"
end try

sleep 10
lTemp = WSPC_DEACTIVATE_ALL(lRobotID)
if NOT lTemp then
print "All WSPC deactivate"
else
print "Failed to deactivate all WSPC"
end if

detach

end program

function ExitSet (byval lRobotID as long, byval WSPCFrom as long, byval WSPCTo as long, exit_loc as generic location) as string
dim lTemp as long

lTemp = WSPC_FIND_EXIT(lRobotID, WSPCFrom, WSPCTo, exit_loc)
if NOT lTemp then
ExitSet = "exit point location setup succeeded"
lFlag = 1
else
ExitSet = "exit point location setup failed"
lFlag = 0
end if

end function

function EntrySet (byval lRobotID as long, byval WSPCTo as long, byval WSPCFrom as long, entry_loc as generic location) as string
dim lTemp as long

lTemp = WSPC_FIND_ENTRY(lRobotID, WSPCTo, WSPCFrom, entry_loc)
if NOT lTemp then
entrySet = "entry point location setup succeeded"
lFlag = 1
else
entrySet = "entry point location setup failed"
lFlag = 0
end if

end function

function RobotMovesFromWSPCto(byval lMotFlag as long, exit_Loc as generic location, entry_Loc as generic location) as string
try
if lMotFlag then
En = 1
moves exit_Loc vcruise = 5
while IsMoving <>0
sleep 1
end while

moves entry_Loc vcruise = 5
while IsMoving <>0
sleep 1
end while
en = 0
RobotMovesFromWSPCto = "movement completed"
else
RobotMovesFromWSPCto = "can't execute movement"
end if

catch else
RobotMovesFromWSPCto = "can't execute movement"
end try

end function

function CurrectLoc(old_Loc as generic location, new_Loc as generic location) as long
dim i as long

for i = 1 to 3
new_Loc{i} = old_loc{i}
next

end function

function RobotSetup as string
dim i as long
dim genAxis as generic axis
for i = 1 to 4
genAxis = SystemAxis(i)
attach genAxis
genAxis.pemax = 10
genAxis.en = 1
move genAxis 0 abs = 1 vcruise = 50
while genAxis.ismoving<> 0
sleep 1
end while
genAxis.en = 0
detach genAxis

next

RobotSetup = "Setup Done"

end function

</syntaxhighlight>

Program Examples: WorkSpace areas

2018-05-13T05:53:28Z

Itay:

WorkSpace areas

2018-05-13T05:29:16Z

Itay: Created page with "{{Languages}} <div id="BackToTop" class="noprint" style="background-color:; position:fixed; bottom:32px; left:95%; z-index:9999; padding:0; margin:0;"> <span style="color:blu..."

{{Languages|WorkSpace_areas}}
<div id="BackToTop" class="noprint" style="background-color:; position:fixed; bottom:32px; left:95%; z-index:9999; padding:0; margin:0;">

[[Image:TOP2.png|50px|link=#top]] </div>

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Functions=
{{Note | '''''RobotId''''' is a long value, which sets using ''<element>.ElementID'' query}}
{|class="wikitable" style="text-align: left"
|'''Function Name'''
|'''Description'''
|'''Return Value'''
|-
|WSPC_PARSE_XML(byval RobotId as long, XML file as string) as long
|Get workSpaces setting as defined by user.
| 0 - Execution succeeded MC error number - Execution failed
|-
|WSPC_GET_NUM (byval RobotId as long) as long
|Return how many WorkSpaces defined for each robot.
|Number of Workspaces - long format
|-
|WSPC_ACTIVATE_ALL(byval RobotId as long) as long
|Activate all WorkSpaces which exist in the system.
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_DEACTIVATE_ALL(byval RobotId as long) as long
|Deactivate all WorkSpaces which exist in the system.
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_ACTIVATE(byval RobotId as long, byval workspace_number as long) as long
|Activate specific WorkSpace
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_DEACTIVATE(byval RobotId as long, byval workspace_number as long) as long
|Dectivate specific WorkSpace
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_GET_INDEX(byval RobotId as long) as long
|Return WorkSpace indexs which the robot within
|BIN format - as Workspaces indexs
|-
|WSPC_FIND_ENTRY(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, entry_loc as generic location) as long
|Defined entry location according to currnet Workspaces and the linked Workspaces
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_FIND_EXIT(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, exit_loc as generic location) as long
|Defined exit location according to currnet WSPC and the linked WSPC
| 0 - Execution succeeded 1 - Execution failed
|}

Motion Control

2018-05-13T05:28:23Z

Itay: /* Group and Robot Motion */

Program Examples: WorkSpace areas

2018-05-10T05:42:19Z

Itay: /* WorkSpace Functions */

{{Languages}}
<div id="BackToTop" class="noprint" style="background-color:; position:fixed; bottom:32px; left:95%; z-index:9999; padding:0; margin:0;">

[[Image:TOP2.png|50px|link=#top]] </div>

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Functions=
{{Note | '''''RobotId''''' is a long value, which sets using ''<element>.ElementID'' query}}
{|class="wikitable" style="text-align: left"
|'''Function Name'''
|'''Description'''
|'''Return Value'''
|-
|WSPC_PARSE_XML(byval RobotId as long, XML file as string) as long
|Get workSpaces setting as defined by user.
| 0 - Execution succeeded MC error number - Execution failed
|-
|WSPC_GET_NUM (byval RobotId as long) as long
|Return how many WorkSpaces defined for each robot.
|Number of Workspaces - long format
|-
|WSPC_ACTIVATE_ALL(byval RobotId as long) as long
|Activate all WorkSpaces which exist in the system.
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_DEACTIVATE_ALL(byval RobotId as long) as long
|Deactivate all WorkSpaces which exist in the system.
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_ACTIVATE(byval RobotId as long, byval workspace_number as long) as long
|Activate specific WorkSpace
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_DEACTIVATE(byval RobotId as long, byval workspace_number as long) as long
|Dectivate specific WorkSpace
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_GET_INDEX(byval RobotId as long) as long
|Return WorkSpace indexs which the robot within
|BIN format - as Workspaces indexs
|-
|WSPC_FIND_ENTRY(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, entry_loc as generic location) as long
|Defined entry location according to currnet Workspaces and the linked Workspaces
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_FIND_EXIT(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, exit_loc as generic location) as long
|Defined exit location according to currnet WSPC and the linked WSPC
| 0 - Execution succeeded 1 - Execution failed
|}

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

Program Examples: WorkSpace areas

2018-05-10T05:39:25Z

Itay: /* WorkSpace Functions */

{{Languages}}
<div id="BackToTop" class="noprint" style="background-color:; position:fixed; bottom:32px; left:95%; z-index:9999; padding:0; margin:0;">

[[Image:TOP2.png|50px|link=#top]] </div>

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Functions=
{{Note | '''''RobotId''''' is a long value, which sets using ''<element>.ElementID'' query}}
{|class="wikitable" style="text-align: left"
|'''Function Name'''
|'''Description'''
|'''Return Value'''
|-
|WSPC_PARSE_XML(byval RobotId as long, XML file as string) as long
|Get workSpaces setting has defined by the user.
| 0 - Execution succeeded MC error number - Execution failed
|-
|WSPC_GET_NUM (byval RobotId as long) as long
|How many WorkSpaces defined for each robot.
|Number of Workspaces - long format
|-
|WSPC_ACTIVATE_ALL(byval RobotId as long) as long
|Activate all WorkSpaces exist in the system.
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_DEACTIVATE_ALL(byval RobotId as long) as long
|Deactivate all WorkSpaces exist in the system.
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_ACTIVATE(byval RobotId as long, byval workspace_number as long) as long
| Activate specific WorkSpace
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_DEACTIVATE(byval RobotId as long, byval workspace_number as long) as long
|Dectivate specific WorkSpace
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_GET_INDEX(byval RobotId as long) as long
|return WorkSpace indexs which the robot within
|BIN format - as Workspaces indexs
|-
|WSPC_FIND_ENTRY(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, entry_loc as generic location) as long
|Defined entry location according to currnet Workspaces and the linked Workspaces
| 0 - Execution succeeded 1 - Execution failed
|-
|WSPC_FIND_EXIT(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, exit_loc as generic location) as long
|Defined exit location according to currnet WSPC and the linked WSPC
| 0 - Execution succeeded 1 - Execution failed
|}

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

Program Examples: WorkSpace areas

2018-05-10T05:37:59Z

Itay: /* WorkSpace Functions */

{{Languages}}
<div id="BackToTop" class="noprint" style="background-color:; position:fixed; bottom:32px; left:95%; z-index:9999; padding:0; margin:0;">

[[Image:TOP2.png|50px|link=#top]] </div>

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Functions=
{{Note | '''''RobotId''''' is a long value, which sets using ''<element>.ElementID'' query}}
{|class="wikitable" style="text-align: left"
|'''Function Name'''
|'''Description'''
|'''Return Value'''
|-
|WSPC_PARSE_XML(byval RobotId as long, XML file as string) as long
|Get workSpaces setting has defined by the user.
| 0 - Execution was successful MC error number - Execution failed
|-
|WSPC_GET_NUM (byval RobotId as long) as long
|How many WorkSpaces defined for each robot.
|Number of Workspaces - long format
|-
|WSPC_ACTIVATE_ALL(byval RobotId as long) as long
|Activate all WorkSpaces exist in the system.
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_DEACTIVATE_ALL(byval RobotId as long) as long
|Deactivate all WorkSpaces exist in the system.
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_ACTIVATE(byval RobotId as long, byval workspace_number as long) as long
| Activate specific WorkSpace
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_DEACTIVATE(byval RobotId as long, byval workspace_number as long) as long
|Dectivate specific WorkSpace
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_GET_INDEX(byval RobotId as long) as long
|return WorkSpace indexs which the robot within
|BIN format - as Workspaces indexs
|-
|WSPC_FIND_ENTRY(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, entry_loc as generic location) as long
|Defined entry location according to currnet Workspaces and the linked Workspaces
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_FIND_EXIT(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, exit_loc as generic location) as long
|Defined exit location according to currnet WSPC and the linked WSPC
| 0 - Execution was successful 1 - Execution failed
|}

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

Program Examples: WorkSpace areas

2018-05-09T08:57:38Z

Itay:

{{Languages}}
<div id="BackToTop" class="noprint" style="background-color:; position:fixed; bottom:32px; left:95%; z-index:9999; padding:0; margin:0;">

[[Image:TOP2.png|50px|link=#top]] </div>

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Functions=
{{Note | '''RobotId''' is a long value, which sets using ''<element>.ElementID'' query}}
{|class="wikitable" style="text-align: left"
|'''Function Name'''
|'''Description'''
|'''Return Value'''
|-
|WSPC_PARSE_XML(byval RobotId as long, XML file as string) as long
|Get workSpaces setting has defined by the user.
| 0 - Execution was successful MC error number - Execution failed
|-
|WSPC_GET_NUM (byval RobotId as long) as long
|How many WorkSpaces defined for each robot.
|Number of Workspaces - long format
|-
|WSPC_ACTIVATE_ALL(byval RobotId as long) as long
|Activate all WorkSpaces exist in the system.
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_DEACTIVATE_ALL(byval RobotId as long) as long
|Deactivate all WorkSpaces exist in the system.
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_ACTIVATE(byval RobotId as long, byval workspace_number as long) as long
| Activate specific WorkSpace
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_DEACTIVATE(byval RobotId as long, byval workspace_number as long) as long
|Dectivate specific WorkSpace
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_GET_INDEX(byval RobotId as long) as long
|return WorkSpace indexs which the robot within
|BIN format - as Workspaces indexs
|-
|WSPC_FIND_ENTRY(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, entry_loc as generic location) as long
|Defined entry location according to currnet Workspaces and the linked Workspaces
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_FIND_EXIT(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, exit_loc as generic location) as long
|Defined exit location according to currnet WSPC and the linked WSPC
| 0 - Execution was successful 1 - Execution failed
|}

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

Program Examples: WorkSpace areas

2018-05-09T08:57:03Z

Itay: /* WorkSpace Functions */

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Functions=
{{Note | '''RobotId''' is a long value, which sets using ''<element>.ElementID'' query}}
{|class="wikitable" style="text-align: left"
|'''Function Name'''
|'''Description'''
|'''Return Value'''
|-
|WSPC_PARSE_XML(byval RobotId as long, XML file as string) as long
|Get workSpaces setting has defined by the user.
| 0 - Execution was successful MC error number - Execution failed
|-
|WSPC_GET_NUM (byval RobotId as long) as long
|How many WorkSpaces defined for each robot.
|Number of Workspaces - long format
|-
|WSPC_ACTIVATE_ALL(byval RobotId as long) as long
|Activate all WorkSpaces exist in the system.
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_DEACTIVATE_ALL(byval RobotId as long) as long
|Deactivate all WorkSpaces exist in the system.
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_ACTIVATE(byval RobotId as long, byval workspace_number as long) as long
| Activate specific WorkSpace
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_DEACTIVATE(byval RobotId as long, byval workspace_number as long) as long
|Dectivate specific WorkSpace
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_GET_INDEX(byval RobotId as long) as long
|return WorkSpace indexs which the robot within
|BIN format - as Workspaces indexs
|-
|WSPC_FIND_ENTRY(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, entry_loc as generic location) as long
|Defined entry location according to currnet Workspaces and the linked Workspaces
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_FIND_EXIT(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, exit_loc as generic location) as long
|Defined exit location according to currnet WSPC and the linked WSPC
| 0 - Execution was successful 1 - Execution failed
|}

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

Program Examples: WorkSpace areas

2018-05-09T08:55:16Z

Itay: /* WorkSpace Functions */

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Functions=
{|class="wikitable" style="text-align: left"
|'''Function Name'''
|'''Description'''
|'''Return Value'''
|-
|WSPC_PARSE_XML(byval RobotId as long, XML file as string) as long
|Get workSpaces setting has defined by the user.
| 0 - Execution was successful MC error number - Execution failed
|-
|WSPC_GET_NUM (byval RobotId as long) as long
|How many WorkSpaces defined for each robot.
|Number of Workspaces - long format
|-
|WSPC_ACTIVATE_ALL(byval RobotId as long) as long
|Activate all WorkSpaces exist in the system.
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_DEACTIVATE_ALL(byval RobotId as long) as long
|Deactivate all WorkSpaces exist in the system.
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_ACTIVATE(byval RobotId as long, byval workspace_number as long) as long
| Activate specific WorkSpace
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_DEACTIVATE(byval RobotId as long, byval workspace_number as long) as long
|Dectivate specific WorkSpace
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_GET_INDEX(byval RobotId as long) as long
|return WorkSpace indexs which the robot within
|BIN format - as Workspaces indexs
|-
|WSPC_FIND_ENTRY(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, entry_loc as generic location) as long
|Defined entry location according to currnet Workspaces and the linked Workspaces
| 0 - Execution was successful 1 - Execution failed
|-
|WSPC_FIND_EXIT(byval RobotId as long, byval workspace_number as long, byval linked_workspace_number as long, exit_loc as generic location) as long
|Defined exit location according to currnet WSPC and the linked WSPC
| 0 - Execution was successful 1 - Execution failed
|}

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

Program Examples: WorkSpace areas

2018-05-09T08:37:23Z

Itay:

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Functions=

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

Program Examples: WorkSpace areas

2018-05-09T08:36:22Z

Itay: /* Introduction */

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

Program Examples: WorkSpace areas

2018-05-09T08:35:12Z

Itay: /* Introduction */

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}
{{Note| For more information about WorkSpace functions please refer to WSPC.LIB file, attached to example files in the example section}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

Program Examples: WorkSpace areas

2018-05-09T08:34:49Z

Itay: /* Introduction */

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}
{{Note| For more information about WorkSpace function please refer to WSPC.LIB file, attached to example files in the example section}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

Program Examples: WorkSpace areas

2018-05-09T08:33:05Z

Itay:

=Introduction=
This feature limits robot movements inside defined WorkSpaces areas and at specific paths between them. Each WorkSpaces is modeled by users as a rectangular prism in 3D space with entry and exit points, which defined in '''*.XML''' file. 
Robot is considered to be '''inside''' WorkSpaces if its TCP (Tool Center Point) is within the prism and '''outside''' WorkSpaces if its TCP is outside the prism. 
In case user tries to move the robot outside WorkSpaces using unauthorized path an error will raise and motion won't be started. 
{{Note | Robot segments are not considered}}

=WorkSpace Properties=
WorkSpaces are cuboids defined by its four vertex points:
* Origin (O)
* Width (W)
* Length (L)
* Height (H)
The cuboid can have any orientation in space. The coordinates of the cuboid are given in '''WorkPiece''' coordinates of the robot TCP (including tool). 
Cuboid parameter defines relative to WorkSpace origin:
* O = #{X,Y,Z,Yaw,Pitch,Roll} - location
* L = O:#{0,WSCPL,0,0,0,0}
* W = O:#{WSCPW,0,0,0,0,0}
* H = O:#{0,0,WSCPH,0,0,0}
When '''WSPCL''' = WorkSpace length, '''WSPCW''' = WorkSpace width, '''WSPCH''' = WorkSpace height.
To sets a proper WorkSpace one need to follow these rules:
# WorkSpaces are grouped in WorkSpace-sets. There will be maximum 16 WorkSpace defined in one WorkSpace-set when each WorkSpace-set belongs to only one robot.
# WorkSpace will be indexed by unique numbers 1, 2, 3, ...
# Only '''active''' WorkSpace is considered.
# WorkSpace areas won't be able to edit (change) while robot is enabled (powered-on).
# WorkSpace can be '''activated''' only when the robot is disabled (powered-off).
# WorkSpace areas won't be active during '''conveyer tracking'''.
# In the first phase, if there are active WorkSpace lined to a robot joint-interpolated motions (MOVE) will be not allowed!
# Each WorkSpace area will have a set of '''entry & exit''' points: (En1,En2, …) and (Ex1,Ex2, …) defining exit and entry paths from one workspace to another.
# Entry and exit points will be '''defined only''' by #{X,Y,Z} relative to the origin (O) of the related working space.
# Entry and exit points '''must lie on the surface''' of the WorkSpace (not inside the WorkSpace).
# Entry and exit points will be defined with a '''tolerance radius R''' meaning that if the robot TCP is at distance less then R from the given point it will be considered at this point. The tolerance will be described by half-sphere of radius R – meaning only the half that is inside given WorkSpace is valid.
# There will be only one exit and one entry path from one given pair of WorkSpaces
# User can move the robot from one WorkSpace area to another only if:
## Movement is straight line movement (MOVES, MOVESKD), other interpolation types like: CIRCLE, MOVE, JOG are not allowed.
## Movement starts from one of the exit points of the WorkSpace area (Exi) to the entry-point (Enj) of another WorkSpace area.
## No other movement outside WorkSpace area are allowed.
# To move a robot to a WorkSpace area From random location without using WorkSpace paths, one need to issuing separate axis movements: Move A1 10 Move A2 -40 ....
# Different robots can have different WorkSpace sets.
# It will be possible to know for each robot in which WorkSpace-index the robot is currently placed.

=Graphic Movement Examples=
To understand the movement between WorkSpaces follow the next scenario: [[File:WSPC 1.png|right|450px]]
* There are three workspace objects:
** wspc#1
** wspc#2
** wspc#3
* Only the following exit/entry paths between workspaces are allowed:
** wspc#1.Ex1→ wspc#2.En2
** wspc#2.Ex1→ wspc#3.En1
** wspc#3.Ex1→ wspc#1.En1
** wspc#3.Ex2→ wspc#2.En1

It's allowed for entry and exit paths to cross WorkSpaces and other WorkSpaces areas unlimited number of times: 
[[File:WSPC 2.png|450px]]

In case two WorkSpaces areas have common intersection, robot will be able to move from one to another without limitations: 
[[File:WSPC 3.png|250px]]

=Initialization=
Initialization of one WorkSpace set will be done by reading an '''XML''' file with coordinates and entry/exit points linked to a specific robot. 
To upload Workspace setting user have to use WSPC function - '''WSPC_PARSE_XML(Robot ID number as long, XML Name as string)''' 
The XML structure should contain the following: 
* Workspace id number.
* WorkSpace vertices: O,W,H,L (all with X,Y,Z coordinates in mm)
* Accuracy radius: R (in mm)
* Exit Points to other Workspaces: Ex1#w1, … Exk#wk
* Entry Points from other WorkSpaces: En1#w1, … Enk#wk
 
In this format: 
<syntaxhighlight lang='XML'>
<workspace_set>
<workspace number="1" name = "ToolCenter_pos">
<origin x="450" y="-50" z="-50" yaw="0" pitch="0" roll="0"/>
<dimensions x="100" y="100" z="100"/>
<entry_points>
<point ws_num="3" x="0" y="0" z="50"/>
</entry_points>
<exit_points>
<point ws_num="2" x="0" y="100" z="50"/>
</exit_points>
<tolerance radius="5" />
</workspace>
</workspace_set>
</syntaxhighlight>

=WorkSpace Example=
{|class="wikitable" style="text-align: center"
|'''Description'''
|'''Download'''
|-
|It's recommended to download the example '''ZIP''' file, extract all the project files, open project with ControlStudio, and run the example by yourself.
|[[image:Download.png|90px|link=http://softmc.servotronix.com/img_auth.php/1/16/scara.zip]]
|}

To run WorkSpace example:

# Upload all project files to MC
# Via CS terminal send the following – “SEND SCARAEX.XML” – NEED TO GET “done” MESSAGE
# Via CS terminal: “reset all” -> “load startprg.prg” -> “load WSPCONE.PRG” -> “STAS WSPCONE.PRG”
# Information message should appear in the Message Log panal.

{{Note|
The information you should get from WSPCONE.PRG task refer to:
* loactions definition
* Movements status
* WSPC status
}}

File:scara.zip

2018-05-09T08:30:36Z

Itay: -> Creation failed: Unsupported filetype!

Program Examples: WorkSpace areas

2018-05-09T08:25:39Z

Itay: /* Initialization */

Program Examples: WorkSpace areas

2018-05-09T08:25:24Z

Itay: /* Initialization */

Program Examples: WorkSpace areas

2018-05-03T10:07:27Z

Itay: