dc42 firmware - nozzle heater PID

I'm wondering if I'm seeing expected behavior when the PID starts chopping the heater drive here:



(75 Seconds of proportional control before the target temp is reached and printing starts)

I've reverted to the default PID params after replacing the ATX PSU with a 13.8V 25A desktop unit which has increased the warm-up times considerably. The heater cartridge seems OK given the steep rise in temperature before PWM kicks in. Just wondering if this is normal or indicative of something wrong.

firmware 1.04e-dc42

---

RS Components Reprap Ormerod No. 481

I don't think there's anything physically wrong with your system, just one of your PID values needs to be adjusted slightly to reduce the slow warm up time.

I'm not an expert of PID controllers, but I think you'll probably need to increase the Integral slightly.... Here's what the Wiki says: [reprap.org]

Quote

For manual adjustments:
if it overshoots a lot and oscillates, either the integral gain needs to be increased or all gains should be reduced
Too much overshoot? Increase D, decrease P.
Response too damped? Increase P.
Ramps up quickly to a value below target temperature (0-160 fast) and then slows down as it approaches target (160-170 slow, 170-180 really slow, etc) temperature? Try increasing the I constant.

However, DC42 should know for sure, as he seems to have a good understanding of PID.

You can increase the I term, but that is likely to result in overshoot. I suggest increasing either the S term or the T term - either should work.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

DC42

Just out of curiosity, why doesn't the RepRap firmware have PID autotuning like Marlin, Repetier and Smoothie? Is it too complicated? Or just not worth the time because it's easy enough to do by hand?

Good question! I might have a go at implementing this.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I too have a slow hotend.

Following advice from a previous post I think I need to do:
M301 P10 S1.1
And perhaps reduce the S value if it overshoots a bit?

My question:
Do I put this command into my config file?

Quote
TH57
I too have a slow hotend.

Following advice from a previous post I think I need to do:
M301 P10 S1.1
And perhaps reduce the S value if it overshoots a bit?

My question:
Do I put this command into my config file?

Try sending it from the gcode console in the web interface or from pronterface first, while the nozzle is still at room temperature. Then command the nozzle to printing temperature. If the temperature undershoots or overshoots, increase or decrease the S factor again as appropriate, let the nozzle cool to near room temperature, and try again. When you have found a good value for S, put it in config.g.

PS - in my next release, I think I'll increase the P, I and D values (which is equivalent to increasing S), because a number of users have reported undershoot on this forum, but nobody has reported overshoot yet. My intention is that S = 1 is suitable for an average power heater, assuming you haven't turned up the voltage beyond 12V.

Edited 1 time(s). Last edit at 04/30/2015 03:29PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks guys, I've now reduced the delay from 75 down to 20 seconds by using I=1.3 There is a small initial overshoot but it settles well before the printing gets underway.
It seems to take a great deal of patience to get satisfactory PID settings so any "Auto tuner" would be most welcome indeed!

---

RS Components Reprap Ormerod No. 481

I've had a couple of customers report heater timeout issues, since firmware 1.09. I think Christian rolled in dc42's PID changes with that firmware. The feedback I've had usually points to a heater cartridge that has a bit higher resistance than normal; one customer that was experiencing heater timeouts had a heater cartridge resistance of around 5 ohms.

The current default PID settings in v1.09 are:

SENDING:M301
Heater 1 P:10.00 I:0.100 D:100.00 T:0.40 S:1.00 W:180.0 B:30.0

The default PID settings in v1.04 were:

SENDING:M301 H1
Heater 1 - P:20.000000 I:0.500000 D: 100.000000

These seemed to work well for most people. Is there any problem setting the PID back to the 1.04 values? Do the other parameters - S (Scaling, I think), W (?) and B (?) matter?

Ian
RepRapPro tech support

Also, something slightly odd...
If I send:

Connecting...
Printer is now online.
>>>M301
SENDING:M301
Heater 1 P:10.00 I:0.100 D:100.00 T:0.40 S:1.00 W:180.0 B:30.0
>>>M301 H1 P20 I0.5 D100
SENDING:M301 H1 P20 I0.5 D100
>>>M301
SENDING:M301
Heater 1 P:20.00 I:1.000 D:50.00 T:0.40 S:1.00 W:180.0 B:30.0

Note I sent P=20 I=0.5 D=100, but it reports as if it has double 'I' and halved 'D'! It does this for any value I put in. To get the 1.04 PID values, I have to send:

