Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Software driven heater/nested sensors

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    2
    7
    224
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • soare0undefined
      soare0
      last edited by

      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>

      infiniteloopundefined 1 Reply Last reply Reply Quote 0
      • infiniteloopundefined
        infiniteloop @soare0
        last edited by

        @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.

        soare0undefined 1 Reply Last reply Reply Quote 0
        • soare0undefined
          soare0 @infiniteloop
          last edited by

          @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.

          1. One can hardwire this, as I suggested, but this limits the number of processes wich can be handled.
          2. This can be ... poetically addressed via some analog input, where we can have multiple processes "hardwired", but still, this is also complex.
          3. 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...

          infiniteloopundefined 1 Reply Last reply Reply Quote 0
          • infiniteloopundefined
            infiniteloop @soare0
            last edited by

            @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 😊

            soare0undefined 1 Reply Last reply Reply Quote 1
            • soare0undefined
              soare0 @infiniteloop
              last edited by

              @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.

              infiniteloopundefined 1 Reply Last reply Reply Quote 0
              • infiniteloopundefined
                infiniteloop @soare0
                last edited by

                @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.

                soare0undefined 1 Reply Last reply Reply Quote 0
                • soare0undefined
                  soare0 @infiniteloop
                  last edited by 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

                  1 Reply Last reply Reply Quote 1
                  • First post
                    Last post
                  Unless otherwise noted, all forum content is licensed under CC-BY-SA