Teacup issues and questions...

I've got an application where I wan't to use an atmega328 to drive a printer so I've decided to give teacup FW a test. I tested it on my current printer that uses sanguinololu electronics with an atmega1284p running at 16Mhz and have come across a few issues. Wondering if anyone can offer some pointers, advice or explanations.

Issue 1
PID doesn't seem very stable. I have a J-Head MKIV-b hotend and have previously calibrated the PID values in Marlin. Running the printer under Marlin I get almost perfect control of temperature (i.e only 2-3 deg overshoot and then +/-1 deg drift).

Here are the value I use:
#define DEFAULT_Kp 27.52
#define DEFAULT_Ki 1.79
#define DEFAULT_Kd 105.52

I first tried entering these values as is into heater.c as the default scaled factor #defines (obviously scaled by 1024). I did this the first time I programmed the micro, so was certain they were stored correctly into EEPROM. When running the printer, the temperature was overshooting by over 10degrees and then just oscillating +/- 5 degrees about 5 degrees higher than the set temperature. It never settled.

I then tried modifying the values using M13x commands and nothing I tried had a real positive effect on the PID performance other than setting the I factor to zero. However, nothing I did replicated or even came close to the performance I get under Marlin. I also noticed that big numbers greater than 16bits (i.e. the D factor) weren't being stored correctly. I was getting negative values when reading them back using M136.

I dug into the code and noticed something that I'm not sure about. In the structs the PID factors were declared as int32 but in the functions where they are being written to and/or read from EEPROM they we're being accessed as uint32. Something seems a little odd here.

a. Am I missing something?
b. Can anyone get stable PID using teacup?
c. Ways to improve what I'm getting?

Issue 2

I realised that with my setup I can get only a maximum speed of ~110mm/s in any axis otherwise the movement just goes out of whack. I read in the wiki what the limiting factors are and am ok with this - the numbers add up.

What I'm not sure about and what I wanted to confirm if what I'm see is correct is that certain E-movements cause the prints to slow down and almost stop. Again I'm comparing the performance to Marlin as that is what I'm used to and what I know.

What I'm seeing is that whenvener there is a retract/prime of the extruder, there is no lateral movement. The movement just stops to do the retract or prime and this is severly slowing down prints and also causing a kind of blobing in those areas where there is a retract.

Is this correct?

In marlin, it just seems a lot smoother and there are definately x/y moves during retracts (or at least it seems so).

Can someone point me to a video or their printer running teacup so I can compare it to mine as mine seems quite jerky and stop/starty.

BTW I don't use firmware retract (M101 or M103) - just normal G1 Exxx for retracts.

Quote

In the structs the PID factors were declared as int32 but in the functions where they are being written to and/or read from EEPROM they we're being accessed as uint32.

Looks like you discovered a bug :-) Patches are welcome!

Retracts like you use them depend on the G-code sent. If retract is in a separate G-code command, the commands are executed in that order. Marlin has probably a number of "tricks" in its sleeve which try to compensate for slicer shortcomings, so it's not exactly a measure for correct behaviour.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> In the structs the PID factors were declared as
> int32 but in the functions where they are being
> written to and/or read from EEPROM they we're
> being accessed as uint32.
>
> Looks like you discovered a bug :-) Patches are
> welcome!

Ok. I'm going to have a go at it. If it works I'll provide the patch. It's just a little confusing in some areas and I'll need to try and understand the code a little first to understand if there will be other conflicts by changing such parts.

Aside from this can you provide any feedback about the performance of the PID control in you experiance?

> Retracts like you use them depend on the G-code
> sent. If retract is in a separate G-code command,
> the commands are executed in that order. Marlin
> has probably a number of "tricks" in its sleeve
> which try to compensate for slicer shortcomings,
> so it's not exactly a measure for correct
> behaviour.

I don't use slic3r anymore, I use KISSlicer. Are you suggesting firmware based retractions are faster/smoother?

PS. I just discovered the gen7 branch. I've been using the default brach - not sure if the lookahead feature can help with this.

Here's an example of a retract between two infil paths in gcode

....
....
G1 X104.09 Y104.01 E10.0493
G1 X103.68 Y105.06 E10.087
G1 X103.58 Y105.07 E10.0901
G1 X102.5 Y103.98 E10.1416
;
; 'Wipe (and De-string)', 0.0 [feed mm/s], 48.8 [head mm/s]
G1 E9.1416 F1800
;
; 'Stacked Sparse Infill', 1.6 [feed mm/s], 48.8 [head mm/s]
G1 X101.95 Y97.92 E9.1416 F12000
G1 E10.1416 F1800
G1 X101.76 Y97.73 E10.1508 F2927.5
G1 X102.95 Y97.08 E10.1962
...
...