>>>M301 H1 P20 I0.25 D200
SENDING:M301 H1 P20 I0.25 D200
>>>M301
SENDING:M301
Heater 1 P:20.00 I:0.500 D:100.00 T:0.40 S:1.00 W:180.0 B:30.0

Is it reporting the wrong settings, or is it doing a different calculation?

Ian
RepRapPro tech support

Quote
droftarts
I've had a couple of customers report heater timeout issues, since firmware 1.09. I think Christian rolled in dc42's PID changes with that firmware.

Nice of you to credit me with some of the code in 1.09, even if only in a negative context! I put a lot of work into RepRapFirnware, much of which made its way into 1.09 via zpl's fork (i.e. most of the changes listed at [github.com] that I don't attribute to zpl or RRP), but the 1.09 announcement at [reprappro.com] doesn't mention my contribution at all.

Quote
droftarts
The feedback I've had usually points to a heater cartridge that has a bit higher resistance than normal; one customer that was experiencing heater timeouts had a heater cartridge resistance of around 5 ohms.

The current default PID settings in v1.09 are:

SENDING:M301
Heater 1 P:10.00 I:0.100 D:100.00 T:0.40 S:1.00 W:180.0 B:30.0

The default PID settings in v1.04 were:

SENDING:M301 H1
Heater 1 - P:20.000000 I:0.500000 D: 100.000000

These seemed to work well for most people. Is there any problem setting the PID back to the 1.04 values? Do the other parameters - S (Scaling, I think), W (?) and B (?) matter?

Let me explain the reasons for the changes I made. The default RRP PID settings worked very badly for me. Using the ones in the original 0.59 (AFAIR) release, the hot end wouldn't even reach the selected temperature. Using the values you changed to in later releases, there was massive overshoot on one of my hot ends. So I decided to look into what was going on.

The original values make the system highly nonlinear, which means that PID theory breaks down. This is because the PID band was set way too high (180C AFAIR), and the PWM is limited to values between 0 and 255. If you wanted to heat the hot end from 20C to 200C, the temperature difference of 180C times the P term (which was still 20 AFAIR) commanded a PID value of many thousand, which was of course impossible. So the heating proceeded much more slowly than PID theory requires. This resulted in the I term getting wound up a lot. If the product of heater power and I term were just right, you might be lucky and get the hot end to reach the target temperature quickly. But the cartridge heater resistance seems to vary a lot between different heaters, which in many cases results in severe overshoot and oscillation (as I encountered) or undershoot. So I decided this was not a good approach.

The approach I took was to use a much narrower PID band, within which the system is essentially linear and PID theory works. This requires that when switching to PID, the I term is preset to approximately the value needed to maintain the temperature at which the switch over is performed. I introduced the T term to compute this value, and calibrated it based on the heaters I was using at the time (and am still using). These heaters have a resistance of about 2.8 ohms.

When it became apparent to me that the heaters vary so much in power, I introduced the S term to scale the output to account for different heater powers - or different supply voltages, because by then some people were powering Ormerods from LED PSUs turned up to 14V, which increases heater power by 36%. The alternative is to adjust all of P, I, D and T.

Based on recent reports of undershoot, I think the heaters I am using are probably more powerful than average (even though my PSU is set to 12V), and the default values of some or all of P, I, D and T ought to be increased.

I don't think you can get a single set of PID settings that works really well over such a wide range of heater powers. Preferably, some sort of auto-tune facility should be introduced. It needn't be as complicated as the auto tune in Marlin if you are essentially targeting only one hot end design, it could just measure the heater power and adjust S.

Quote
droftarts
Also, something slightly odd...

RRP made a change several versions ago, which was to allow the PID sample/adjust frequency to be configured via an M code. This means that the I and D terms need to be adjusted according to the PID interval when the sample frequency is changed, and all getting and setting of the I and D terms done in terms of some normalised frequency. The RRP code failed to take account of this. I'm sure I tested the changes I made to allow for this at the time; however it looks like the adjustment is not being done correctly in 1.09 (and my fork of 1.09 shows the same problem).

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I am sure ALL users are very appreciative of dc42's hard work in improving the ormerod firmware.
His efforts should be recognised by reprappro and shouted from the tree tops.
I hate to think where we would be without his expertise and experience.

