Software driven heater/nested sensors

soare0

Lets say I have a thermostated chamber heather. I mean, it is like a bed (it is a bed), with heating element and thermistor.
If it would be a bed heater, it would be ok, but I intend to use it as a chamber heater.
Now, the chamber itself has its own sensor, and this may drive an output for the heather. The heather, being a heating pad, needs its own thermistor, to not overheat.
So we would have
Chamber sensor>>> Chamber output>>>>>|Heating pad element
Heating pad thermistor>>>>|

Normally, I would need some software intrerupt (wich would be simple if I could do in firmware, but I will not mess with it), something like

Defining them is simple

M308 S2 P"temp1" Y"pt1000"                         ; configure sensor 2 as pt1000 via temp1
M950 H2 C"out8" T2                                 ; create main chamber heater output on out8 and map it to sensor 2
M307 H2 B1 S1.00                                   ; enable bang-bang mode for heater  and set PWM limit
M141 P0 H2                                         ; map chamber0 to heater 2
M143 H2 S80                                        ; set temperature limit for heater 2 to 80C

M308 S3 P"1.temp2" Y"pt1000"  A"PAD SENSOR"            ; configure sensor 3 as pt1000 via 1.temp2

But out8 needs to be altered from S3 too, for example modifying its PWM:

if S3.temperature>100
       M307 H2  S0.00
else
      M307 H2  S1.00                            ;

The macro itself is simple, but I do not know how to trigger it, otherwise than inserting the trigger in slicing gcode, but this is not quite ok all the time, for various reasons, while it may be doable this way.

Is there a timer driven intrerupt available on DUET boards, or such a thing, or this needs to be done by an external trigger, triggered by ... out8>

infiniteloop

@soare0

Is there a timer driven intrerupt available on DUET boards, or such a thing

Back then with RRF 2.x, I had to configure a chamber heater composed of 2 PTCs, 4 fans, 2 thermistors sensing the PTCs and another 2 thermistors to monitor the temperatures at the top and bottom of the chamber. Just some entries to the config.g. Look: no macro script needed, no "interrupt" anywhere. Of course, the Gcodes were adjusted to work with the latest stable RRF (3.4.6).

; Setting up the chamber heater:
M308 S3 P"duex.e2temp" Y"thermistor" A"Chamber PTCs" T50000  ; sensor 3: direct thermistor on heater #3 (we use two parallel thermistors)
M308 S4 P"duex.e3temp" Y"thermistor" A"Chamber Top"          ; sensor 4: chamber top sensor controls heater
M308 S5 P"duex.e4temp" Y"thermistor" A"Chamber Bottom"       ; sensor 5: bottom sensor, just for info
M950 H3 C"duex.e2heat" T4                                    ; heater 3 is chamber heater, uses temp.-sensor 4
M307 H3 A11 C900 D30 B1                                      ; define heater model parameters manually
M141 H3 S-273.15 R0                                          ; heater 3: initially 0 degrees, off

; Adjust chamber heater fault detection:
M570 H3 P300 T25                                             ; allowed deviation before heater fault: < 300 secs, ± 25 degrees

; Connecting fans to the chamber heater:
M950 F3 C"duex.fan3"
M950 F4 C"duex.fan4"
M106 P3 L0.2 X0.7 T40:180 H3
M106 P4 L0.2 X0.7 T40:180 H3

; Protect chamber heaters against overheating:
M143 H3 T3 A2 C0 S150                                         ; shut-down heaters temporarily if exceeding 150 degrees (never happens, can be removed)

Your case involves less components, so you can simplify the setup.

soare0

@infiniteloop
I would say that my case is more complex than what you proposed.

You are using S3 just for overheating protection, and then put H3 it in fault state, wich makes H3 unusable.
S5 is just for info, so it does not matter.

S4 alone is driving, in fact, H3, and not, as I asked, S3 AND S4.

Lets recheck my question:

M308 S2 P"temp1" Y"pt1000"                         ; configure sensor 2 as pt1000 via temp1
M950 H2 C"out8" T2                                 ; create main chamber heater output on out8 and map it to sensor 2
M307 H2 B1 S1.00                                   ; enable bang-bang mode for heater  and set PWM limit
M141 P0 H2                                         ; map chamber0 to heater 2
M143 H2 S80                                        ; set temperature limit for heater 2 to 80C

M308 S3 P"1.temp2" Y"pt1000"  A"PAD SENSOR"            ; configure sensor 3 as pt1000 via 1.temp2

As I wanted to use a silicone bed (H2) with thermistor (S3), this needs to be not only protected, but regulated, like heating it at 100C. For this, is S3 needed
Then, the chamber needs to be regulated, using S2, but acting also onto H2, so they are mingled.
S3 is not just for fault protection, it needs to regulate too, but just the PAD, and only when S2 asks for it, because of the chamber.

This is just for fun, as I simply can add another regular heater (wich I may do afterall), but this too would open some possibilities.
I mean, DUET has ample possibilies (I would say), so a simple RTC, with a interrupt, would simplify this.

One can hardwire this, as I suggested, but this limits the number of processes wich can be handled.
This can be ... poetically addressed via some analog input, where we can have multiple processes "hardwired", but still, this is also complex.
The next step is to use a quantum core for duet, but maybe we will skip that for this time...

There is a simple logic to be addressed, with 2 sensors and one heater. I can continue using some jokes making analogies, just ask for it, hehe...

infiniteloop

@soare0

You are using S3 just for overheating protection, and then put H3 it in fault state, wich makes H3 unusable.

Right, my S3 is just an auxiliary measure to limit the PTCs - these things tend to thermal runaways and are thus limited internally (240° in my case). Basically, I intended to reduce air flow inside the chamber to a minimum, so the small PTCs dissipate their heat mainly by means of a large aluminum sheet, the fans only have to remove some heat from between sheet and chamber wall. So, my system is well balanced (it just has to handle 300 W) and never reached the S3 limit.

In your case, the easiest solution I can imagine is to monitor your S3 in daemon.g. By this, you can overcome the flaw your rightfully spotted in my approach. And yes: your poetical jokes are welcome

soare0

@infiniteloop said in Software driven heater/nested sensors:

In your case, the easiest solution I can imagine is to monitor your S3 in daemon.g.

Right, this was the answer I was searching for.
Thank you.

And a note: even if in old greek language (maybe in modern too) this filename means (translated) guardian.g, in our times has a somewhat darker resonance, and maybe that is why my subconscious mind avoided considering it (as I noticed it mentioned in the past, for such tasks).
I guess that in order to use another name, RRF source code needs to be modified. This being a ... conundrum (?), most probably I will increase the power of the actual heater, instead of doing funny things in funny files.

infiniteloop

@soare0 Interesting connotation, thanks for the insight. My reservation against using the δαίμονας is more profane: it has the potential to bog down the MCU, interpreted scripts tend to use vast amounts of processor cycles - which is especially true for my venerable Duet 2 system.

soare0

@infiniteloop
Yes, this is a problem, but I think any interrupt, if not treated in time slots, like for a RTOS, has this potential.
Profane interest indeed, infiniteshowoff (δαίμονας)! :D:D:D
Bigger power for the heater then...
Thanks