PID Controller Design for Ventilator

Started by August 15, 2020
I understand the basics of PID design, but if you can't describe the thing being controlled, how can you design the controller other than trial and error?

The "plant" is a motor on a tall reducing gear (~300:1) turning an arm that presses on a bag producing an air flow with the loop controlled by a pressure measurement.

One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. frequency.  Presently they are using 3.6 kHz with 8 bit PWM control.  I kinda wonder if a sigma-delta might be better, but that might require some external logic.  They seem to be shy of pushing the CPU too much even after changing from an Arduino CPU at 20 MHz to an ARM CM4F at 80 MHz.

The big concern is the overshoot when ramping up the pressure between exhale and inhale.  In general, would it be better to simply jump the pressure set point at once and let the PID controller do its thing, optimizing the response time as best as possible controlling overshoot -or- would it be better to run up the pressure set point over a period of time which would seem to place less demand on the PID controller?

The model of the lung seems to include a spring constant (I think of this as a capacitor) in parallel with a dissipative element (a dashpot or resistor in electronics).  The motor is highly geared to a relatively lightweight arm pushing on a bag with air passing through a tube of relatively low restriction.  So initially the dominate opposition to flow will be the dissipation/resistor, i.e. proportional to the rate of airflow.  This in turn is proportional to the arm speed (although not constant through the stroke due to the bag geometry).  The arm speed is what is controlled by the PWM (approximately).

The lung model shows the dashpot and spring in parallel, but I'm not sure that's appropriate.  The response to air entering the lung will be the sum of the airway resistance (dashpot) and the lung compliance (spring) which would be a series combination to obtain the resulting air pressure.  Well, maybe that is right for the mechanical model, but in the electrical equivalent if pressure is the same as voltage it would be a series arrangement.

Anyway, the lung would seem to be a capacitor and a resistor.  So if driven by a P only controller, is there any way it could ring?  I was shown data measured that showed huge ringing from an initial step function in the set point.

I watched some videos and it seems they use both pressure regulated and flow regulated cycles.  I expect to see similar results with either method.

