Difference between revisions of "SimpleMotion motion control strategies"

From Granite Devices Knowledge Wiki
Jump to: navigation, search
[checked revision][checked revision]
 
(3 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Strategy !! Implementation !! Features !! Cons !! Need real-time host !! Synchronized multi-axis motion
+
! Strategy !! Implementation !! Features !! Cons !! Need real-time host !! Synchronized multi-axis motion !! Example implementation & documentation
 
|-
 
|-
 
| Parameter communication ||  
 
| Parameter communication ||  
Line 13: Line 13:
 
||
 
||
 
*No multi-axis synchronization, all axes operate in point-to-point mode individually
 
*No multi-axis synchronization, all axes operate in point-to-point mode individually
|| No || No
+
|| No || No || [https://github.com/GraniteDevices/SimpleMotionV2Examples PointToPointExample]
 
|-
 
|-
| Buffered motion commands ||  
+
| Buffered motion stream ||  
List of positions are uploaded to drive command buffers and executed by drives based on clock
+
List of trajectory coordinate points are uploaded to drive command buffers and executed by drives based on clock
 
||
 
||
 
*Allow synchronizing multiple axes and running arbitrary motion paths
 
*Allow synchronizing multiple axes and running arbitrary motion paths
 
*Motion acceleration and velocity profiles are generated by user application
 
*Motion acceleration and velocity profiles are generated by user application
*Drives syncronize clocks so motion stays in sync infinitely
+
*Unlimited trajectory duration
 
*Typical setpoint update rates are 250 Hz to 1000 Hz for 1 to 4 axis systems
 
*Typical setpoint update rates are 250 Hz to 1000 Hz for 1 to 4 axis systems
*Use of {{param|CIS}} smoothens any motion above 250 Hz to silky smooth
 
 
||
 
||
*Delay caused by buffering (0.1-1.0 sec buffering is recommended to avoid buffer underruns and stopping of motion)
+
*Delay caused by buffering (0.2-1.0 sec buffering is recommended to avoid buffer underruns and breaks of motion)
 
*Update rate will reduce as more axes are added to the system (due to bus bandwidth limit)
 
*Update rate will reduce as more axes are added to the system (due to bus bandwidth limit)
 
*Some added complexity in programming
 
*Some added complexity in programming
|| No || Yes
+
|| No || Yes||
 +
* Example project:[https://github.com/GraniteDevices/SimpleMotionV2Examples BufferedMotionStreamExample]
 +
* [[Buffered motion stream in SimpleMotion V2]]
 
|-
 
|-
 
| Real-time motion commands ||  
 
| Real-time motion commands ||  
Line 34: Line 35:
 
*Allow synchronizing multiple axes and running arbitrary motion paths
 
*Allow synchronizing multiple axes and running arbitrary motion paths
 
*Motion acceleration and velocity profiles are generated by user application
 
*Motion acceleration and velocity profiles are generated by user application
*Use of {{param|CIS}} smoothens any motion above 250 Hz to silky smooth
+
*Use of {{param|CIS}} smooths any motion above 250 Hz to silky smooth
 
*There is virtually no delay between command and action
 
*There is virtually no delay between command and action
 
*Higher scalability, can use multiple SimpleMotion buses to support large number of axis
 
*Higher scalability, can use multiple SimpleMotion buses to support large number of axis
 
||
 
||
 
*Update rate will reduce as more axes are added to the system (due to bus bandwidth limit), however, see the scalability feature in Features column
 
*Update rate will reduce as more axes are added to the system (due to bus bandwidth limit), however, see the scalability feature in Features column
*For smooth unterrupted motion, need hard real-time host, such as RTLinux, [[PLC]] or microcontroller platform.  
+
*For smooth interrupted motion, need hard real-time host, such as RTLinux, [[PLC]] or micro controller platform.  
 
*[[SimpleMotion V2 USB adapter]] may add uncertainty to timing, so use of other adapter may be necessary (PCI, PCI-E, PLC port or other peripheral, such as microcontroller USART).
 
*[[SimpleMotion V2 USB adapter]] may add uncertainty to timing, so use of other adapter may be necessary (PCI, PCI-E, PLC port or other peripheral, such as microcontroller USART).
|| Yes || Yes
+
|| Yes || Yes || [https://github.com/GraniteDevices/SimpleMotionV2Examples/tree/develop RealtimeControlExample]
 
|}
 
|}
  

Latest revision as of 11:29, 4 October 2018

SimpleMotion V2 allows building single and multi-axis motion control applications in three different strategies. The table below summarizes the options.

Strategy Implementation Features Cons Need real-time host Synchronized multi-axis motion Example implementation & documentation
Parameter communication

Send setpoint commands to a target drive with simple "write parameter" commands

  • The easiest way to do point-to-point motion control
  • Motion acceleration and velocity trajectories are produced by drive and can be set before motion is started
  • Can modify any drive parameter on the fly
  • Can be used together with other setpoint sources
  • No multi-axis synchronization, all axes operate in point-to-point mode individually
No No PointToPointExample
Buffered motion stream

List of trajectory coordinate points are uploaded to drive command buffers and executed by drives based on clock

  • Allow synchronizing multiple axes and running arbitrary motion paths
  • Motion acceleration and velocity profiles are generated by user application
  • Unlimited trajectory duration
  • Typical setpoint update rates are 250 Hz to 1000 Hz for 1 to 4 axis systems
  • Delay caused by buffering (0.2-1.0 sec buffering is recommended to avoid buffer underruns and breaks of motion)
  • Update rate will reduce as more axes are added to the system (due to bus bandwidth limit)
  • Some added complexity in programming
No Yes
Real-time motion commands

Position commands are sent to drives just like in parameter communication strategy, except in high update rate and from real-time host

  • Allow synchronizing multiple axes and running arbitrary motion paths
  • Motion acceleration and velocity profiles are generated by user application
  • Use of Setpoint smoothingCIS smooths any motion above 250 Hz to silky smooth
  • There is virtually no delay between command and action
  • Higher scalability, can use multiple SimpleMotion buses to support large number of axis
  • Update rate will reduce as more axes are added to the system (due to bus bandwidth limit), however, see the scalability feature in Features column
  • For smooth interrupted motion, need hard real-time host, such as RTLinux, PLC or micro controller platform.
  • SimpleMotion V2 USB adapter may add uncertainty to timing, so use of other adapter may be necessary (PCI, PCI-E, PLC port or other peripheral, such as microcontroller USART).
Yes Yes RealtimeControlExample