G1 E9.1416 F1800

This clearly means retract is done with no X/Y movement. Seems like Teacup does what it's commanded to do.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
HaniC
I've got an application where I wan't to use an atmega328 to drive a printer so I've decided to give teacup FW a test. I tested it on my current printer that uses sanguinololu electronics with an atmega1284p running at 16Mhz and have come across a few issues. Wondering if anyone can offer some pointers, advice or explanations.

Issue 1
PID doesn't seem very stable. I have a J-Head MKIV-b hotend and have previously calibrated the PID values in Marlin. Running the printer under Marlin I get almost perfect control of temperature (i.e only 2-3 deg overshoot and then +/-1 deg drift).

Here are the value I use:
#define DEFAULT_Kp 27.52
#define DEFAULT_Ki 1.79
#define DEFAULT_Kd 105.52

I first tried entering these values as is into heater.c as the default scaled factor #defines (obviously scaled by 1024). I did this the first time I programmed the micro, so was certain they were stored correctly into EEPROM. When running the printer, the temperature was overshooting by over 10degrees and then just oscillating +/- 5 degrees about 5 degrees higher than the set temperature. It never settled.

I then tried modifying the values using M13x commands and nothing I tried had a real positive effect on the PID performance other than setting the I factor to zero. However, nothing I did replicated or even came close to the performance I get under Marlin. I also noticed that big numbers greater than 16bits (i.e. the D factor) weren't being stored correctly. I was getting negative values when reading them back using M136.

I dug into the code and noticed something that I'm not sure about. In the structs the PID factors were declared as int32 but in the functions where they are being written to and/or read from EEPROM they we're being accessed as uint32. Something seems a little odd here.

a. Am I missing something?
b. Can anyone get stable PID using teacup?
c. Ways to improve what I'm getting?

a: What you are missing is easy to miss: the units of the PID parameters for Teacup. The Kp,Ki, Kd units you are using look like they might be in units of counts/C, counts/(Cs) and counts/(C/s), while Teacup uses parameters aligned to its quarter-degree-C (qC) and quarter-second (qs) sampling, along with the TH_COUNT history (8 samples), so Teacup's units are counts/qc, counts/(qc*qs), and counts/(qc/8*qs), so you might get similar performance out of setting the defaults near [github.com] to:

/// default scaled P factor, equivalent to 27.52/4*1024
#define DEFAULT_P 7045
/// default scaled I factor, equivalent to 1.79/16*1024
#define DEFAULT_I 114
/// default scaled D factor, equivalent to 105.52/8*1024
#define DEFAULT_D 13507
/// default scaled I limit = 255/114*1024
#define DEFAULT_I_LIMIT 2209

And maybe use Mcodes like M130 S6.88; M131 S 0.116; M132 S13.9; M133 S2209

b) Yes. I turned off my D since I had a noisy sensor, and didn't want to drive the process based on noise. (Your Kd=105 counts/degree-per-second value seems high for a process with significant dead time.) I slowed down the integral term significantly with a near-zero 0.05 term, and increased I limit to allow for a significant integral offset component: M133 S3600 ; 160 pwm /0.05. but then I needed to edit the code to actively limit proportional windup to limit the overshoot, since the I is winding up to I-limit from the beginning of the process change with Teacup. Marlin controls this somewhat with the interaction between resetting the integrator at +/-PID_FUNCTIONAL_LIMIT and kI, but produces weird behavior if the heater is too fast, or overshoot if the heater is too slow compared to the functional limit.

c) Use some sort of tuning method. Turn off kI and kD, search for a good kP then bring back kI and kD as needed. I imagine that with a KI of zero, you end up with a PD controller, and come to some steady-state value below your setpoint. If so, you could correct that by adding a M131 Ssomething, with a big enough M133 so that you could accumulate enough qC*qs so that Ki times the integral is enough to run your heater at the right value at steady state. However, the typical reprap PID algorithm doesn't fully protect against integral-windup and its overshoot-- you can tradeoff some of that behavior by limiting Teacup's I-limit below 255/kI, or with Marlin's PID_FUNCTIONAL_RANGE.