@Phaedrux - We are only using x16 micro stepping. Thanks for the info regarding tool board step rate. That's helpful.

@Veti - Will check the M122 output next time I run it. Will be able to update some time this week. Thanks!

We need to connect 10 motors (6 drive axes and 4 extruders) for our multi-headed printer project. With a Duet 2+Duex5 we get stuttering when the four heads are printing, so are looking into the Duet 3. Currently we see two main options that would work and one that satisfies our connection needs but not sure works:

1. 6HC Mainboard + 2*(3HC Expansion Boards)
2. 6HC Mainboard + 4*(1LC Tool Board) + Tool Distribution Board
3. 2*(6HC Mainboard)

Other than cost and wiring simplicity, what are some of the benefits of one over the other? Would one setup be better at handling the processing needed to run all the motors at once? Is option 3 even viable?

OK, got it. We'll try to adjust our acceleration settings to see if the buffer is limiting us. Thank you @dc42.

@Phaedrux, the code is on SD card 0 on the Duet. Code: X_2000FR_pt1S.gcode

@dc42 Thank you!

1. Let me double check how it is formatted and if not at the largest cluster size, I'll re-try our tests.
2. Is there a way to confirm we might be hitting the 40 move buffered queue?
   The M122 was placed in the middle of the gcode test file, so is this telling us that?

=== MainDDARing ===
Scheduled moves: 188, completed moves: 148, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: 3

Thank you both for your help!

Hi Phaedrux,

Thanks for the quick response and help!

• We actually see more stuttering/longer travel times with small segments and FW3.1.1
• No mesh compensation

The tests we ran are just using the X motor.

Config.g
; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M575 P1 B57600 S0

; Bed Leveling Locations
M669 K0; ; Kinematics defined as Cartesian

; Network
M552 S1 ; enable network
M586 P0 S1 ; enable HTTP
M586 P1 S0 ; disable FTP
M586 P2 S0 ; disable Telnet

; Drives
M584 X0 Y1 Z2 E6 ; create the additional axis and assign stepper drivers to them

M569 P0 S0 ; Drive 0 goes forwards - X
M569 P1 S0 ; Drive 1 goes reverse- Y
M569 P2 S1 ; Drive 2 goes forwards - Z

M569 P6 S0 ; Drive 6 goes forwards - X EXT

; Endstops
M574 Y0 P"nil" ; Y has no endstop, free up Y endstop input
M574 Z1 S1 P"zstop" ; Z min, active high endstop switch
M574 X2 S1 P"e0stop" ; X max, active high endstop switch

; Motor Settings
M92 Y117.777777 Z800.00 X80.00 E492.45 ; set steps per mm
M350 Y16 Z16 X16 E16 I1 ; Configure microstepping with interpolation
M566 Y400.00 Z12.00 X125.00 E120.00 ; Set maximum instantaneous speed changes (mm/min)
M203 Y16000.00 Z450.00 X3000.00 E15000.00 ; set maximum speeds (mm/min)
M201 Y1200.00 Z20.00 X500.00 E500.00 ; set accelerations (mm/s^2)
M906 Y1440.00 Z2400.00 X1840.00 E1000.00 I30 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout

; Axis Limits
M208 Y-1000000000 Z-30 X0 S1 ; Set axis minima
M208 Y1000000000 Z600 X300 S0 ; Set axis maxima

; Heaters
M308 S0 P"bed_temp" Y"thermistor" A"Bed" T100000 B3950 ; define bed temperature sensor
M950 H0 C"bed_heat" T0 ; heater 0 uses the bed_heat pin, sensor 0
M140 H0
M143 H0 S80 A2 ; switch off heater 0 temporarily if it exceeds 80°C

M308 S3 P"duex.e3temp" Y"thermistor" A"X" T100000 B4725 ; define X sensor to sensor 3, thermister pin 3
M950 H3 C"duex.e3heat" T3 ; heater 3 uses the bed_heat pin, sensor 3
M143 H3 S285 A0 ; raise a heater fault if it exceeds 285°C

; Fans

M950 F3 C"duex.fan3" Q100 ; Fan 3 is connected to fan pin 3, PWM at 100Hz

M106 P3 S1 H3 T45 ; Set fan 3 (X) to 100% when it reaches 45°C, thermister sensor 3

M950 H1 C"nil" ; Unassociate heater 1 (pin e0)
M950 H2 C"nil" ; Unassociate heater 1 (pin e1)

M950 F1 C"e1heat" Q100 ; Fan 1 is connected to heater 2 pin, PWM at 100Hz
M106 P1 S1 ; Set fan 1 (Duet Driver Fan) to 100%
M950 F2 C"e0heat" Q100 ; Fan 2 is connected to heater 2 pin, PWM at 100Hz
M106 P2 S1 ; Set fan 2 (Duex Driver Fan) to 100%

; Tools

