Controlling nozzle pressure with a PID loop



  • I'm making a custom machine with a Duet 2 controller and it needs to be able to regulate the pressure inside the printer nozzle while it's printing. Basically I need the extruder motor to speed up or slow down depending on if there's too much or too little pressure in the nozzle. I'm using a pressure transducer hooked up to the print head to read the pressure. Is there any way I could do this with the Duet controller?



  • (A) Do you also want it to follow the gcode E parameter on a coordinated move, with the pressure just modifying the baseline?

    (B) Or do you want it to be entirely and exclusively pressure controlled?

    (C) Or do you want it to be pressure controlled, during those moments in time when the Duet is commanding "forward" rotation of the E motor, and when the Duet commands "backward" rotation, follow that, actually rotate the motor backwards (i.e. retract)?

    (D) Or do you want it to be pressure controlled, only when "Enabled" by a status that is enabled and disabled in macros?

    (E) C and D combined? That is, pressure controlled when enable AND the E motor is running forward?

    Or something else?



  • I was initially thinking that it would be entirely driven by the pressure, but (A) would definitely be preferable. Ideally I'd give it a pressure to chase with an E value as a starting baseline and then let the duet controller make minor adjustments to accurately keep the same pressure.



  • Understood.

    What about retracts? How does the duet react to lines 12 through 16, or really to the combination of the first section of small extrusion moves , then those lines, then the next section of extrusion moves? It can't (shouldn't?) hold pressure during the backward rotation of the extruder, so what does it do?

    G1 X99.505 Y119.945 E0.04373
    G1 X98.986 Y119.260 E0.02696
    G1 X98.483 Y118.419 E0.03074
    G1 X97.922 Y117.068 E0.04586
    G1 X97.689 Y116.168 E0.02914
    G1 X97.560 Y115.259 E0.02879
    G1 X97.563 Y94.708 E0.64437
    G1 X97.891 Y93.025 E0.05374
    G1 X98.566 Y91.426 E0.05443
    G1 X99.513 Y90.058 E0.05215
    G1 F8640
    G1 X100.532 Y89.028 E-0.33480
    G1 X101.217 Y88.508 E-0.19855
    G1 X102.059 Y88.005 E-0.22636
    G1 X102.060 Y88.005 E-0.00028
    G1 E-0.04000 F2100.00000
    G1 Z0.800 F10800.000
    G1 X125.438 Y117.837
    G1 Z0.200
    G1 E0.80000 F2100.00000
    G1 F1200
    G1 X125.157 Y117.813 E0.00887
    G1 X125.144 Y117.882 E0.00220
    G1 X124.864 Y117.832 E0.00892
    G1 X124.846 Y117.900 E0.00220
    G1 X124.570 Y117.826 E0.00897
    G1 X124.546 Y117.892 E0.00219
    G1 X124.275 Y117.793 E0.00902
    


  • In case you are wondering, I'm asking these questions because my electronics sub-company is currently involved in a project where we are doing something VERY similar. Can't discuss any details. I can say that it involves "overriding" the Duet E moves, during a print, under certain circumstances, based on a combination of sensor inputs. Very, very similar to what you are asking.

    In this case, we chose to not ask Duet to change the firmware. Instead, we inserted a controller of our own that taps into the Step and Dir signals that are going to the Duet E motor driver (Duet 2 expansion). We configured the Duet to use a driver for E that doesn't exist, so we don't get errors from no motor plugged in. The new embedded controller has a Trinamic driver that connects to the E motor.

    In summary, the new controller is logically (and physically) "in between" the Duet and the E motor.

    The new controller mostly "passes through" the step and dir from the Duet. When the sensors hit certain values, it "takes over" and drives the E motor faster or slower than the Duet. The "take over" period may last from milliseconds to many seconds, entirely depending on the sensors.

    This approach of a controller "in between" the Duet and the E motor was chosen so that we did not have to modify Duet firmware. This was for speed of delivery (the embedded controller went from concept to alpha in about 1.5 weeks, and to beta in about another week) and to limit the circle of people involved in the NDA. Also, we have a very narrow and specialized requirement; your pressure sensing could become a very widely adopted function.

    Probably, for what you want, the correct answer in the long run is to have the Duet firmware take on this function. I mention all this for two reasons:

    First, so that you know we've explored a lot of these same questions in an actual running printer and corrected some of our own assumptions during Alpha testing.

    Second, you might consider a similar approach, a controller 'between' the Duet and E, for Proof-of-Concept, and get the same function embedded into Duet firmware if it proves viable, etc.

    I am danal (dot) estes (at) gmail (dot) com if you wish to discuss this further.



  • If nozzle pressure feedback can demonstrably improve the print quality, this could be an interesting cooperation between Duet and E3D, bringing another innovation to the market.



  • I had already been thinking about a solution similar to yours where I'd hook up the pressure transducer as a an input to the Duet's temperature sensor header and then use the Duet's PID control as an input into a micro controller that would drive a stepper motor. I like your way of doing it better though because it allows for a much more precise input for the micro-controller (A step and direction line vs a PWM signal).

    However, I think the key thing missing from your solution is the ability to communicate the desired pressure to the micro-controller. Ideally there'd be another argument added to the G1 command that's used to set a target pressure. That way on retract commands you could specify a pressure of zero so the extruder wouldn't try to maintain a pressure while also trying to retract.

    It would also be possible to use the direction line to specify a pressure override from what's set in the micro-controller. I.E. if the direction line is pulled high the micro-controller would know to stop trying to chase a target pressure and just listen to the step line.



  • @Cynopolis said in Controlling nozzle pressure with a PID loop:

    I had already been thinking about a solution similar to yours where I'd hook up the pressure transducer as a temperature sensor and then use the Duet's PID control as an input into a micro controller that would control a stepper motor. I like your way of doing it better though because it allows for a much more precise input for the micro-controller (A step and direction line vs a PWM signal).

    I believe this would be WAY WAY too slow for all the very quick changes in an extruder.

    However, I think the key thing missing from your solution is the ability to communicate the desired pressure to the micro-controller. Ideally there'd be another argument added to the G1 command that's used to set a target pressure. That way on retract commands you could specify a pressure of zero so the extruder wouldn't try to maintain a pressure while also trying to retract.

    Agreed, a clean way to get target pressure to the "in between" controller is a challenge. This is another reason to eventually do this in the Duet/RepRap firmware.

    It would also be possible to use the direction line to specify a pressure override from what's set in the micro-controller. I.E. if the direction line is pulled high the micro-controller would know to stop trying to chase a target pressure and just listen to the step line.

    That's why I was asking question (C) above.



  • I agree with you about my initial idea, and that's why I didn't want to go through with it in the first place. Your solution would certainly be faster and easier to implement in code. I apologize about the miscommunication in my initial response as well. I should've been more thorough in describing how the extruder should act in different use cases, and I hadn't really considered what should happen when I need the extruder to retract.

    I'd love to get this issue solved in firmware, but I'm very new to this forum. Where could I post to get this issue raised to the firmware developers?


  • Moderator

    Moved to the firmware wishlist forum where @dc42 can evaluate it.