Firmware wishlist and priorities for Duet WiFi and Duet Ethernet
-
My vote:
7
8
16
17
18 -
My ordered priorities:
1, 7, 6, 3, 20
Thanks,
John
-
My votes:
1 for the fact I would love more solid wifi connection anything can help.
6 Would be nice to see as I am curious if my cooling fan is overkill or not. Or the effects of truly printing fast or slow
7 I think this is huge. I feel a lot of us are undercompensating these amazing stepper drivers with their ability to actually use X256 microstepping… Would it switch down to interpolated steps or just standard steps?
11 and 12 These are fairly important to me as this is what I will be doing for my project
16 Temperature control is always the battle so I am definitely in to see if this can be implimented
18 Also very nice to see. -
18
7
10
1
12Thanks for your hard work and dedication!
Adam
-
I have another firmware feature to add to the list: Stepper motor linearity compensation.
There's no point in me explaining when Mariss Freimanis from GeckoDrive has explained it far better than I ever could:
https://en.industryarena.com/forum/showthread.php?t=129408&p=1057850&viewfull=1#post1057850Now each make / model of motor will probably use the same compensation factor, so users would need to work out the correct factor for each type of motor that they are using.
This can either be done with a laser / mirror as Mariss mentioned, or an inexpensive encoder could be used with a 3D printed adapter. I've used these encoders with a 3.3V in the past and they work fine, even though they are only rated down to 5V, there's also some higher line count encoders available:
http://www.ebay.co.uk/itm/131515172625With the encoder, calibration could be fully automatic.
-
Andrew, reading the Gecko drive post it looks like he is talking about compensating for this in the stepper driver chip using an FPGA to alter the Electrical waveform to compensate for the mechanical error in microstepping position. That means the compensation will be in fractions of microsteps. Within firmware we only have the ability to work in microsteps, and this sort of error is not cumulative so I think this is a stepper driver chip level functionality request.
-
Hi Tony,
While Mariss is indeed talking about performing the compensation as part of the driver, I believe the method could be applied at the level above.
The controller would need to keep track of the electrical phase angle that the driver chip is currently positioned at. This assumes that there's a way of the driver chip telling the controller that it has reached a full step position. (This is only needed at the start, as the controller can keep track of it afterwards - This could possibly be queried directly or possibly assumed when the driver chip is first enabled - I haven't checked the datasheet though) Essentially the electrical phase angle is the modulus of the current position (In steps) and the current microstepping level multiplied by 4. (As there's 4 quadrants)
We can then talk about two different step counts, let's call them virtual steps (Where we want the motor to go, representing physical positions on the model) and physical steps. (Corrected steps that we've commanded the driver chip to use, representing the electrical position of the motor)
If the step position that we currently output to the driver is the virtual steps, then all we should need to do is add the compensation value (Which is looked up from a pre-configured table based on the current electrical phase angle) to get to the physical steps, which can then be output.
I hope that makes sense, I can try to explain in a different way if needed - I'm also making an assumption that the controller can find out where the full step position of the driver is.
-
Hi Andrew it does make sense, but my understanding was the error was less than 1 microstep. That means that there is never anything that can be compensated for by a system that the smallest correction it can input is steps.
-
A fair point, I hadn't considered the resolution required - I've just graphed the compensation assuming 16x microstepping here:
In this graph, you see that each microstep represents a change of about 6% and the correction is about half of that at around 3% - Therefore 32x or 64x microstepping should be enough to make it work.
-
You'll not get 32x let alone 64x micro-stepping holding torque accuracy except for random rare cases of pure luck. You might get 16x if your lucky. Micro stepping works sure, but it doesn't replace good old mechanical resolution. I would say 1/8th stepping calculations might be a bit more realistic.
-
In terms of positional accuracy and for low speed movements, the amount of torque required in a 3D printer (Especially for the X and Y axes) is very low - I don't believe there should be any issue in holding a position to those sorts of accuracies. (Except maybe for deltas and Z axes ?) I don't have any evidence for this though, just based on speculation and theory.
With 16x or 8x, as Tony identified the correction distance is smaller than the resolution so it doesn't make sense at these microstepping levels.
-
What might work for a delta might not work so much for a cartesian. Before I upgraded the stepper on my Z axis I think I was getting about 1/4 step holding accuracy. So for me compensation wasn't working all that great. So much better now with higher torque motor.
-
Is this for a regular cartesian machine ? What stepper motors / current are you using and what pitch of leadscrew ? I don't have any numbers for this so it would be great to put some numbers behind it.
-
Voting for number 5
-
8, 7, 20, 16
-
Hi DC42,
Just wondering where you got to with G2/G3 arc support? Not sure if you spotted my rants on other threads about my testing results from 1.18beta1 and beta3? In a nutshell, according to my interpretation of the I and J parameters the motion you create for the arc is incorrect. I've played with all kinds of values for I and J and it always ends up with a vertical linear motion before the arc actually starts regardless of the value being entered (unless I and J are both zero in which case it is a straight line to the end coordinate). Also, if the arc motion takes the head outside the min/max bed size limitations it does not clip the arc, causing the motors to skip as the head slams into the mechanical limitations.
Really just after some confirmation that you still have plans to get it working correctly as I've committed quite a bit of time on my end writing code to convert regular 3D print G-code to use arcs instead of hundreds of short lines for curved surfaces. Not much point in taking that further if G2/G3 support is going to come to a dead end on the Duet.
Many thanks for putting the time you already have into supporting arcs.
-
7, 14, 18, 16, 11
-
7
11
12
18 -
i suggested this before, but when i "heater fault" occurs why not pause the print and allow the user to "resume" the print after the fault is rectified/cleared.
-
1
5
6
14
19
