Duet WiFi firmware new feature priorities
-
Just thought of a "anything else".
Some sort of running total of print time to date. A sort of "hour meter", or "mileometer". It would be useful for setting up maintenance schedules\reminders. Like "lubricate guides" every x number of hours or "change belts" every y hundred hours". I guess this is more a web interface thing, as it would need to be running total of when the printer is actually printing rather than power on time. Just a thought…....
-
Oh yes, the hourmeter would be a very very nice feature. It could be nice to know individual axes' travel distances, as well as print hours, total powered up hours (for motors) etc.
-
Very nice list, choices, choices…
My vote would be -
-
- F. Support for multiple independent X carriages.
-
- A. Higher stepper motor current (above 2A)
-
- P. Control over which access point
-
- N. Support for driving RC servos - But do the HW on the expansion header (shield) with a +5V reg + I/O etc.
-
- R. Support to compensate for axis hysteresis
In my first week of using DuetWifi I would have voted for E. Support for an external SD card socket, but now it's almost not even something I would think about, and it's annoying that other 3D printers are still using a slow external card…
Best Regards,
Rich.
-
-
I think this is my preference of order.
C. Predictive temperature control.
H. Grid-based bed compensation,
J. Dynamically-varying microstepping
O. Support for restore points.
G. Support for three independently-controlled Z motorsI read DC42 start post that way, the other topics will
not be dropped, just come later.One suggestion from my side ( I believe the topic
was already discussed in some thread(s) on the RepRap forum)What about having a dedicated button (pin) for pausing
the print (similar the pause Web Button) ?Sometimes I have see someting strange during the print
and would like to pause. The Webbutton is to slow to reach
and a power off (like an emergency stop button)
ruins the print. -
The PanelDue offers exactly this pause button. I personally would never run a duet printer without a paneldue. It's a much more reliable and fast means of controlling the printer than the web interface. Keep in mind, the pause command does wait for the last gcode command to finish executing (or maybe even the whole queue).
-
I just pre-ordered a board. One feature I want to request (if it doesn't exist already) is an extruder advance (aka JKN, Linear Advance, etc) to help compensate for hysteresis in bowden systems. My machine has some very long bowden tubes and enabling this (unfinished) feature in Marlin's RC Bug fix branch made a noticeable difference on corners and top infill quality.
-
I just pre-ordered a board. One feature I want to request (if it doesn't exist already) is an extruder advance (aka JKN, Linear Advance, etc) to help compensate for hysteresis in bowden systems. My machine has some very long bowden tubes and enabling this (unfinished) feature in Marlin's RC Bug fix branch made a noticeable difference on corners and top infill quality.
Good news for you. RepRapFirmware has supported extruder pressure advance for around 18 months. See
http://reprap.org/wiki/Gcodes#M572:_Set_or_report_extruder_pressure_advance -
I just pre-ordered a board. One feature I want to request (if it doesn't exist already) is an extruder advance (aka JKN, Linear Advance, etc) to help compensate for hysteresis in bowden systems. My machine has some very long bowden tubes and enabling this (unfinished) feature in Marlin's RC Bug fix branch made a noticeable difference on corners and top infill quality.
Good news for you. RepRapFirmware has supported extruder pressure advance for around 18 months. See
http://reprap.org/wiki/Gcodes#M572:_Set_or_report_extruder_pressure_advanceExcellent news! And it's per extruder, even better! Can't wait to get my hands on it!
-
My own list for a printer:
1/ H grid-compensation
2/ C temp control with auto-tune
3/ D Simple panel
There was on forum someone asking for an odometer (recording filament consumption) and printing hour counter. That shall not be high priority, but that may be a nice to have.
The Duet WiFi having higher current capability, it can be possible to handle a CNC, but there is need to implement a few more G-Code- M0/M1 stop/start for tool change
- M3/M5 start/stop spindle
- M8/M9 Coolant on/off
- M10/M11 : Vacuum (for part maintaining) - lower priority
- Sn : spindle speed
Heaters output can be used to command SSR or to make a PWM for spindle speed control.
A 'standard' mapping shall be decided, e.g. E0 heater -> spindle on/off E1 heater -> coolant on/off , Bed heater -> Vacuum pump, Fan0 for spindle speed control.
Shapeoko is listing the G-code it is using here http://www.shapeoko.com/wiki/index.php/G-Code
-
@PRZ:
There was on forum someone asking for an odometer (recording filament consumption) and printing hour counter. That shall not be high priority, but that may be a nice to have.
Hey that was me :), sort of forgotten about it but yes it would be good to have but low on the list
Second the CNC stuff….. that will be my next big project.
-
It's time to summarize which firmware features you want most. I allocated 5 points to your first choices, 4 points to your second choices usw. and added them up.
By far the most wanted feature is predictive temperature control with auto tuning (51 points). After that comes dynamic microstep generation (30), grid-based bed compensation (27), restore points (24), faster microstepping (23), and higher motor current (21) and babystepping (18).
I already implemented faster microstep generation and released it in firmware 1.14.
Dynamic microstepping and higher motor current are related, because they both involve the SPI interface ti the stepper drivers. So I plan to implement them together. This leads me to the following provisional plan:
#1 Predictive temperature control with auto calibration
#2 Higher motor current and dynamic microstepping
#3 Grid-based bed compensation
#4 Restore points
We also expect to have OEM customers for the Duet WiFi so I will be taking their views into account too.
-
Really have to ask, but what on earth is 'predictive temperature control' are you talking about Feed forward or heuristic control?… both I would consider to be a poor replacement for PID.
The problem with PID control is tuning and most people who talk about tuning of PID rarely explain that the tuning methodology changes with the form of the PID algorithms (and there are many forms)
How about replacing the existing PID algorithm with an auto tune algorithm?
-
It's feedforward control. Why would you consider it to be a poor replacement for PID? PID is OK at correcting for small changes in the status quo, but it's fairly useless at achieving the target temperature in the first place.
-
What exactly about it are you trying to improve? I don't think I've ever been unable to tune a PID adequately enough for it to have no ill-effect on prints.
One thing that would be nice for an alternate to PID, is for it to be able to set temperatures for times in the future. For example, have an idle heater heated up at the precise moment it is needed, rather than having to wait. It would account for the heatup (and cooldown) times and time the signals appropriately to have the heater ready or not when it is needed or not. This would be useful in the case of a stationary idle extruder.
-
b c j o h in no particular order
-
Feed-forward temp control (or more accurately "model-based" control) doesn't really get the average user anything (except maybe 10-20 second faster stabilized preheat time) but it is very valuable for two extreme usage cases:
1) Very high-speed printing. Large changes in filament melt power (and I do mean LARGE, like with a Volcano changing from slow perimeters to fast infill)) cause massive temp fluctuation that can trigger firmware heater safety cutoffs and affect print quality.
2) Very light-weight hot ends. When the temp sensing time lag and/or heater power are large relative to the heat capacity of the hot end, feedback control algorithms like PID can become mathematically incapable of outputting a stable temperature with acceptable settling time. Basically if your process gain or sensor time constant is too large, PID is a bad control scheme.The PID autotune technique used by all the other 3d printer firmwares (specifically, the relay method with old-school Ziegler Nichols parameters in Marlin, Repetier, Smoothie, etc) really is NOT very effective. It outputs mediocre tuning values. The fact that hot ends heat up much faster than they cool down violates the mathematical assumptions going into the relay autotuning method. You can improve the auto-tune algorithm with some tweaks, which Redeem has recently implemented, but at a certain point you have to ask why you're using increasingly complex implementations of PID – a super-generic control scheme that is ideal for un-modeled processes with unknown disturbance inputs -- rather than making a bespoke control algorithm that takes advantage of the well-known physics we're dealing with here.
3D printer hot end control is a VERY good candidate for a feed-forward model. Almost all heat flux can be accounted for with three terms: heater power, heat losses due to temp difference between the hot end and ambient, and heat leaving the hot end in the melted filament. All of these can be auto-calibrated without too much difficulty. Then you add in a minimal PID-style "I" feedback loop to correct any residual model error, and bob's your uncle -- super stable temp control for a wider range of hardware and print conditions.
-
Sorry DC42, but I've got to strongly disagree with you on this one, but I'm talking from a point of 30 years experience using and developing PID control algorithms reasonably tuned PID is always spot on when achieving the target temperature, and the current Duet PID algorithm is not great, but I've never had a problem getting a reasonable tune, however, I can understand how anyone unfamiliar with PID can get themselves into trouble or think that its some kind of black magic….
ZN tuning basically sucks for temperature control tuning especially when you have an ambient cooling system (as per 3D printers), the only reason ZN tuning gets used by 3D printers is because its a widely documented as an 'easy' method yet rarely do the web sites that tout it explain in what applications ZN tuning works, and yes the Astrom-Hagglund method (ZN Plus relay) is generally the standard autotune algorithm, yes it doesn't give great results, but when your not experienced in PID tuning its a good starting point
The other issue with PID with heating systems is the D term.... its generally has little benefit in this type of system and only serves to confuse, a good PID algorithm makes it very easy to disable the D term.
Personally I think the best methodology would be FF+PI this are PID variants, and when I write a PID algorithm I always give them a FF term they are basically systems where you use a FF factor to get the temperature in the ball park then P and I terms to tweak output to get the required final temperature, generally speaking they give very fast initial responses,
Maybe I should take the time to develope a better temperature control algorithm myself..... only issue is after a year of half hearted attempts I've still not manged to get get Eclipse up and running so I can play with the firmware.... and I blame you DC entirely for this, if you were not doing such a damned great job with the firmware then I would have more encouragement to fix the problems (which mostly dont exist) myself!!!
-
As it happens, FF+PI is exactly what I am considering. It seems to me that the D term in a PID heating control system serves to account for a temperature rise generated by the heater that is still on its way to the thermistor. This term would be better replaced by a prediction of what that temperature rise will be, based on a process model and the recent history of heater power.
I have also been reading about the various tuning methods, and Cohen-Coon tuning looks worth trying. It might be faster than ZN+relay (not that this really matters), and it provides a process model. The model gives us directly the value of the M305 T parameter (used to preset the I term when switching from full on or off to PID), and allows us to calculate the B parameter (used to determine how close we get to the target temperature before switching to PID). It also provides the parameters needed to replace the D term by a FF term.
After that will come further FF terms to predict the effect of changes in the print cooling fan speed and the extrusion rate.
-
CC test is usually only in a single direction, Astrom-Hagglund is bidirectional, I would suggest with CC that you do both a heating and cooling step test and use the average result, both CC and Astrom-Hagglund will require that you give the PID function a manual mode of operation, and Id also recommend a bump-less transfer function.
-
I really don't even think you need the P term if you have a good heat flux model, FF+I should do it. Proportional feedback makes hot blocks with a lot of sensing lag or very small heat capacity more oscillatory. But it's literally one line of code to include, so there's probably no downside to leaving it in there. Easy enough to set the P gain to 0 if you don't like it.