Interesting

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
On 8/15/2020 9:44 PM, Ricketty C wrote:
> I understand the basics of PID design, but if you can't describe the thing being controlled, how can you design the controller other than trial and error? > > The "plant" is a motor on a tall reducing gear (~300:1) turning an arm that presses on a bag producing an air flow with the loop controlled by a pressure measurement. > > One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. frequency. Presently they are using 3.6 kHz with 8 bit PWM control. I kinda wonder if a sigma-delta might be better, but that might require some external logic. They seem to be shy of pushing the CPU too much even after changing from an Arduino CPU at 20 MHz to an ARM CM4F at 80 MHz. > > The big concern is the overshoot when ramping up the pressure between exhale and inhale. In general, would it be better to simply jump the pressure set point at once and let the PID controller do its thing, optimizing the response time as best as possible controlling overshoot -or- would it be better to run up the pressure set point over a period of time which would seem to place less demand on the PID controller? > > The model of the lung seems to include a spring constant (I think of this as a capacitor) in parallel with a dissipative element (a dashpot or resistor in electronics). The motor is highly geared to a relatively lightweight arm pushing on a bag with air passing through a tube of relatively low restriction. So initially the dominate opposition to flow will be the dissipation/resistor, i.e. proportional to the rate of airflow. This in turn is proportional to the arm speed (although not constant through the stroke due to the bag geometry). The arm speed is what is controlled by the PWM (approximately). > > The lung model shows the dashpot and spring in parallel, but I'm not sure that's appropriate. The response to air entering the lung will be the sum of the airway resistance (dashpot) and the lung compliance (spring) which would be a series combination to obtain the resulting air pressure. Well, maybe that is right for the mechanical model, but in the electrical equivalent if pressure is the same as voltage it would be a series arrangement. > > Anyway, the lung would seem to be a capacitor and a resistor. So if driven by a P only controller, is there any way it could ring? I was shown data measured that showed huge ringing from an initial step function in the set point. > > I watched some videos and it seems they use both pressure regulated and flow regulated cycles. I expect to see similar results with either method. > > Interesting >
This graphical programming environment for Arduino has PID modules, and you can use it tweak the PID parameters in the GUI (or any parameters, actually) in real-time via the debugging interface while the code runs on the actual chip. No special interface required just USB cable <https://xod.io/>
On 8/15/2020 6:44 PM, Ricketty C wrote:
> I understand the basics of PID design, but if you can't describe the thing > being controlled, how can you design the controller other than trial and > error? > > The "plant" is a motor on a tall reducing gear (~300:1) turning an arm that > presses on a bag producing an air flow with the loop controlled by a > pressure measurement.
YOu (they) are controlling the current to a motor. The motor is driving a mechanism. The mechanism integrates the action of the motor. The mechanism pushes (?) air into the lungs via some sort of function that maps mechanism position to air volume "pushed". No idea what you are *measuring* -- and how it fits into the above. Presumably, what you are wanting to control is the RATE of air being pushed into the lungs (with possible clamps on the total volume expelled) But, you're only CONTROLLING the current to the motor. (Do you see all of the "transfer functions" that are involved in mapping the current to the "flow rate"?)
> One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. > frequency. Presently they are using 3.6 kHz with 8 bit PWM control. I > kinda wonder if a sigma-delta might be better, but that might require some > external logic. They seem to be shy of pushing the CPU too much even after > changing from an Arduino CPU at 20 MHz to an ARM CM4F at 80 MHz. > > The big concern is the overshoot when ramping up the pressure between exhale > and inhale. In general, would it be better to simply jump the pressure set > point at once and let the PID controller do its thing, optimizing the > response time as best as possible controlling overshoot -or- would it be > better to run up the pressure set point over a period of time which would > seem to place less demand on the PID controller? > > The model of the lung seems to include a spring constant (I think of this as > a capacitor) in parallel with a dissipative element (a dashpot or resistor > in electronics). The motor is highly geared to a relatively lightweight arm > pushing on a bag with air passing through a tube of relatively low > restriction. So initially the dominate opposition to flow will be the > dissipation/resistor, i.e. proportional to the rate of airflow. This in > turn is proportional to the arm speed (although not constant through the > stroke due to the bag geometry). The arm speed is what is controlled by the > PWM (approximately). > > The lung model shows the dashpot and spring in parallel, but I'm not sure > that's appropriate. The response to air entering the lung will be the sum > of the airway resistance (dashpot) and the lung compliance (spring) which > would be a series combination to obtain the resulting air pressure. Well, > maybe that is right for the mechanical model, but in the electrical > equivalent if pressure is the same as voltage it would be a series > arrangement. > > Anyway, the lung would seem to be a capacitor and a resistor. So if driven > by a P only controller, is there any way it could ring? I was shown data > measured that showed huge ringing from an initial step function in the set > point. > > I watched some videos and it seems they use both pressure regulated and flow > regulated cycles. I expect to see similar results with either method. > > Interesting >
On Saturday, August 15, 2020 at 11:07:10 PM UTC-4, Don Y wrote:
> On 8/15/2020 6:44 PM, Ricketty C wrote: > > I understand the basics of PID design, but if you can't describe the thing > > being controlled, how can you design the controller other than trial and > > error? > > > > The "plant" is a motor on a tall reducing gear (~300:1) turning an arm that > > presses on a bag producing an air flow with the loop controlled by a > > pressure measurement. > > YOu (they) are controlling the current to a motor. > The motor is driving a mechanism. > The mechanism integrates the action of the motor. > The mechanism pushes (?) air into the lungs via some sort of function > that maps mechanism position to air volume "pushed". > > No idea what you are *measuring* -- and how it fits into the above. > > Presumably, what you are wanting to control is the RATE of air > being pushed into the lungs (with possible clamps on the total > volume expelled) > > But, you're only CONTROLLING the current to the motor. > > (Do you see all of the "transfer functions" that are involved in > mapping the current to the "flow rate"?) > > > One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. > > frequency. Presently they are using 3.6 kHz with 8 bit PWM control. I > > kinda wonder if a sigma-delta might be better, but that might require some > > external logic. They seem to be shy of pushing the CPU too much even after > > changing from an Arduino CPU at 20 MHz to an ARM CM4F at 80 MHz. > > > > The big concern is the overshoot when ramping up the pressure between exhale > > and inhale. In general, would it be better to simply jump the pressure set > > point at once and let the PID controller do its thing, optimizing the > > response time as best as possible controlling overshoot -or- would it be > > better to run up the pressure set point over a period of time which would > > seem to place less demand on the PID controller? > > > > The model of the lung seems to include a spring constant (I think of this as > > a capacitor) in parallel with a dissipative element (a dashpot or resistor > > in electronics). The motor is highly geared to a relatively lightweight arm > > pushing on a bag with air passing through a tube of relatively low > > restriction. So initially the dominate opposition to flow will be the > > dissipation/resistor, i.e. proportional to the rate of airflow. This in > > turn is proportional to the arm speed (although not constant through the > > stroke due to the bag geometry). The arm speed is what is controlled by the > > PWM (approximately). > > > > The lung model shows the dashpot and spring in parallel, but I'm not sure > > that's appropriate. The response to air entering the lung will be the sum > > of the airway resistance (dashpot) and the lung compliance (spring) which > > would be a series combination to obtain the resulting air pressure. Well, > > maybe that is right for the mechanical model, but in the electrical > > equivalent if pressure is the same as voltage it would be a series > > arrangement. > > > > Anyway, the lung would seem to be a capacitor and a resistor. So if driven > > by a P only controller, is there any way it could ring? I was shown data > > measured that showed huge ringing from an initial step function in the set > > point. > > > > I watched some videos and it seems they use both pressure regulated and flow > > regulated cycles. I expect to see similar results with either method. > > > > Interesting > >
First, no, the current to the motor is not controlled, the voltage is controlled. I've already thought about the "transfer functions" which you seem to want to make complex. They are rather simple at a first approximation. The motor PWM drive controls the force on the bag which to a first approximation is the pressure in the bag. It will vary some through the stroke because of the bag geometry, more at first, less after the initial portion. So I'll say the pressure into a constant resistance to air flow is proportional to the PWM drive. The lung (as I've said) is the pneumatic equivalent of an RC series arrangement. Initially the counter force is all dissipative (air flow resistance) and the effect of the capacitor (lung elastance) is minimal in comparison. As the lung inflates the elastance becomes a larger factor. The only part that is at issue is the initial response to the step function of the control variable. That would seem to be dominated by proportional effects. I do see that there is little about my explanation that you understand. If you have questions I would be happy to answer, but you seem to be overwhelmed by it all. -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
On 8/15/2020 9:44 PM, Ricketty C wrote:
> I understand the basics of PID design, but if you can't describe the thing being controlled, how can you design the controller other than trial and error? > > The "plant" is a motor on a tall reducing gear (~300:1) turning an arm that presses on a bag producing an air flow with the loop controlled by a pressure measurement. > > One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. frequency. Presently they are using 3.6 kHz with 8 bit PWM control. I kinda wonder if a sigma-delta might be better, but that might require some external logic. They seem to be shy of pushing the CPU too much even after changing from an Arduino CPU at 20 MHz to an ARM CM4F at 80 MHz. > > The big concern is the overshoot when ramping up the pressure between exhale and inhale. In general, would it be better to simply jump the pressure set point at once and let the PID controller do its thing, optimizing the response time as best as possible controlling overshoot -or- would it be better to run up the pressure set point over a period of time which would seem to place less demand on the PID controller?
as I understand it in supportive ventilation the pressure application is triggered by patient breathing in, the pressure ramps up slowly to max while sensing the back-pressure from the lung, then the flow rate ramps down from peak in proportion to back-pressure as it starts rapidly increasing near the end of the cycle. there's a trade off between slow rise times and not hitting the required overall tidal volume, and fast rise times which are uncomfortable for the patient! There are different control schemes; like time-cycled and volume cycled, in time-cycled the total inspiration time is set and the mass flow rate during the "flat" part of the curve is dynamically adjusted to deliver the required volume, and volume cycled, where the peak mass flow rate is fixed and the inspiration time varies. I don't think I would be "jumping" anything, the output pressure is not a static value in either of the schemes AFAICT, always a dynamic function of the back-pressure. the peak flow rate is related to peak pressure but I don't think outlet pressure is the primary variable
> The model of the lung seems to include a spring constant (I think of this as a capacitor) in parallel with a dissipative element (a dashpot or resistor in electronics). The motor is highly geared to a relatively lightweight arm pushing on a bag with air passing through a tube of relatively low restriction. So initially the dominate opposition to flow will be the dissipation/resistor, i.e. proportional to the rate of airflow. This in turn is proportional to the arm speed (although not constant through the stroke due to the bag geometry). The arm speed is what is controlled by the PWM (approximately).
Simple mechanical model of a lung is just like you'd expect - an elastic bellows. Or a vertical dashpot, like a spirometer, with elastics that increase its resistance as the dashpot rises in the tube.
> The lung model shows the dashpot and spring in parallel, but I'm not sure that's appropriate. The response to air entering the lung will be the sum of the airway resistance (dashpot) and the lung compliance (spring) which would be a series combination to obtain the resulting air pressure. Well, maybe that is right for the mechanical model, but in the electrical equivalent if pressure is the same as voltage it would be a series arrangement. > > Anyway, the lung would seem to be a capacitor and a resistor. So if driven by a P only controller, is there any way it could ring? I was shown data measured that showed huge ringing from an initial step function in the set point.
The earliest hydraulic/mechanical ventilators were P-control only I think but the servos and valves had mechanical inertia the "loop gain" was intrinsically limited at high frequency. Can a P-only controller ring? Sure, any negative-feedback system with a phase lag in the loop and enough gain as the lag approaches 180 degrees can ring, you know dat
> I watched some videos and it seems they use both pressure regulated and flow regulated cycles. I expect to see similar results with either method. > > Interesting >
.
On 8/16/2020 12:20 AM, bitrex wrote:
> On 8/15/2020 9:44 PM, Ricketty C wrote: >> I understand the basics of PID design, but if you can't describe the >> thing being controlled, how can you design the controller other than >> trial and error? >> >> The "plant" is a motor on a tall reducing gear (~300:1) turning an arm >> that presses on a bag producing an air flow with the loop controlled >> by a pressure measurement. >> >> One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. >> frequency.&nbsp; Presently they are using 3.6 kHz with 8 bit PWM control. >> I kinda wonder if a sigma-delta might be better, but that might >> require some external logic.&nbsp; They seem to be shy of pushing the CPU >> too much even after changing from an Arduino CPU at 20 MHz to an ARM >> CM4F at 80 MHz. >> >> The big concern is the overshoot when ramping up the pressure between >> exhale and inhale.&nbsp; In general, would it be better to simply jump the >> pressure set point at once and let the PID controller do its thing, >> optimizing the response time as best as possible controlling overshoot >> -or- would it be better to run up the pressure set point over a period >> of time which would seem to place less demand on the PID controller? > > as I understand it in supportive ventilation the pressure application is > triggered by patient breathing in, the pressure ramps up slowly to max > while sensing the back-pressure from the lung, then the flow rate ramps > down from peak in proportion to back-pressure as it starts rapidly > increasing near the end of the cycle. there's a trade off between slow > rise times and not hitting the required overall tidal volume, and fast > rise times which are uncomfortable for the patient! > > There are different control schemes; like time-cycled and volume cycled, > in time-cycled the total inspiration time is set and the mass flow rate > during the "flat" part of the curve is dynamically adjusted to deliver > the required volume, and volume cycled, where the peak mass flow rate is > fixed and the inspiration time varies. > > I don't think I would be "jumping" anything, the output pressure is not > a static value in either of the schemes AFAICT, always a dynamic > function of the back-pressure. the peak flow rate is related to peak > pressure but I don't think outlet pressure is the primary variable
That is to say if the back-pressure starts increasing _for any reason_ you have to start dropping the outlet pressure proportionally you can't just set it and forget it!
On Sunday, August 16, 2020 at 12:21:03 AM UTC-4, bitrex wrote:
> On 8/15/2020 9:44 PM, Ricketty C wrote: > > I understand the basics of PID design, but if you can't describe the thing being controlled, how can you design the controller other than trial and error? > > > > The "plant" is a motor on a tall reducing gear (~300:1) turning an arm that presses on a bag producing an air flow with the loop controlled by a pressure measurement. > > > > One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. frequency. Presently they are using 3.6 kHz with 8 bit PWM control. I kinda wonder if a sigma-delta might be better, but that might require some external logic. They seem to be shy of pushing the CPU too much even after changing from an Arduino CPU at 20 MHz to an ARM CM4F at 80 MHz. > > > > The big concern is the overshoot when ramping up the pressure between exhale and inhale. In general, would it be better to simply jump the pressure set point at once and let the PID controller do its thing, optimizing the response time as best as possible controlling overshoot -or- would it be better to run up the pressure set point over a period of time which would seem to place less demand on the PID controller? > > as I understand it in supportive ventilation the pressure application is > triggered by patient breathing in, the pressure ramps up slowly to max > while sensing the back-pressure from the lung, then the flow rate ramps > down from peak in proportion to back-pressure as it starts rapidly > increasing near the end of the cycle. there's a trade off between slow > rise times and not hitting the required overall tidal volume, and fast > rise times which are uncomfortable for the patient!
I had not looked at the problem until today, but I'm being told the pressure should rise within 100 ms of sensing the patient breathing. I believe this is a comfort thing where they don't want to feel they are unable to breath. I watched a video earlier tonight indicating when the patient starts the breath the machine then essentially forces the breath either by controlling the pressure as a constant for a set amount of time or by controlling the flow rate as a constant until a volume is reached. Both methods have advantages and disadvantages. I don't see where they distinguish between patient triggered and machine triggered. This guy Allan Gonzales is terrible to listen to, but he does keep them short. https://www.youtube.com/watch?v=psEAJQQXN3I He shows the only difference between patient triggered and machine triggered waveforms is the negative pressure from the patient trying to draw air in at the very start of the cycle. His diagrams are pretty poor with no registration between the various points on different parameters, but he gets across the main points. You can do a Google search to find other much better diagrams. I don't think there are any new concepts to an engineer. https://www.google.com/search?q=ventilator+pressure+vs+volume&source=lnms&tbm=isch&sa=X&ved=2ahUKEwim2e7gu57rAhVtqlkKHW5YDckQ_AUoAXoECA0QAw&biw=1012&bih=555#imgrc=UjeGmhYTkW1S0M
> There are different control schemes; like time-cycled and volume cycled, > in time-cycled the total inspiration time is set and the mass flow rate > during the "flat" part of the curve is dynamically adjusted to deliver > the required volume, and volume cycled, where the peak mass flow rate is > fixed and the inspiration time varies.
Yup...
> I don't think I would be "jumping" anything, the output pressure is not > a static value in either of the schemes AFAICT, always a dynamic > function of the back-pressure. the peak flow rate is related to peak > pressure but I don't think outlet pressure is the primary variable
Not sure why you say that. What you call "timed" is constant pressure. There is no intended modulation of the pressure... hence "constant". In order to use a fixed time the not fixed flow rate has to be well known for a given pressure. If the pressure varies at all it messes this up. The machine is also measuring the volume by integrating the flow rate. So I don't know why anyone would feel the need to work to a "fixed" inspiration time. If there is some variation in lung compliance there could be significant variations in the flow rate and volume. This diagram shows that very clearly. https://clinicalgate.com/mechanical-ventilation-5/ I wonder if there are reasons why they do things the way they do or if it is just "this is what we all do" so they keep doing it that way?
> > The model of the lung seems to include a spring constant (I think of this as a capacitor) in parallel with a dissipative element (a dashpot or resistor in electronics). The motor is highly geared to a relatively lightweight arm pushing on a bag with air passing through a tube of relatively low restriction. So initially the dominate opposition to flow will be the dissipation/resistor, i.e. proportional to the rate of airflow. This in turn is proportional to the arm speed (although not constant through the stroke due to the bag geometry). The arm speed is what is controlled by the PWM (approximately). > > Simple mechanical model of a lung is just like you'd expect - an elastic > bellows. Or a vertical dashpot, like a spirometer, with elastics that > increase its resistance as the dashpot rises in the tube.
Yes, that's what I said I believe, dissipation and spring. Mechanically they are in parallel, or in an electrical analogy it is a resistor and capacitor in parallel with voltage representing pressure and current as flow, the charge on the cap as volume.
> > The lung model shows the dashpot and spring in parallel, but I'm not sure that's appropriate. The response to air entering the lung will be the sum of the airway resistance (dashpot) and the lung compliance (spring) which would be a series combination to obtain the resulting air pressure. Well, maybe that is right for the mechanical model, but in the electrical equivalent if pressure is the same as voltage it would be a series arrangement. > > > > Anyway, the lung would seem to be a capacitor and a resistor. So if driven by a P only controller, is there any way it could ring? I was shown data measured that showed huge ringing from an initial step function in the set point. > > The earliest hydraulic/mechanical ventilators were P-control only I > think but the servos and valves had mechanical inertia the "loop gain" > was intrinsically limited at high frequency. Can a P-only controller > ring? Sure, any negative-feedback system with a phase lag in the loop > and enough gain as the lag approaches 180 degrees can ring, you know dat
Where would the lag come from in this system? That's my point. I'm pretty sure I could do a few calculations and produce a table of values that take into account the variable motor speed to air flow relation of the bag and another that models the lung resulting in a very simple controller that needs no PID terms. I'm just not seeing any complications in controlling this device. I have no idea how they made it ring. Worse they said they read texts on PID controllers that said P only will ring with a high coefficent. If the P only rings, it's going to go nuts when you add the I term. When I hand tweak PID controllers I typically start with a large P term and add in I until it starts to act wonky, then play with them a bit until I get minimum overshoot with good response. This has always been fairly simple devices being controlled. If you had an RC series circuit on the output of a PID controller, do you think you could make that ring? Maybe the motor and bag are more complex than I realize or the connecting tubing is more complicated than I think. I believe the tubing is around 10% the volume as the bag. Still, it shouldn't be a big deal it seems. Even if the compliance of the various spaces act like coupled capacitors, the time constants are going to be *very* short. Not my problem at the moment. We'll see what happens. -- Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
On Sunday, August 16, 2020 at 12:32:46 AM UTC-4, bitrex wrote:
> On 8/16/2020 12:20 AM, bitrex wrote: > > On 8/15/2020 9:44 PM, Ricketty C wrote: > >> I understand the basics of PID design, but if you can't describe the > >> thing being controlled, how can you design the controller other than > >> trial and error? > >> > >> The "plant" is a motor on a tall reducing gear (~300:1) turning an arm > >> that presses on a bag producing an air flow with the loop controlled > >> by a pressure measurement. > >> > >> One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. > >> frequency.&nbsp; Presently they are using 3.6 kHz with 8 bit PWM control. > >> I kinda wonder if a sigma-delta might be better, but that might > >> require some external logic.&nbsp; They seem to be shy of pushing the CPU > >> too much even after changing from an Arduino CPU at 20 MHz to an ARM > >> CM4F at 80 MHz. > >> > >> The big concern is the overshoot when ramping up the pressure between > >> exhale and inhale.&nbsp; In general, would it be better to simply jump the > >> pressure set point at once and let the PID controller do its thing, > >> optimizing the response time as best as possible controlling overshoot > >> -or- would it be better to run up the pressure set point over a period > >> of time which would seem to place less demand on the PID controller? > > > > as I understand it in supportive ventilation the pressure application is > > triggered by patient breathing in, the pressure ramps up slowly to max > > while sensing the back-pressure from the lung, then the flow rate ramps > > down from peak in proportion to back-pressure as it starts rapidly > > increasing near the end of the cycle. there's a trade off between slow > > rise times and not hitting the required overall tidal volume, and fast > > rise times which are uncomfortable for the patient! > > > > There are different control schemes; like time-cycled and volume cycled, > > in time-cycled the total inspiration time is set and the mass flow rate > > during the "flat" part of the curve is dynamically adjusted to deliver > > the required volume, and volume cycled, where the peak mass flow rate is > > fixed and the inspiration time varies. > > > > I don't think I would be "jumping" anything, the output pressure is not > > a static value in either of the schemes AFAICT, always a dynamic > > function of the back-pressure. the peak flow rate is related to peak > > pressure but I don't think outlet pressure is the primary variable > > That is to say if the back-pressure starts increasing _for any reason_ > you have to start dropping the outlet pressure proportionally you can't > just set it and forget it!
Not sure what you mean by outlet pressure and back-pressure. What is your model like? -- Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209
On 8/16/2020 1:47 AM, Ricketty C wrote:
> On Sunday, August 16, 2020 at 12:32:46 AM UTC-4, bitrex wrote: >> On 8/16/2020 12:20 AM, bitrex wrote: >>> On 8/15/2020 9:44 PM, Ricketty C wrote: >>>> I understand the basics of PID design, but if you can't describe the >>>> thing being controlled, how can you design the controller other than >>>> trial and error? >>>> >>>> The "plant" is a motor on a tall reducing gear (~300:1) turning an arm >>>> that presses on a bag producing an air flow with the loop controlled >>>> by a pressure measurement. >>>> >>>> One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. >>>> frequency.&nbsp; Presently they are using 3.6 kHz with 8 bit PWM control. >>>> I kinda wonder if a sigma-delta might be better, but that might >>>> require some external logic.&nbsp; They seem to be shy of pushing the CPU >>>> too much even after changing from an Arduino CPU at 20 MHz to an ARM >>>> CM4F at 80 MHz. >>>> >>>> The big concern is the overshoot when ramping up the pressure between >>>> exhale and inhale.&nbsp; In general, would it be better to simply jump the >>>> pressure set point at once and let the PID controller do its thing, >>>> optimizing the response time as best as possible controlling overshoot >>>> -or- would it be better to run up the pressure set point over a period >>>> of time which would seem to place less demand on the PID controller? >>> >>> as I understand it in supportive ventilation the pressure application is >>> triggered by patient breathing in, the pressure ramps up slowly to max >>> while sensing the back-pressure from the lung, then the flow rate ramps >>> down from peak in proportion to back-pressure as it starts rapidly >>> increasing near the end of the cycle. there's a trade off between slow >>> rise times and not hitting the required overall tidal volume, and fast >>> rise times which are uncomfortable for the patient! >>> >>> There are different control schemes; like time-cycled and volume cycled, >>> in time-cycled the total inspiration time is set and the mass flow rate >>> during the "flat" part of the curve is dynamically adjusted to deliver >>> the required volume, and volume cycled, where the peak mass flow rate is >>> fixed and the inspiration time varies. >>> >>> I don't think I would be "jumping" anything, the output pressure is not >>> a static value in either of the schemes AFAICT, always a dynamic >>> function of the back-pressure. the peak flow rate is related to peak >>> pressure but I don't think outlet pressure is the primary variable >> >> That is to say if the back-pressure starts increasing _for any reason_ >> you have to start dropping the outlet pressure proportionally you can't >> just set it and forget it! > > Not sure what you mean by outlet pressure and back-pressure. What is your model like? >
There's some force per unit area of the air coming out of the tube into the lungs, and as air fills the lungs there's some back-pressure resisting that force from the weight of the atmosphere pushing down on the lungs. Like when you blow into a balloon. The early hydro-mechanical ventilators were back-pressure regulated; when back-pressure reaches a set point the exhale cycle is triggered.
On Sunday, August 16, 2020 at 1:59:02 AM UTC-4, bitrex wrote:
> On 8/16/2020 1:47 AM, Ricketty C wrote: > > On Sunday, August 16, 2020 at 12:32:46 AM UTC-4, bitrex wrote: > >> On 8/16/2020 12:20 AM, bitrex wrote: > >>> On 8/15/2020 9:44 PM, Ricketty C wrote: > >>>> I understand the basics of PID design, but if you can't describe the > >>>> thing being controlled, how can you design the controller other than > >>>> trial and error? > >>>> > >>>> The "plant" is a motor on a tall reducing gear (~300:1) turning an arm > >>>> that presses on a bag producing an air flow with the loop controlled > >>>> by a pressure measurement. > >>>> > >>>> One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. > >>>> frequency.&nbsp; Presently they are using 3.6 kHz with 8 bit PWM control. > >>>> I kinda wonder if a sigma-delta might be better, but that might > >>>> require some external logic.&nbsp; They seem to be shy of pushing the CPU > >>>> too much even after changing from an Arduino CPU at 20 MHz to an ARM > >>>> CM4F at 80 MHz. > >>>> > >>>> The big concern is the overshoot when ramping up the pressure between > >>>> exhale and inhale.&nbsp; In general, would it be better to simply jump the > >>>> pressure set point at once and let the PID controller do its thing, > >>>> optimizing the response time as best as possible controlling overshoot > >>>> -or- would it be better to run up the pressure set point over a period > >>>> of time which would seem to place less demand on the PID controller? > >>> > >>> as I understand it in supportive ventilation the pressure application is > >>> triggered by patient breathing in, the pressure ramps up slowly to max > >>> while sensing the back-pressure from the lung, then the flow rate ramps > >>> down from peak in proportion to back-pressure as it starts rapidly > >>> increasing near the end of the cycle. there's a trade off between slow > >>> rise times and not hitting the required overall tidal volume, and fast > >>> rise times which are uncomfortable for the patient! > >>> > >>> There are different control schemes; like time-cycled and volume cycled, > >>> in time-cycled the total inspiration time is set and the mass flow rate > >>> during the "flat" part of the curve is dynamically adjusted to deliver > >>> the required volume, and volume cycled, where the peak mass flow rate is > >>> fixed and the inspiration time varies. > >>> > >>> I don't think I would be "jumping" anything, the output pressure is not > >>> a static value in either of the schemes AFAICT, always a dynamic > >>> function of the back-pressure. the peak flow rate is related to peak > >>> pressure but I don't think outlet pressure is the primary variable > >> > >> That is to say if the back-pressure starts increasing _for any reason_ > >> you have to start dropping the outlet pressure proportionally you can't > >> just set it and forget it! > > > > Not sure what you mean by outlet pressure and back-pressure. What is your model like? > > > > There's some force per unit area of the air coming out of the tube into > the lungs, and as air fills the lungs there's some back-pressure > resisting that force from the weight of the atmosphere pushing down on > the lungs. Like when you blow into a balloon.
You reasoning still isn't clear to me. Everything has pressure from the atmosphere. That's why pressure in most cases is relative, not absolute. So that's simply not an issue. The balloon is elastic, that's why they require pressure to inflate. Inflating a paper bag is against air pressure only. What you are calling "back-pressure" is the combination of the dissipative effect (mostly moving air through the various forking passages I expect) and the compliance of the lungs (the elastic effect which actually does push back but without a lag). That is the pressure the vent has to assert to get air into the lungs, proportional to A*I + B*dI/dt which is what I've been describing all along.
> The early hydro-mechanical ventilators were back-pressure regulated; > when back-pressure reaches a set point the exhale cycle is triggered.
That might be a flow regulated unit. The flow is constant, so the pressure increases from the elastic effect until the volume is achieved and the exhale begins. -- Rick C. +- Get 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209