Electronics-Related.com
Forums

PID Controller Design for Ventilator

Started by Ricketty C August 15, 2020
On 8/16/2020 2:13 AM, Ricketty C wrote:
> 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.  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 >>>> >>>> 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.
Right. brain fart! the forces are balanced if the "balloon" isn't expanding or contracting.
> >> 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. >
On 8/16/2020 2:13 AM, Ricketty C wrote:
> 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.  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 >>>> >>>> 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. >
Yeah, don't see what else it could be I guess when it's entirely powered by the air supply. If the PID is controlling pressure tho and what you're actually measuring is pressure differential the thought occurred to me, if you just set it to what the pressure is supposed to be during the main portion of the inhale to get the volume and let the PID "do its thing" what happens if for some reason the patient starts actively pushing back while it's ramping up does the PID read this as "pressure too low" and start trying to force it in harder? and then they stop and it can overshoot? I mean I guess they'd be sedated so that might be unlikely
On 8/16/2020 3:02 AM, bitrex wrote:
> On 8/16/2020 2:13 AM, Ricketty C wrote: >> 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.  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 >>>>> >>>>> 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. >> > > Yeah, don't see what else it could be I guess when it's entirely powered > by the air supply. > > If the PID is controlling pressure tho and what you're actually > measuring is pressure differential the thought occurred to me, if you > just set it to what the pressure is supposed to be during the main > portion of the inhale to get the volume and let the PID "do its thing" > what happens if for some reason the patient starts actively pushing back > while it's ramping up does the PID read this as "pressure too low" and > start trying to force it in harder? and then they stop and it can > overshoot? I mean I guess they'd be sedated so that might be unlikely
It sounds to me like for pressure-control there has to be a well-defined time where the pressure is ramped up while ensuring the volume of air in the patient's lungs is increasing linearly (or however it's supposed to do), however you do that, and then when the pressure set point is reached which will deliver the needed volume if it's kept there for the rest of the cycle the PID kicks in to hold it there by squeezing harder on the source-bag while it empties If I'm understanding your setup correctly
On 8/16/2020 3:22 AM, bitrex wrote:
> On 8/16/2020 3:02 AM, bitrex wrote: >> On 8/16/2020 2:13 AM, Ricketty C wrote: >>> 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.  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 >>>>>> >>>>>> 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. >>> >> >> Yeah, don't see what else it could be I guess when it's entirely >> powered by the air supply. >> >> If the PID is controlling pressure tho and what you're actually >> measuring is pressure differential the thought occurred to me, if you >> just set it to what the pressure is supposed to be during the main >> portion of the inhale to get the volume and let the PID "do its thing" >> what happens if for some reason the patient starts actively pushing >> back while it's ramping up does the PID read this as "pressure too >> low" and start trying to force it in harder? and then they stop and it >> can overshoot? I mean I guess they'd be sedated so that might be unlikely > > It sounds to me like for pressure-control there has to be a well-defined > time where the pressure is ramped up while ensuring the volume of air in > the patient's lungs is increasing linearly (or however it's supposed to > do), however you do that, and then when the pressure set point is > reached which will deliver the needed volume if it's kept there for the > rest of the cycle the PID kicks in to hold it there by squeezing harder
Er, reverse that, I think you said it squeezes less hard as you approach the end of the stroke to keep pressure constant.
On 8/16/2020 12:01 AM, Ricketty C wrote:
> 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. >
In the electrical analogy it sounds more like the squeeze-bag is the RC system, with an "output resistance" that varies with respect to the volume of air (charge?) in the bag. And the lung model is something that produces a "back EMF" (pressure) against it proportional to A*I + B*dI/dt (What's I? flow rate?) and the goal of the PID is to keep the mass flow rate (current) constant during the main portion of the inhale cycle
On a sunny day (Sat, 15 Aug 2020 22:46:45 -0700 (PDT)) it happened Ricketty C
<gnuarm.deletethisbit@gmail.com> wrote in
<d2d879c1-cf13-42f8-9727-8ef27dc2dc65o@googlegroups.com>:

> >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.
No experience with these things but from _my_ life I know breathing is related to oxygen level in the blood. For example, when I try biking very fast I need deeper and more often breathing than when I am pressing buttons on a mouse or keyboard and sitting still. In the 'overall loop' one should measure oxygen level in the blood and based on that pump more or less air, there is where your loop is. Compare it to those funny thermostats mounted outside that control the heating inside I have seen those, never the correct temperature inside... Measure where you want it controlled, not somewhere else. I would not want to be on a machine that without the oxygen level feedback was just pumping me, could be vary dangerous. Very important with people with covid-19 related changing lung damage.
On Sunday, August 16, 2020 at 3:02:23 AM UTC-4, bitrex wrote:
> On 8/16/2020 2:13 AM, Ricketty C wrote: > > 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. > > > > Yeah, don't see what else it could be I guess when it's entirely powered > by the air supply.
The difference is what is controlled. There's no reason why the pressure could not be controlled and then timed or still work off the volume. In fact, it seems to me the flow rate controlled system *could* be timed to get an accurate volume while the pressure controlled system will produce a variable volume depending on the patient parameters. There's still a lot missing.
> If the PID is controlling pressure tho and what you're actually > measuring is pressure differential the thought occurred to me, if you > just set it to what the pressure is supposed to be during the main > portion of the inhale to get the volume and let the PID "do its thing" > what happens if for some reason the patient starts actively pushing back > while it's ramping up does the PID read this as "pressure too low" and > start trying to force it in harder? and then they stop and it can > overshoot? I mean I guess they'd be sedated so that might be unlikely
You just said the pressure is controlled. So it won't "push back harder". That would be the flow controlled system in which the pressure will vary according to the patient parameters - spring and dashpot and of course if he is awake, breathing back against the machine. "Assist" means the patient is awake. This is the mode the "amateur" systems seldom tackle, so we are adding that. Sometimes I just want to hit my head on the floor. The guy adds a very demanding mode after much of the design is supposedly done and still wants to push for getting it done quickly because people are getting tired of working on this. This sort of inconsistency is rife in this project. I wanted to get rid of the ten cent thermistor (that's about 1 and 6 old currency) for a linear device that cost a dime. People were complaining about the cost. Mean while we have $100 in sheet metal, a $30 motor and gear train, three $20 pressure sensors and a $30 O2 sensor! They don't want me to use parts that do a better job if they aren't in inventory in the ten thousands, but the pressure sensors are hardly stocked anywhere. Now we are trying to pick a new motor and the one they picked can trash the gears if run against a stop. The currents at the max peak rating and the max continuous rating are so close that the inaccuracies in the current sensor in the motor controller are larger. So many things would have been worked out had we done a proper requirements analysis. The first two sets of boards are not functional enough to verify circuits work like the battery charger (I think the input voltage is too low to fully charge the battery as the charging chip is designed - Vboost is 14.6, Vin is nominally 15V but there's tolerance - not to mention drop out voltage!). Still, they are rushing to get the next rev of the board done. The last couple weeks I've been wanting to walk away, but I'd like to get through a design review on the board. I asked to add hysteresis to the alarm comparators (fully hardware, no software) and provided an LTspice schematic which had been verified in simulation. The schematic has negative feedback instead of positive. I know, I know, I'm whining at this point. Thanks for listening. -- Rick C. ++ Get 1,000 miles of free Supercharging ++ Tesla referral code - https://ts.la/richard11209
s&oslash;ndag den 16. august 2020 kl. 16.31.14 UTC+2 skrev Jan Panteltje:
> On a sunny day (Sat, 15 Aug 2020 22:46:45 -0700 (PDT)) it happened Ricketty C > <gnuarm.deletethisbit@gmail.com> wrote in > <d2d879c1-cf13-42f8-9727-8ef27dc2dc65o@googlegroups.com>: > > > > >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. > > No experience with these things > but from _my_ life I know breathing is related to oxygen level in the blood.
not really, your breathing is mostly related to the amount of CO2 in your lungs that's why breathing something like pure nitrogen will kill you without you even noticing
On Sunday, August 16, 2020 at 3:22:34 AM UTC-4, bitrex wrote:
> On 8/16/2020 3:02 AM, bitrex wrote: > > On 8/16/2020 2:13 AM, Ricketty C wrote: > >> 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.&nbsp; 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.&nbsp; Everything has pressure from > >> the atmosphere.&nbsp; That's why pressure in most cases is relative, not > >> absolute.&nbsp; So that's simply not an issue.&nbsp; The balloon is elastic, > >> that's why they require pressure to inflate.&nbsp; 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).&nbsp; 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.&nbsp; The flow is constant, so the > >> pressure increases from the elastic effect until the volume is > >> achieved and the exhale begins. > >> > > > > Yeah, don't see what else it could be I guess when it's entirely powered > > by the air supply. > > > > If the PID is controlling pressure tho and what you're actually > > measuring is pressure differential the thought occurred to me, if you > > just set it to what the pressure is supposed to be during the main > > portion of the inhale to get the volume and let the PID "do its thing" > > what happens if for some reason the patient starts actively pushing back > > while it's ramping up does the PID read this as "pressure too low" and > > start trying to force it in harder? and then they stop and it can > > overshoot? I mean I guess they'd be sedated so that might be unlikely > > It sounds to me like for pressure-control there has to be a well-defined > time where the pressure is ramped up while ensuring the volume of air in > the patient's lungs is increasing linearly (or however it's supposed to > do), however you do that, and then when the pressure set point is > reached which will deliver the needed volume if it's kept there for the > rest of the cycle the PID kicks in to hold it there by squeezing harder > on the source-bag while it empties > > If I'm understanding your setup correctly
That sounds right but not "harder". The vent bag does not have much "spring" to it, just enough to reinflate it. In fact, because of the geometry, contact with the bag is over a smaller area at first and as that area expands during the stroke the area of the "piston" effectively increases. We are using about half the volume of the bag, so will need to press on it about three quarters of a stroke I estimate. So if the arm moves at a constant rotation the graph of flow rate vs position will be roughly a triangle. -- Rick C. --- Get 1,000 miles of free Supercharging --- Tesla referral code - https://ts.la/richard11209
On Sunday, August 16, 2020 at 10:31:14 AM UTC-4, Jan Panteltje wrote:
> On a sunny day (Sat, 15 Aug 2020 22:46:45 -0700 (PDT)) it happened Ricketty C > <gnuarm.deletethisbit@gmail.com> wrote in > <d2d879c1-cf13-42f8-9727-8ef27dc2dc65o@googlegroups.com>: > > > > >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. > > No experience with these things > but from _my_ life I know breathing is related to oxygen level in the blood. > For example, when I try biking very fast I need deeper and more often breathing > than when I am pressing buttons on a mouse or keyboard and sitting still. > In the 'overall loop' one should measure oxygen level in the blood > and based on that pump more or less air, there is where your loop is. > Compare it to those funny thermostats mounted outside that control the heating inside > I have seen those, never the correct temperature inside... > Measure where you want it controlled, not somewhere else. > I would not want to be on a machine that without the oxygen level feedback was just pumping > me, could be vary dangerous. > Very important with people with covid-19 related changing lung damage.
Your post is very confusing. If the heat comes on so hard it sets the house on fire, maybe you should have a controller that prevents that even if the bedroom is not quite warm enough. The vent is concerned with getting air into the lungs without causing damage to the lungs. Setting the volume goals of the machine is up to the operator who is monitoring the patient's O2 levels. If there is a problem with getting the O2 from the air in your lungs into your blood stream, perhaps you would not want a person monitoring the machine and just allow it to inflate your chest like a balloon causing embolisms and death. The machine controls aspects that are appropriate for the machine to control. More complex factors are controlled by a trained human. I appreciate that you have designed many control systems and I value your input. But you don't understand the problem fully. -- Rick C. --+ Get 1,000 miles of free Supercharging --+ Tesla referral code - https://ts.la/richard11209