Firmware wishlist and priorities for Duet WiFi and Duet Ethernet
-
I have been trying to implement a fail safe switch which will stop Z homing and move the bed down 5mm.
I am using your mini probe but want to test a piezo version I have constructed but I am worried that if it fails, nothing will stop the bed moving and damaging the hotend or bed surface.
I originally tried "M581 Z S1 T2 C0 ; Set Z stop as fail safe for Z zeroing and run /sys/trigger2.g"
and a /sys/trigger2.g file with the following entries G91, G1 Z5 F200This works when moving the bed manually but has no effect when homing Z.
Deckingman suggested using the spare E0 connection "M581 E0 S1 T2 C0" this did not solve the issue and performed the same as the Z connection.
Does the firmware lock the system until homing has completed?
If so would it be possible to change that so the process can be interrupted in the way shown above or is their another way to protect the hotend and bed from probe failure? -
Hi,
my vote is : 1, 6, 7, 8, 14
-
3
17
16
14
7 -
Hello, Love what you've done already! Just amazing.
Cast vote as : 1, 3, 6, 8, 16.
Best Regards. -
Vote of a 'simple' user
14,
13,
16,
17 -
7
10
11
14
6
16
12 -
1,4,6,8,18
4..being able to utilize 5v switches on Duex for XYZ -
5
4
7
17
19 -
Just 11 for me, I definitely want to use the duet board for my laser cutter.
Now that I am used to 18 inst as big of a deal but would be nice I suppose.
-
My order of preference
18, 3, 17, 1, 20, 6, 8, 14
I know I'm going against the grain but I think 2 is possibly asking too much for the duet, I just don't see most needing that level of security on their local network and if they do there is always the option of putting it behind a firewall. I'd rather have that processing power put into extra features myself
-
14,17,18
-
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.
