Duet WiFi firmware new feature priorities
-
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.
-
The effectiveness of the D term here GREATLY depends on the selection of temp change filtering. For example, a while back, Smoothieware was updating the PID at 20 Hz, scaling the temp change back to degrees/second units for D (ie multiplying the last 0.05 seconds of temp change by 20), and had zero filtering/averaging within the PID loop… so EVERY time the temp changed, the D term would kick like a mule and saturate the entire PID output to 0% or 100%, then go back to doing nothing 0.05 seconds later. Without a low-pass or lag-cut filter or whatever, the D term was doing significantly more harm than good. (I think they fixed that, I haven't looked lately. I know they implemented better ADC filtering to reduce the noisy stepwise temp changes they were getting due to bad ADC hardware on the LPC17xx.)
In comparison, if you have an appropriate moving average or whatever filter, the D term really helps tamp down on hot end temp oscillation and overshoot. Having the D term update faster than the time constant of the temp sensor (which is maybe 2-3 seconds for a glass bead thermistor) is pretty stupid.
-
I just had a random curiosity question come to mind.
Is there any easy way to switch between types of thermocouple on the TC expansion board, or is the lookup table (and hopefully the cold junction compensation) hard coded into the interface chip on the expansion board?
If this is accessible to be patched or changed through the firmware updating process, it might be a useful option.The reason I ask is that some have easier access to different metalurgies, such as Type J, and in the case of Type J, it can be more accurate in the range we should see as well.
Again, this is just curiosity, and very late to the game to be bringing up feature requests.
-
I just had a random curiosity question come to mind.
Is there any easy way to switch between types of thermocouple on the TC expansion board, or is the lookup table (and hopefully the cold junction compensation) hard coded into the interface chip on the expansion board?
If this is accessible to be patched or changed through the firmware updating process, it might be a useful option.The reason I ask is that some have easier access to different metalurgies, such as Type J, and in the case of Type J, it can be more accurate in the range we should see as well.
Again, this is just curiosity, and very late to the game to be bringing up feature requests.
The conversion table is built into the MAX31855K chip on the TC expansion board. To use a type J thermocouple, you would need to use a MAX31855J instead of MAX31855K. I could build you a special if you want. If you want to assemble your own, we could probably let you have a bare PCB.
I guess it would be possible to do the conversion in firmware, but unless several users want it, it is unlikely that I will implement that. The nice thing about the MAX31855 is that by using the chip matched to the thermocouple, the chip does all the work and the firmware just reads the temperature from it. Type K thermocouples are widely available and inexpensive.
-
That makes sense. I didn't know how you were implementing the TC reading, or I wouldn't have bothered you.
If there is an un-populated board available, I would be interested in giving it a try. This does sound like a much simpler solution than how my work handles TCs, but I'm guessing that the Maxim chip may not have as much ability to be calibrated for precision and documentation of the same.
-
That makes sense. I didn't know how you were implementing the TC reading, or I wouldn't have bothered you.
If there is an un-populated board available, I would be interested in giving it a try. This does sound like a much simpler solution than how my work handles TCs, but I'm guessing that the Maxim chip may not have as much ability to be calibrated for precision and documentation of the same.
You can find the datasheet at https://datasheets.maximintegrated.com/en/ds/MAX31855.pdf. The accuracy figures are on pages 3 and 4.
-
I like to add other requests to the list:
-
Filament Odometer ( keeps traking of the amount of filament the printer use since: last print/last startup/commissioning)
-
Time Odometer ( keeps traking of the amount of time the printer use since: last print/ last startup/commissioning)
-
Support Volumetric Extrussion
-
Emergency Stop Button in PanelDue
-
Filament sensor: support to 3 types of sensors:
-
The implementation of a switch to see if I'm out of filament.
-
The implementation of a "mouse wheel " attached to the filament to check if the filament if moving and how much it's moving (If the wheel is not moving, there is no more filament or the hotend is jam )
-
A ccd sensor to check filament diameter to dinamicaly execute M200 gcode to change filament diameter to allow volumetric extrusion (http://www.thingiverse.com/thing:699308 and [[url=http://www.thingiverse.com]www.thingiverse.com] )
-
-
I've spoken to David previously about adding support for a simple switch based filament out sensor to the PanelDue so that you don't have to run as many wires (I'm on a delta and the PanelDue is right next to my spools).
If you have any interest in that please chime up.
-
Just an idea,
I was thinking of making an "Air Struder" for a large build kossel. But although it's a proven solution the weight of the extruders are still mostly on the carriages.
An alternative is balancing with springs but it is not my favorit solution either.
It might not be much weigh for 2-4 extruders but if you consider a reservoir for paste extrusion it can be 1 kilograms or 2.
Why not suspend the effectors/paste reservoir to an extra stepper motor with a pulley and have them raise as a function of the current printed layer. So the vertical distance between effector and the airstrudder would stay constant. Basically a height controlled hanging platform about 40 cm above the effector. -
I like to add other requests to the list:
…
- A ccd sensor to check filament diameter to dinamicaly execute M200 gcode to change filament diameter to allow volumetric extrusion (http://www.thingiverse.com/thing:699308 and [[url=http://www.thingiverse.com]www.thingiverse.com] )
This would be awesome!
-
For me, the biggest things would be:
- Digital Filament sensor support. (I have a tunell sensor on my Smoothie. It would be a killer to lose the ability to have large print pause resume capability. I'd go back to having tons of partial rolls of filament lying around!)
- Config override file
- Predictive Temperature Control
- Babystepping
- I don't have a number 5!
-
You can already use digital filament sensors. See http://reprap.org/wiki/G-code#M581:_Configure_external_trigger. I'll write a wiki page about using this facility with filament out sensors when I get time.
-
I described a simple switch based filament detection here :
http://reprap.org/wiki/RepRap_Firmware_macros#Set_of_macros_for_filament_detectionI published details and photos here: http://forums.reprap.org/read.php?416,668887,668887#msg-668887
However, I have yet to publish the stl and scad for the modified tensioner -
@dc42 My apologies. Everything I'd seen to this point (including this thread) seemed to indicate it wasn't yet a feature (reading comprehension fail).
Can it ignore the sensor when not actually printing? When my print is finished, the Tunell sensor will trigger a non-moving condition. As a result, the switch would be triggered until I reset it. This would cause the system to go to the "pause position" while at home and that's not so awesome of a result on a Delta printer.
A valid answer is, dump the fancy electronic sensor for one that doesn't trigger unless it's out of filament but I hope that's not the one you give me.