M563 P0 S"X Axis" D0 H3 ; Define tool 0
G10 P0 X0 Z0 ; Set tool 0 axis offsets
G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

M501

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-917NK-F23T0-6JTDL-3S46S-KDA4F
Used output buffers: 6 of 24 (22 max)
=== RTOS ===
Static ram: 27980
Dynamic ram: 94424 of which 24 recycled
Exception stack ram used: 504
Never used ram: 8140
Tasks: NETWORK(ready,424) HEAT(blocked,1224) DUEX(suspended,160) MAIN(running,1824) IDLE(ready,80)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:05:00 ago, cause: power up
Last software reset at 2020-06-01 13:33, reason: User, spinning module GCodes, available RAM 5860 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 8
MCU temperature: min 34.5, current 34.9, max 35.4
Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, SG min/max 0/34
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-06-01 13:39:35
Cache data hit count 520404793
Slowest loop: 42.60ms; fastest: 0.12ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.4ms, write time 2.3ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 165, MinFreeDm: 164, MaxWait: 59518ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 188, completed moves: 148, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: 3
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is ready with "M122" in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 201.89ms; fastest: 0.09ms
Responder states

Hello All,

We recently noticed some vertical banding in our prints and have been able to link a particular case with stuttering during small segments. When trying to isolate where this occurs by moving on a single axis, we noticed a link with feed rate. We have also tried with FW 3.1.1. and the results were worse (M112 showed never used RAM at 5668).

Does someone know how we might be able to fix this? Does this hint to buffering or processing?

Our Test

• Measure the time it takes to complete a 200mm move, at a constant feed rate while varying segment size
• e.g. g-code for testing a 0.1mm segment size at 3000mm/min looked like this:
  G1 X0.1 F3000,
  G1 X0.2 F3000
  ......
  G1 X200.0 F3000

Electronics

• Board: Duet WiFi 1.02 or later + DueX5 (duetwifi102)
• Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.0 (2020-01-03b3)
• Duet WiFi Server Version: 1.23
• G-code file located on the board board SD card
• Motor connected to Duet WiFi

Motor Settings
M92 X80.00; set steps per mm
M350 X16; Configure microstepping with interpolation
M566 X125.00; Set maximum instantaneous speed changes (mm/min)
M203 X3000.00; set maximum speeds (mm/min)*** (Experiment for Y)
M201 X500.00; set accelerations (mm/s^2)*** (250 for Y)
M906 X1840.00; Set motor currents (mA) and motor idle factor in per cent

Results

• at a feed rate of 3000mm/min, we noticed a an increase in travel time when segment size dropped below ~0.12mm
• at a feed rate of 2000mm/min, we noticed an increase in travel time when segment size dropped below ~0.05mm
• at a feed rate of 1000mm/min, we noticed an increase in travel time when segment size dropped below ~0.016mm
• as segment sizes decrease below each of the ones mentioned above, stuttering increases and total travel time increase

Conclusion

• there appears to be a minimum time per a segment and when you drop below it you see stuttering - from these tests ~0.001 - 0.002 sec/segment (segment size/feed rate)

@dc42 said in Polar Printing Kinematics with U-axis:

If you are saying that you want to print two different objects at the same time, then that will require very special preparation of the GCode. Your best option would be to generate GCode that has all the segmentation and Cartesian-to-Polar coordinate transformation already done, then you can configure the printer as a straight 4-axis Cartesian printer (XYZU).
If you don't want to do that but you do want to be able to switch between 2 tools, the simplest approach would be to have both tools run on the same linear rail and cover the same radius values. Then the coordinate transformation would be the same for both heads. You could use the existing Polar kinematics, and use the M584 command to switch the X axis to either the X or the U motor in the tool change files.
HTH David

David, that helps a ton. At this time, I think the best approach for us is to prepare our own GCode and treat it as a 4-axis Cartesian printer.

Thank you for your help!

@dc42 said in Polar Printing Kinematics with U-axis:

IDEX polar printer

Yes more of an IDEX polar printer, although we don't want the heads just to mirror, so we were thinking of giving specific Y feed rates to have better control when printing at two different radii.

Is there a way to use X and an additional axis as two radial arms where both run through the polar kinematics and feed rate adjustments?

@dc42 said in Polar Printing Kinematics with U-axis:

What will you be using the X axis for?

Hi dc42, thank you for the quick reply! We want to use U for a couple of reasons: 1) so we can control the feedrate based on Y only, 2) so we can use more than one linear axis in the future.

Hello all! We are playing around with polar printing using a Duet 2 Wifi. Does anyone know if polar kinematics work with a linear U-axis and rotational Y-axis (instead of the traditional linear X-axis and rotational Y)? If not, is there a way to tweak the config, homing or FW to use the U-axis with polar kinematics?

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later + DueX5
Firmware Version: 2.05+1 (2020-01-19b1)