Well done David,
please keep up the good work
Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Yep indeed, I doubt we would have ever gotten to this stage of firmware quality without David's contributions. When I started my firmware development about a year ago, I chose David's fork as a base for a reason, especially because it turned out to be somewhat usable compared to the old RRP firmware at that time! I remember the old firmware used to hang up quite frequently and didn't even have the watchdog enabled, which IMO also meant a serious safety concern. If it hadn't been for the contributions he provided at that time, I would have probably dumped my Ormerod a long time ago, and would have never written most of the networking improvements, the new web interface and other changes.

When I release new versions of my firmware fork here on the forum, I have always paid credit to the changes DC (and partially RRP) had introduced and I always will, since IMHO this is just fair in open-source development. Same goes for David's firmware releases, he has always mentioned my name after he had merged in parts from my firmware fork. I am sorry that the official RRP 1.09 firmware announcement doesn't make this clear, but I did not have an influence on that article (actually I was on holiday when the new firmware was released). Nevertheless, Ian and I have talked again to RRP and we're quite confident they will edit the news entry once more to mention your name, and in an appropriate way pay credit to the contributions you have been gratefully providing.

And just for clarification: I've never said that I introduced all of the improvements in my firmware fork, that would be just ridiculous, and as I've been working on the firmware myself for quite a while, too, I can very well understand why this is upsetting. I did introduce 90% of the improvements mentioned in that article, however features like serving all files directly from the Duet and long filename support were clearly implemented by David's efforts along with many other firmware improvements not even mentioned in that article.

So in conclusion: Thank you once more David, I do appreciate your work, and your advice on programming techniques and designing common standards together!

Quote
dc42
Nice of you to credit me with some of the code in 1.09, even if only in a negative context! I put a lot of work into RepRapFirnware, much of which made its way into 1.09 via zpl's fork (i.e. most of the changes listed at [github.com] that I don't attribute to zpl or RRP), but the 1.09 announcement at [reprappro.com] doesn't mention my contribution at all.

Hi dc42. Apologies, we have now updated that blog post, and acknowledged your contributions. See the first paragraph. We'll try to remember this in the future. At the time of release of 1.09, we were concentrating on the changes to the network code, rather than other changes zpl merged in. It wasn't intentional, just that we weren't even expecting them! I didn't mean to sound negative, I was just following on from the thread, trying to work out what was going on.

Quote
dc42
Let me explain the reasons for the changes I made...

Thanks for the explanation. As I said, I was surprised that your PID code ended up in our firmware. Our PID code seemed to be working fine (though the initial settings in 0.59 were not great - but that was over a year ago!). While I appreciate one set of settings doesn't necessarily work for everyone, our settings were working - I hadn't had any queries about this. Now I do, though it does seem from people who's heater cartridges have a resistance higher than 3 ohms.

Quote
dc42
RRP made a change several versions ago, which was to allow the PID sample/adjust frequency to be configured via an M code. This means that the I and D terms need to be adjusted according to the PID interval when the sample frequency is changed, and all getting and setting of the I and D terms done in terms of some normalised frequency. The RRP code failed to take account of this. I'm sure I tested the changes I made to allow for this at the time; however it looks like the adjustment is not being done correctly in 1.09 (and my fork of 1.09 shows the same problem).

As far as I'm aware, the 1.04 code did take account of the sample frequency, and, from a quick test, it reports the correct values when they're changed with M301. I asked Adrian to look at this thread. He has suggested there's a small bug in the M301/ code:

        if (gb->Seen('I'))
        {
            pp.kI = gb->GetFValue() / platform->HeatSampleTime();
            seen = true;
        }
        if (gb->Seen('D'))
        {
            pp.kD = gb->GetFValue() * platform->HeatSampleTime();
            seen = true;
        }

and then

reply.printf("Heater %d P:%.2f I:%.3f D:%.2f T:%.2f S:%.2f W:%.1f B:%.1f\n",
                    heater, pp.kP, pp.kI, pp.kD, pp.kT, pp.kS, pp.pidMax, pp.fullBand);

the latter should be

reply.printf("Heater %d P:%.2f I:%.3f D:%.2f T:%.2f S:%.2f W:%.1f B:%.1f\n",
                    heater, pp.kP, pp.kI*platform->HeatSampleTime(), pp.kD/platform->HeatSampleTime(), pp.kT, pp.kS, pp.pidMax, pp.fullBand);

So, I think it sets them correctly, it just doesn't report the right numbers. I guess the HeatSampleTime() is set to 0.5. I have yet to test the old PID values, to see if it helps with higher resistance heater cartridges.

Ian
RepRapPro tech support