PID Controller Design for Ventilator...

[Ricketty C]

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

 

[bitrex]

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/>

 

[Don Y]

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

 

[Ricketty C]

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

 

[bitrex]

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

..

 

[bitrex]

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!

 

[bitrex]

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.

The early hydro-mechanical ventilators were back-pressure regulated;
when back-pressure reaches a set point the exhale cycle is triggered.

 

[Ricketty C]

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.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

 

[Ricketty C]

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

 

[Ricketty C]

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?

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

 

[bitrex]

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.

 

[bitrex]

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

 

[bitrex]

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

 

[bitrex]

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.

 

[bitrex]

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

 

[Ricketty C]

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

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

 

[Lasse Langwadt Christensen]

sø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

 

[Ricketty C]

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

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

 

[server]

On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

sø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

I wonder how many old ladies ricky\'s team plans to kill, trying to
learn PIDs and stuff.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Ricketty C]

On Sunday, August 16, 2020 at 11:14:22 AM UTC-4, jla...@highlandsniptechnology.com wrote:

On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

sų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

I wonder how many old ladies ricky\'s team plans to kill, trying to
learn PIDs and stuff.

Perhaps you will be the first little old lady? Care to volunteer?

I love the fact that Larkin tells others to ignore me but can\'t resist reading and responding negatively himself!

Yeah, that\'s a great community spirit. I\'m glad Larkin is pulling for us all. At least he isn\'t making a personal attack like he criticizes others for... no, wait, he is!

I would ask your opinion, but you have made it very, very clear that you don\'t actually understand the math of controllers, you just whip up a simulation and you are off to the races.

I may well do that myself, but only after understanding the lung/air way model well enough to be sure the simulation is modeling something useful.

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209