Firmware wishlist and priorities for Duet WiFi and Duet Ethernet

jacksat

3
17
16
14
7

Ntesla66

Hello, Love what you've done already! Just amazing.
Cast vote as : 1, 3, 6, 8, 16.
Best Regards.

Merlin

Vote of a 'simple' user
14,
13,
16,
17

jmjcoke2

7
10
11
14
6
16
12

Loffy770

1,4,6,8,18
4..being able to utilize 5v switches on Duex for XYZ

Reanimator2k

5
4
7
17
19

Miasmictruth

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.

Crash69

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

Alexander Mundy

14,17,18

T-Printer

My vote:
7
8
16
17
18

JohnOCFII

My ordered priorities:

1, 7, 6, 3, 20

Thanks,

John

Fickert

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.

Adamfilip

18
7
10
1
12

Thanks for your hard work and dedication!

Adam

yngndrw

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#post1057850

Now 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/131515172625

With the encoder, calibration could be fully automatic.

T3P3Tony

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.

yngndrw

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.

T3P3Tony

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.

yngndrw

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.

InSanity

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.

yngndrw

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.