Firmware wishlist and priorities for Duet WiFi and Duet Ethernet
-
Hmm, curious. Does it have stops at each end of the axis? Presumably for that to work, the machine would need to have a fair amount of "slop" in the linear guides so that it can twist? Or is some other mechanism employed?
I have 8 endstops, min and max for each rail. Being a meter in length, and a mixture of stainless steel and 3d printed parts, and gt2 belts, you can get up to 2cm off square if you move just one of the motors whilst keeping the other stationary. Doesnt seem to be a problem in use though, as both motors move together to keep it square. I have successfully milled aluminium on it, though usually I just mill wood or polcarbonate.
That's fair enough - I have twin linear rails on my CoreXY which are only held by a single bolt at each end so if the belt tension isn't exactly the same both sides, it'll twist the axis. In fact, that's how I set the belt tension - push the X is to it's extreme Y position, then adjust the belt tension on one side or the other until it's square with the frame. Obviously once set, the belt tension will keep it square regardless.
Actually, on your printer, the fact that both motors move together will keep the axes parallel but not necessarily square. So for auto squaring to work, there would need to be some inherent "flex" in the system. I guess you could use M556 axis compensation but it's a manual process to set it.
-
Auto squaring/calibrating by homing dual x and dual y steppers individually.
I also have an mpcnc machine that at some point I am going to swap over to a duet ethernet so I can also use it for 1 meter x 1meter x 15cm prints. It has dual x, and dual y steppers. One feature that the branch of marlin has that would be great on the duet would be to automatically be able to square off the x and y axis by moving all 4 motors independently to their own endstops
This is possible with the Duet/RRF already. Use M584 to create two additional invisible axes (U and V assuming that you only have XYZ) like this:
M584 X0:3 Y1:4 Z3 U10 V11 E5:6:7:8:9 P3
Then when homing X, separate the 2 X motors into X and U and home them together:
M584 X0 U3
G91
G1 S1 X-300 U-300 F3000
…and then join them again:
M584 X0:3 U10
Similarly for homing Y.
-
Wow - light bulb moment. I've just realised that I can use this for homing my extruder CoreXY that sits above the hot end CoreXY. Currently I have to remember to check that they are lined up by eye before homing, as only the hot end CoreXY has end stop switches attached. This works because the extruder CoreXY has longer axes than the hot end so they don't have to be too precisely aligned but sometimes when I've been working on the printer, I forget and if the extruders are too far to the left or front, nasty things happen.
Quick question though. Presumably one has to define the other (additional) end stop switches using M574 U and V. But these switches would need to be connected to spare E stops (as there are no U and V estops labelled as such on the board). Can you point me to where I assign an En stop to an axis?
-
E0 endstop is for U and E1 endstop is for V.
-
E0 endstop is for U and E1 endstop is for V.
Brill!. I'm currently using E0 and E1 for emergency stops on axis maxima and a separate emergency stop switch but I can re-position these to use two of the estops on the Duex 5.
-
Would implementing Z axis backlash/hysteresis compensation be any easier than X/Y axes?
I am using a belt driven Z with a worm drive reduction. And as such, upon reversing travel direction, I have ~0.07mm of dead space… That's not really a problem for regular usage (one direction movement), but I would like to use mesh bed compensation eventually, and that would pose a bit of a problem... -
On a Cartesian printer, it's equally difficult on all the axes. On a delta printer, it may be harder. It partly depends on the amount of compensation needed. Less than 1 full motor step may be easy because we can probably get away with sending the extra steps all at once; but 2 or more full steps is likely to be hard because we will need to send them slowly enough for the motor to move with them, otherwise it is likely to skip steps.
What fraction of a full step (or how many full steps) does your 0.07mm correspond to?
-
I'm using CoreXY actually. With current reduction 0.07mm corresponds to 28 full steps, but it will be 7 when correct pulleys arrive…
That would really need to use jerk/accel values to not skip steps I suppose.
The way I understand it, we would need a way to determine if axis is changing direction, and then add an appropriate amount to Z move command? Or am I missing something important here? Either way, I'm not asking/hoping this will be implemented soon (or at all), just wondering, that's all.
-
The problem is that when reversing direction, the extra steps ideally need to occur and be acted on instantaneously. If you just increase the distance moved, that will correct for under-scaling caused by backlash, but not for the other print quality problems it causes.
In belt-driven X and Y axez, I think the amount of correction needed will generally be much less than a full step; which means that the extra steps can be sent rapidly at the start of the move.
-
Two suggestions, one to improve Z probing accuracy, the other to improve mesh bed leveling (background is here: https://www.duet3d.com/forum/thread.php?pid=32725).
-
A new option for G30 single-point probe commands to probe multiple points and average them to generate the final height for (X,Y). Ideally you'd add NUMBER_OF_POINTS and RADIUS to the probe command, and G30 would then probe that number of points around the given (X,Y), as well as (X,Y) itself. (Since I'm wishing, let's consider an additional option to apply a median filter to this before averaging and/or throw out the lowest and highest measurements.) I think this would increase the accuracy and repeatability of Z probes regardless of what kind of probe you're using.
-
The ability to apply a median filter to heightmap.csv to eliminate outliers (incorrect probe heights). This could prevent one or more bad points from distorting the bed map.
-
-
MQTT is really something that would open the door to many interesting applications. In principle, the integration of MQTT should be fairly easy since many MQTT implementations for ESP8266 are publicly available.
12
14
15
7
10I have one of my Duets wired up to a CNC machine at the moment, though it requires a lot of messing about to from Fusion 360 to actually milling something with the Duet. I can help test stuff out though.
My other suggestion would be support for MQTT, to allow the duet to signal other things with it's status, e.g. current temperature, finished printing etc. With this it would be possible to do stuff like turn off plugs, turn on lights or send text messages when a print had finished.
-
Use StallGuard to tune motors for maximum speed and acceleration.
-
18, 20, 6, 2, 3
Thanks -
Use StallGuard to tune motors for maximum speed and acceleration.
StallGuard won't tell you the maximum speed you can achieve, but you can work it out using the spreadsheet linked to from https://duet3d.com/wiki/Choosing_stepper_motors#How_to_work_out_the_power_supply_voltage_you_need.
I am not sure that StallGuard can tell you the maximum accelerations available either, because what it actually detects is increasing slip angle between the ideal motor position and actual motor position. This slip angle increases with motor load. So it can warn you when the load increases to a value that is close to the maximum value before stalling, but only if you calibrate that value first.
If enough users participated, I guess we could build up a database of recommended stallgard settings for various stepper motor models.
-
Can I add a vote for 19 (Cool down power off wait) with the acknowledgement that a maintained supply to VFAN would achieve the same thing. (On that topic, any chance of proper supply terminals for the fan bus on the next generation of boards? Connecting via VFAN feels a bit hacky)
I’d also like to put in a word for auto-updates.
Whilst I accept the dangers of auto-updating (I’m currently resisting a similar request on my own software) can I suggest that you consider providing an update wizard that backs up the current configuration then walks the user through any configuration changes before installing the update.
If you need additional incentive, just think of all the support requests you’ll save if you get it right.A clear indication on the client that updates (including paneldue and the probe) are available would be useful too - I recently updated my main board to the latest 1.20 release but totally failed to spot a matching update for my panelDue.
-
Cool down power off wait is already implemented, see https://duet3d.com/wiki/G-code#M81:_ATX_Power_Off.
-
Use StallGuard to tune motors for maximum speed and acceleration.
StallGuard won't tell you the maximum speed you can achieve, but you can work it out using the spreadsheet linked to from https://duet3d.com/wiki/Choosing_stepper_motors#How_to_work_out_the_power_supply_voltage_you_need.
I am not sure that StallGuard can tell you the maximum accelerations available either, because what it actually detects is increasing slip angle between the ideal motor position and actual motor position. This slip angle increases with motor load. So it can warn you when the load increases to a value that is close to the maximum value before stalling, but only if you calibrate that value first.
If enough users participated, I guess we could build up a database of recommended stallgard settings for various stepper motor models.
I was thinking of a serpentine pattern that gradually increased speed and or acceleration until Stallguard indicated that the motor was slipping and then back off a little. In the past when I needed to tune steppers for dot matrix printers is was very much cut and try. I envision a process somewhat akin to tuning a PID loop where the intent is to converge as fast as possible without overshoot.
Admittedly, everything is easy if you don't have to do it yourself.
-
5
6
18
17 -
The problem is, Stallguard doesn't really tell you that the motor is slipping. What it tells you is that the load is higher than the threshold you have configured.
-
Oh. Clearly, I need to read the data sheet.
Maybe an accelerometer is what I should be thinking about.
Prusa claims some high print and move speeds. I had assumed they used StallGuard for their tuning but maybe they just raised the threshold until it stopped working, perhaps with an accelerometer to tell them it was skipping, and then backed it off. Or maybe it's just not a useful number that they claim.
