Smooth interpolated motion for delta with extra axes.
-
I'm using extra axes (UV) with a delta printer. when I attempt a G1 move (ex. G1 X10 Y15 Z-10 U30 V-50) everything moves, but it isn't smoothly interpolated during the move. The X,Y,Z axes all move together as expected, but the U and V axes do not move in sync with the delta axes. The behavior is also seemingly arbitrary. For example:
In relative motion G1 X10 Y-15 Z-50 U50 V30 behaves like this:
X,Y,Z,V all work as intended. They move smoothly and accelerate/decelerate along their paths. U moves very fast at the start of the move for a brief moment, then slows down and moves in sync with V. All axes arrive at the end of their move together.G1 X-10 Y15 Z50 U-50 V-30 (opposite) behaves like this:
X,Y,Z all behave properly. U and V continuously accelerate and abruptly stop upon reaching their end positions, well before X,Y,Z arrive at their end positions.My assumption is that whatever piece of code that handles the smooth movement isn't equipped to handle delta moves in conjunction with other moves. When I remove the X,Y,Z movement from the G1 it behaves properly; U and V axes move smoothly together.
Can I request that this type of motion be supported in the firmware?
-
Which firmware version are you using? Please check with 2.02beta1 if you haven't already.
-
I am using 2.02beta1(RTOS) with RRF 1.22.2.
-
Part 1:
Let's be clear how Gcode makes coordinated multi-axis moves, as per the NIST standard: (note it defines only XYZABC where XYZ are linear and A et al. are circular)
G1 X10 Y15 Z-10
Assuming a start of 0,0,0 will result in a STRAIGHT LINE movement by the "control point" (the tip of the nozzle) from X0 Y0 Z0 to X10 Y15 Z-10 , that line being "straight" in three dimensional space. This means that X, Y and Z will all move at different RATES as acceleration, movement, and deceleration occur. In the exact wording of the NIST standard: (bolding mine)
To drive a tool along a specified path, a machining center must often coordinate the motion of several axes. We use the term “coordinated linear motion” to describe the situation in which, nominally, each axis moves at constant speed and all axes move from their starting positions to their end positions at the same time. ...[snip]... control the axes so that, at all times, each axis has completed the same fraction of its required motion as the other axes. This moves the tool along same path, and we also call this kind of motion coordinated linear motion.
Note that, if any of the axis involved in the move reach that individual axis' individual 'top speed', it would then be necessary for the other axis to move slower. Think about 'diagonal' moves. This is extremely common in real world moves.
Further complicating things is Delta kinematics. All the statements above, particularly the bolded one, apply to the "controlled point", the tip of the nozzle, in Cartesian space. The actual movements of the (so called) X Y and Z "towers" are quite different, they are moved as required to accomplish the coordinated linear motion of the tip of the nozzle... and the transformation between the two is highly non-linear, especially as the control point moves away from 0,0.
-
Part 2:
Now, extend the concept of "coordinated linear motion" to extra axis. In NIST G-Code standard, all axis are orthogonal to each other. Extending this concept, an X Y Z U V axis has five axis, all orthogonal to each other (can't physically exist in the universe we inhabit; very easy to calculate in math).
Therefore, "coordinated linear motion" must apply the at all times, each axis has completed the same fraction of its required motion statement to move the controlled point along a straight line in 5 dimensional space.
Stop and think about that for awhile.
-
Part 3:
Last, add back in the cartesian to delta-tower transform for XYZ, but NOT for U or V. Given all of that, I would expect the motors to behave VERY differently in terms of speed acceleration, etc, etc. when behaving correctly. Where correctly = moving the control point along a straight line in five dimensional space.
.
.Interesting to see that G1 X10 Y-15 Z-50 U50 V30 causes various speeds, but then "...All axes arrive at the end of their move together...". That implies they COULD be moving correctly.
However, your statement G1 X-10 Y15 Z50 U-50 V-30 ends with "...abruptly stop upon reaching their end positions, well before X,Y,Z arrive at their end positions." This cannot be compatible with at all times, each axis has completed the same fraction of its required motion
So... no conclusions from me... just trying to help everyone think this through on the same conceptual framework.
-
And, last, a question: What do U and V drive in the physical world? What is the "design goal"?
Very curious, as I am a Delta/Kossel fanatic...
-
@gizmotronx5000, one more test please:
- Do some XYZ movements, then run M122 and check that the Step Error count is zero.
- Do some XYZUV movements, particularly ones where the additional axes stop abruptly at the wrong place. Then run M122 and check the step error count again.
Also please post tyour config.g file.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
Thanks for the insight Denal. You are correct that I am trying to achieve coordinated linear motion. I hadn't actually read the standard before now, so it is good to see how it is actually worded. It is very strange that things seem to more or less work in one direction of movement but not in another.
I'm essentially messing around with the concept of moving build plates in and out of the print area.
Running XYZ (G1 X10 Y15 Z-30) generates the following M122 output:
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02beta1(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6J9F2-3S46R-K2XBW
Used output buffers: 3 of 20 (14 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 97972 of which 0 recycled
Exception stack ram used: 356
Never used ram: 4268
Tasks: NETWORK(ready,400) HEAT(blocked,1248) MAIN(running,3484)
Owned mutexes:
=== Platform ===
Last reset 00:22:21 ago, cause: power up
Last software reset at 2018-08-28 10:52, reason: User, spinning module GCodes, available RAM 4252 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 33.3, current 33.5, max 33.7
Supply voltage: min 12.2, current 12.3, max 12.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/464
Driver 1: standstill, SG min/max 0/471
Driver 2: standstill, SG min/max 0/473
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max 0/0
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max 0/513
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max 0/0
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-08-29 14:05:39
Slowest loop: 3.16ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 236, MaxWait: 62425ms, Underruns: 0, 0
Scheduled moves: 48, completed moves: 48
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 4.65ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
=== Expansion ===
DueX I2C errors 0G1 X10 Y15 Z-30 U-45 V20 (Same move but now with UV motion, homed in between.)
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02beta1(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6J9F2-3S46R-K2XBW
Used output buffers: 3 of 20 (14 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 97972 of which 0 recycled
Exception stack ram used: 356
Never used ram: 4268
Tasks: NETWORK(ready,400) HEAT(blocked,1248) MAIN(running,3484)
Owned mutexes:
=== Platform ===
Last reset 00:24:07 ago, cause: power up
Last software reset at 2018-08-28 10:52, reason: User, spinning module GCodes, available RAM 4252 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 33.4, current 33.8, max 33.9
Supply voltage: min 12.2, current 12.3, max 12.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 3/465
Driver 1: standstill, SG min/max 0/487
Driver 2: standstill, SG min/max 0/466
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max 0/0
Driver 5: standstill, SG min/max 0/553
Driver 6: standstill, SG min/max 0/495
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max 0/0
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: yes
Date/time: 2018-08-29 14:07:26
Slowest loop: 2.60ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 235, MaxWait: 39029ms, Underruns: 0, 0
Scheduled moves: 68, completed moves: 68
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 9.46ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
=== Expansion ===
DueX I2C errors 0 -
My current Config file is below. I have motors XYZUVWA right now, where WA are serving the same purposes as UV, but in a different way. Complicating things more is the fact that W is using an external driver, but that's not important right now to this problem. I'm not using WA until UV work out.
; Configuration file for Duet Ethernet (firmware version 1.20 or newer)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool on Mon Feb 26 2018 12:03:14 GMT-0600 (Central Standard Time); General preferences
M669 K3 ; Kinematics type 3=linearDelta,
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves
M555 P1 ; Set firmware compatibility to look like RepRapFirmareM665 R115 L291.2 B85 H170.8 ; Set delta radius, diagonal rod length, printable radius and homed height backup
; Network
M550 PTest Duet ; Set machine name
M540 Pbe:63:40:4c:53:52 ; Set MAC address
M552 P0.0.0.0 S1 ; Enable network and acquire dynamic address via DHCP
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet; Drives
M569 P0 S0 ; Drive 0 goes backwards X
M569 P1 S1 ; Drive 1 goes forwards Y
M569 P2 S0 ; Drive 2 goes backwards Z
M569 P3 S0 ; Drive 3 goes backwards U
M569 P4 S1 ; Drive 4 goes forwards V
M569 P5 S0 ; Drive 5 goes backwards Nothing
M569 P6 S0 ; Drive 6 goes forwards A
M569 P7 S1 ; Drive 7 goes forwards
M569 P8 S1 ; Drive 8 goes forwards
M269 P10 S1 ; Drive 10 goes forwards WM584 X0 Y1 Z2 E3 U5 V6 W10 A8 ; set up extra axes? U5 V6 A7
M350 X16 Y16 Z16 U16 V8 W1 A8 E16:16 I1 ; Configure microstepping with interpolation
M92 X80 Y80 Z80 U44.4444 V226.24 W2 A24.2963 E92.5 ;E663 ; Set steps per mm (or degree)
M566 X1200 Y1200 Z1200 U1200 V1200 W1200 A1200 E1200 ; Set maximum instantaneous speed changes (mm/min)
M203 X18000 Y18000 Z18000 U4000 V5000 W4000 A5000 E1000 ; Set maximum speeds (mm/min)
M201 X1000 Y1000 Z1000 U1000 V400 W1000 A1000 E500 ; Set accelerations (mm/s^2)
M906 X1000 Y1000 Z1000 U1200 V1000 W75 A700 E1000 I65 ; Set motor currents (mA) and motor idle factor in per cent
M564 S0 H0; Allow moves S0 outside of build area, H0 while not homed.
;M84 S30 ; Set idle timeout; Servos
M307 H3 A-1 C-1 D-1 ; Disable heater 3-7. Set parameters to -1. Servos 3-7 are controlled with heaters 3-7 (There are no servos 1-2). Not currently used
M307 H4 A-1 C-1 D-1
M307 H5 A-1 C-1 D-1
M307 H6 A-1 C-1 D-1
M307 H7 A-1 C-1 D-1; Axis Limits
M208 X-100 Y-100 Z0 U-100000 V-93.34 W-1000 A-58 S1 ; Set minimum
M208 X100 Y100 Z300 U100000 V93.34 W1000 A58 S0 ; Set maximum; Endstops
M574 X2 Y2 Z2 U0 V1 W0 A1 S1 ; Set active high endstops
M666 X0 Y0 Z0 U0 V0 W0 A0 ; Put your endstop adjustments here, or let auto calibration find them; Z-Probe
M558 P0 H5 F120 T6000 ; Disable Z probe but set dive height, probe speed and travel speed
M557 R85 S20 ; Define mesh grid; Heaters
M140 H0 S0 ; Disable heated bed with M140 H-1
M305 P0 T100000 B4725 C7.060000e-8 R4700; Set thermistor + ADC parameters for heater 0 Bed Heater
M305 P1 T100000 B4725 C7.060000e-8 R4700; Set thermistor + ADC parameters for heater 1 Extruder
M143 H1 S280 ; Set temperature limit for heater 1 to 280C
M143 H0 S120 ; Set temperature limit for heater 0 to 120C; Fans
M106 P0 S1.0 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
M106 P1 S255 I0 F250 H-1 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned off
;M106 P2 S1 I0 F500 H T45 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on; Tools
M563 P0 S"Extruder" D0 H1 ; Define tool 0
G10 P0 X0 Y0 Z0 U0 V0 W0 A0 ; Set tool 0 axis offsets
G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C; Automatic saving after power loss is not enabled
; Custom settings are not configured
; Miscellaneous
T0 ; Select first tool
M302 P0 ; Allow cold extrudes for testing -
@dc42 said in Smooth interpolated motion for delta with extra axes.:
@gizmotronx5000, one more test please:
- Do some XYZ movements, then run M122 and check that the Step Error count is zero.
- Do some XYZUV movements, particularly ones where the additional axes stop abruptly at the wrong place. Then run M122 and check the step error count again.
Also please post tyour config.g file.
I should also clarify that the axes do all make it to their final destinations, but they are not coordinated along the path. In combination XYZ+UV movements the U axis is behaving consistently and predictably wrong. Further testing has shown this behavior:
During positive U movements the U axis jumps forward along its path, then finishes the last 2/3 (approx) of the move coordinated with XYZ. During negative U movements the U axis accelerates the entire time, arriving at its assigned final location well before XYZ.
Strangely, V does not behave the same way. I haven't been able to figure out an exact pattern for V yet.
-
I think I found the problem. Please try the firmware binary at https://www.dropbox.com/s/fyvibzm0zl92hiy/Duet2CombinedFirmware.bin?dl=0 - very carefully!
-
That fixed it as far as I can tell! I'll continue doing testing and let you know. What was the bug? This is the best support I've gotten for a product in my life.
-
The bug was that in most places the firmware assumed that only the first 3 axes were delta printer towers, but in one place it assumed that all visible axes were towers.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 Thanks for the fix. Is it safe to assume this fix will make it into future released versions as well?
-
Yes, it will be in the next 2.02beta release.
