PID Controller Design for Ventilator

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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 er
ror?  

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 press
ure measurement.  

One issue I'm seeing discussed is a tradeoff on the PWM resolution vs. freq
uency.  Presently they are using 3.6 kHz with 8 bit PWM control.  I kinda w
onder if a sigma-delta might be better, but that might require some externa
l logic.  They seem to be shy of pushing the CPU too much even after changi
ng 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 exhal
e and inhale.  In general, would it be better to simply jump the pressure s
et point at once and let the PID controller do its thing, optimizing the re
sponse time as best as possible controlling overshoot -or- would it be bett
er 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 a
s a capacitor) in parallel with a dissipative element (a dashpot or resisto
r 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 rest
riction.  So initially the dominate opposition to flow will be the dissipat
ion/resistor, i.e. proportional to the rate of airflow.  This in turn is pr
oportional to the arm speed (although not constant through the stroke due t
o the bag geometry).  The arm speed is what is controlled by the PWM (appro
ximately).  

The lung model shows the dashpot and spring in parallel, but I'm not sure t
hat's appropriate.  The response to air entering the lung will be the sum o
f the airway resistance (dashpot) and the lung compliance (spring) which wo
uld be a series combination to obtain the resulting air pressure.  Well, ma
ybe that is right for the mechanical model, but in the electrical equivalen
t 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 flo
w regulated cycles.  I expect to see similar results with either method.  
  

Interesting

--  

  Rick C.

  - Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: PID Controller Design for Ventilator
On 8/15/2020 9:44 PM, Ricketty C wrote:
Quoted text here. Click to load it

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/

Re: PID Controller Design for Ventilator
On 8/15/2020 6:44 PM, Ricketty C wrote:
Quoted text here. Click to load it

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"?)

Quoted text here. Click to load it


Re: PID Controller Design for Ventilator
On Saturday, August 15, 2020 at 11:07:10 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it
ing
d
that
ome
fter
xhale
 set
Quoted text here. Click to load it
e
ld
is as
tor
t arm
n
e
y the
re
sum
ch
ll,
iven
ta
set
 flow
Quoted text here. Click to load it

First, no, the current to the motor is not controlled, the voltage is contr
olled.  

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 mot
or PWM drive controls the force on the bag which to a first approximation i
s 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 arrange
ment.  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 overwhel
med by it all.  

--  

  Rick C.

  + Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: PID Controller Design for Ventilator
On 8/16/2020 12:01 AM, Ricketty C wrote:
Quoted text here. Click to load it

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

Re: PID Controller Design for Ventilator
On Sunday, August 16, 2020 at 3:57:04 AM UTC-4, bitrex wrote:
Quoted text here. Click to load it
thing
and
m that
.
 I
Quoted text here. Click to load it
 some
Quoted text here. Click to load it
 after
Quoted text here. Click to load it
 exhale
Quoted text here. Click to load it
re set
 be
Quoted text here. Click to load it
ould
this as
istor
ght arm
e
 in
Quoted text here. Click to load it
the
 by the
Quoted text here. Click to load it
sure
e sum
hich
Well,
driven
data
e set
nd flow
.
ontrolled.
ant 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 approximati
on is the pressure in the bag.  It will vary some through the stroke becaus
e 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.
Quoted text here. Click to load it
angement.  Initially the counter force is all dissipative (air flow resista
nce) and the effect of the capacitor (lung elastance) is minimal in compari
son.  As the lung inflates the elastance becomes a larger factor.
Quoted text here. Click to load it
tion of the control variable.  That would seem to be dominated by proportio
nal effects.
Quoted text here. Click to load it
  If you have questions I would be happy to answer, but you seem to be over
whelmed by it all.
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

In your equations I would be the mass moved.  I would consider the equation
s to be a spring constant A times the integral of the flow rate to give pre
ssure and the airways would provide a direct result of B*I to give pressure
.  

I can't find the post now, but I thought you had pointed out that a system  
could oscillate if there were enough time delay in the loop.  If the only t
ime delay were the sample cycle - take a sample, process to a response, imp
ose that response on the system, take another sample, etc., then the freque
ncy of ringing would be 1/Tsample, no?  This is assuming there is no elemen
t in the system that is a derivative of the flow rate.  The "plant" won't o
scillate on its own.  

The data I saw showed periods of oscillation of maybe 100ms which would be  
100 sample times.  

--  

  Rick C.

  +-+ Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: PID Controller Design for Ventilator
On 8/15/2020 9:01 PM, Ricketty C wrote:
Quoted text here. Click to load it

Gee, silly me!  I'd have thought you'd have driven the mechanism with a
FORCE necessary to overcome the losses in the mechanism and not exceed the
patient's airway capability.  Let the motor attain whatever SPEED it
needs to use up that available current and do so at a rate limited
by it's -- and the mechanism's - dynamics... without being hindered
by the control loop's performance.

[You do realize you'll have to ensure you don't command the motor to
change speed faster than it/mechanism can support?  Otherwise your
analysis of the control system will fall apart]

Quoted text here. Click to load it

Because they ALWAYS are when there's anything more than a "motorshaft with
an encoder on it".  Mechanisms and 'real world applications" invariably
introduce lag.  Lag leads to oscillation -- or, highly overdamped tuning.

Quoted text here. Click to load it

Which means you're likely missing many of the "little things" that will
conspire to make tuning harder and loop performance far from ideal.
I.e., why have a loop if you don't expect to GAIN something from it?

You have some capture delay for the sensed variable.  If it's a flash  
converter, that can be near instantaneous.  But, in practice, there's
likely some signal conditioning in front that limits the sensor's
response (adds delay).

There's the location of the sensor wrt the actuator.  (Also, wrt the
actual field variable).  You're inevitably measuring something that
isn't the same (instantaneous) thing as what you are controlling/influencing.
(And, isn't really the same as the field variable that you REALLY
want to be dealing with!)

There's some delay in bringing about the actuator's action.  Some
of this is related to the drive interface while some is inherent
in the capabilities (limitations) of the actuator.  The mechanism
coupling the actuator to the process may have nonlinearities and
delays (backlash in gearboxes is a common foe).

There's a delay in the processing required to decide how to
drive the actuator, "now".

How each of these respond over their operating ranges and within
a particular "cycle" need to be analyzed BEFORE you can dismiss them
as being irrelevant (*if* you can dismiss them).  Otherwise, you'll
scratch your head wondering why the loop performs like crap.

Quoted text here. Click to load it

And the "lung" will vary from one individual to the next.  Concentrate on
the things you have control over, first -- the product's design.  If there
are variables in its performance, figure out how to compensate for them
BEFORE you add the variable that is the "lung" (or, the provider operating
the device!)

Quoted text here. Click to load it

(sigh)  True to form, you underestimate the complexity of the problem and
dismiss folks who have experience solving similar problems because they
say things that you don't want to hear (e.g., FDA approval process) or
ask questions that you can't answer ("That's not important").

[The FDA process would have told you that you should PROVE those things to
be unimportant -- instead of hand-waving them away in "first-order
approximations".]

Classic example of Dunning-Kruger Effect.

If I said I've designed and implemented 50 PID loops, I'd probably be low by
a factor of 5!  And, yours is "trivial", by comparison!  It's not interacting
with 6 or 7 other loops, simultaneously.

For example:

Noticing a higher than desired ejection force for a tabletting station (35-75
in operation concurrently) would lead the associated controller to move the
formation of the tablet *up* in the die.  This requires updating the upper
punch penetration and lower punch penetration settings (mechanisms!)
in-synchrony to ensure the distance between punch tips remains unchanged.
(heaven forbid you let the punch tips TOUCH -- crunch!).  Of course, the
mechanisms for each are different so the mechanical gains and dynamics of
their mechanisms differ.  I.e., the control loops governing their "positions"
(at the end of motorized mechanisms; revolutions becomes tenths of thousandths
of inches) differ and can't be assumed to travel (adjust) at identical rates.

Less distance to travel between it's formation and ejection AND likely out of
any "barreled" portion of the die (even steel wears when subjected to 10T
events at 200Hz day in and day out).

Ah, but that means EVERY tabletting station will now form a tablet at that
new displacement!  (And, stations are forming tablets WHILE THE PUNCHES
PENETRATIONS ARE "IN MOTION"!)  What if some other station NOW exhibits a
higher ejection force?  Do you move the tablet up even further in the die?
Do you ignore the "problem"?  Coerce the previous station to tolerate a
compromise position?

How many tablets do you end up discarding for each tradeoff?  When do you
halt the process and signal the operator to change the tooling (punches/die)
because the process has moved out of your control region?

While the punches are in motion, tablets are being formed.  The forces they
experience in their formation is approximately (nonlinearly!) related to the
weight (mass) of the tablet thus formed.  This is intuitive -- a "fixed"
amount of material being compressed to a particular "final size".

So, if there is any variation between punch-tip-to-punch-tip distance WHILE  
UNDER ADJUSTMENT, it manifests as "weight variation" (though you can't deduce
whether a high force means an overweight tablet or an underweight tablet
because you don't know the dimensions of the actual tablet!).

So, the control loop that adjust the amount of material to install in each
die sees that it needs to compensate (even though it might be operating
at the ideal point IF THE PUNCHES HAD SETTLED INTO THEIR CORRECT PLACES).
As a result, it alters the fill -- and, thus, weights -- of the other
tabletting stations that haven't experienced this disturbance -- yet!

I.e., the loop can make WORSE product than if it hadn't been in place!
[Do you remember that threee-letter agency, begins with an F?]

As the tablet is formed higher in the die, there is increased opportunity
for material ("tablet powder... 'granulation') to incompletely fill the
die (it is gravity fed).  This will likely affect ALL tabletting
stations so you want to pool the observations of all of the control
loops before deciding that you have a "fill problem".

If so, you tweek the setpoint of the hopper controllers -- which then
feeds back into the mechanical processing of all of the tabletting
stations served by that hopper (typically two hoppers per machine).

All of these changes affect real physical characteristics of the
tablets produced:  weight, hardness, friability, dissolution time,
etc.

Thus, there are "offline" tests performed by manufacturing staff to
test these parameters and tweek the press based on their results.
But, these tests often take on the order of minutes or fractional
hours... the machine is no longer in the same configuration it
was when the tablets sampled were produced!

So, you have to keep track of which tablets were actually sampled,
along with the observations made during their formulation, in
order to apply the desired corrections to the CURRENT process.

This is ONE product.  With *dozens* of interacting control loops
manufacturing product (at 200 completed items per second) for a
regulated (FDA) industry.

Would you like to discuss using control theory to assist in
autopilot navigation?  Or, controlling temperature/humidity/flow
in a process air handler?  Or controling the intensity of a lamp
to ensure it accurately detects the "color" of a blood assay?
Or, controlling the formulation of a "candy shell" on a small,
oval piece of chocolate??  :>

But, hey, I'm clearly "overwhelmed" by a paddle pushing on an Ambubag.

Yeah, that.

Re: PID Controller Design for Ventilator
On Sunday, August 16, 2020 at 4:32:20 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it

Good thing I've considered all the above which I believe in every case is trivial and not a factor that needs any special consideration.  


Quoted text here. Click to load it

You are showing your ignorance of the situation.  There is a trained operator to specifically address issues like differences between patients.  It is not up to the machine to magically know the characteristics of the patient it is connected to.  


Quoted text here. Click to load it

Are you offering to participate in the PID design for this product?  

--  

  Rick C.

  --- Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: PID Controller Design for Ventilator
On 8/16/2020 5:54 PM, Ricketty C wrote:
Quoted text here. Click to load it

Hell no.  It looks like a doomed project.  I donate my 500+ /pro bono/ hours,
annually (for the past 20+ years) to projects where I know I (and they) can
do some good.

[OTOH, I'm not entirely altruistic in my choice of projects!  I
deliberately pick projects -- and their solutions -- that I can use
to learn about some technology that is of interest to me, at the time.
The last two projects allowed me to experiment with unattended RDBMS
management techniques and self-modifying -- learning -- Expert Systems.]

I'm merely suggesting why you've missed the boat on how to approach
the *process* and the design -- PID and otherwise.

Get a good book on control system *theory*.  Read it.  Understand it.
It's "old news" but many schools don't include it in their REQUIRED
curricula.  What's changed is the move to sampled systems instead of
continuous and electronic/smart control vs. pneumatic/etc. controls.
E.g., Ziegler-Nichols tuning was devised in the 40's!  The more
practical idea of applying it (and variants) to "self-tune" is more
modern.

(No need to bother yourself with more esoteric things like SPC).

Then look for "control theory for dummies" examples on the web.
There are also modeling tools available, nowadays, that let you PLAY
with "systems" to see what they will do in certain circumstances.
You can see why the systems behave the way they do and "where"
the "issues" creep into the models.

There are myriad approaches to "solving" these issues that have been
developed over the years.  Often very specific to particular
application domains.  (e.g., how do you control the temperature
in a process vessel where the "worker" can periodically open the
vessel -- for whatever reason -- and introduce a large disturbance
to your controller?)

You can use these -- and the Genuine Article -- to see how close your
model is to reality.  And, evaluate remedial measures to compensate
for exposed shortcomings.

Instead of asking how the system will respond to a step function,
apply one to the model and WATCH.  Use this understanding of the
system (as modeled) to JUSTIFY why your control algorithm is
"suitable" (to the regulators).


Re: PID Controller Design for Ventilator
On a sunny day (Sun, 16 Aug 2020 13:32:06 -0700) it happened Don Y

..sniped good stuff...

Quoted text here. Click to load it


It is a fun subject, not so different from driving a rudder in a ship,
been playing with that with steppers,  *immediate response!*
 http://panteltje.com/panteltje/xgpspc/index.html
 scroll down to the pictures of the ballscrew in the vice...
Not saying that is the perfect solution but great to experiment with.
The cost issue in my view should not count for life saving equipment.
Mass production will bring it down anyways,

In my view it is better to design something great, there must be many cheap ones already.
I am sure they have now many of those in China.
And in the end it will have to be tested on real people, starting with the  
designers of course! ;-)
It is something for J. Larkin iterative design!
?

Re: PID Controller Design for Ventilator
On 8/16/2020 11:47 PM, Jan Panteltje wrote:
Quoted text here. Click to load it

Do you drive the motor at a constant step rate?  Or, do you try to
accelerate it to a higher speed?  (I assume most of your actions
are incremental and not "severe")

Quoted text here. Click to load it

Yikes!  Quite an ambitious project!

I designed a LORAN-C -based autopilot ~45 years ago.  Instead of
maintaining course, you specified "destinations" (up to 9, in sequence)
using latitude and longitude (instead of time-differences).  It would
navigate the vessel to each, in order, compensating for drift (cross
currents) that it encountered.  So, you ended up with a straight course
from A directly to B (as long as the vessel could make progress
INTO the current -- think of degenerate case where destination is
directly up-current from your present position)

We circumnavigated Cape Cod on our test voyage -- without touching the wheel.

[minor lie... we stopped for some deep sea fishing off the northeast
coast of the Cape for an hour or two -- catching several Blue Fish.
Sadly, this stop took us off "automatic control" and relied on the
skipper to keep turning the vessel back "into the waves" lest it
rock too severely (boats want to align themselves with the incoming
waves, otherwise).  So, the plot of our trip has a huge "anomaly"
in the otherwise perfect record of our travel!]

Quoted text here. Click to load it

Ball screws are absolutely amazing devices!  They seem to defy the rules
of physics (of course, the reason they work as they do is obvious... but,
if you've never physically played with one, it's a really unique experience!)
I used one in a tablet hardness tester.

Quoted text here. Click to load it

The problem is not with the "cost".  Most medical devices are relatively
low *cost* to produce.  But, they are *priced* rather high to cover all
of the liability, regulatory compliance and "no one wants to buy something
that they perceive as 'cheap'".  Would you buy a $19.95 pacemaker??  :>

[I've designed devices with $300 costs that sold for $6K+]

Quoted text here. Click to load it

Sadly, I don't think many designers ever ROUTINELY use any of their products.
I once saw a device I designed in a retail store and couldn't stop
laughing -- I had to buy one just to have one in its "retail packaging"!

Quoted text here. Click to load it

"Hmmm... THAT one died, too!  Next?!"

Re: PID Controller Design for Ventilator
Quoted text here. Click to load it

Good trick! A bit hard on the keel though. ;)

"Faith, he tonight hath boarded a land carrack. If it prove lawful prize, he's made for ever." --Iago

Cheers

Phil Hobbs

Re: PID Controller Design for Ventilator
On 8/17/2020 5:38 AM, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

Not at all!  There is a water path entirely around the Cape.
The Cape Cod Canal effectively turns the Cape into an island.

And, owing to the narrowness of the land mass, there are many places where
you could portage it in less than half a mile.

Re: PID Controller Design for Ventilator
On 8/17/2020 6:39 AM, Don Y wrote:
Quoted text here. Click to load it

A view from the north/east end of the canal.  In the distance,
you can see the south end of the canal emptying into Buzzard's bay.
The "Cape" occupies the left side of the photo while the "mainland"
occupies the right.

<
https://en.wikipedia.org/wiki/File:CapeCodCanalEastEndAerial.jpg


Re: PID Controller Design for Ventilator
On 2020-08-17 09:39, Don Y wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

You didn't touch the wheel even going through the canal?

Cheers

Phil Hobbs

--  
Dr Philip C D Hobbs
Principal Consultant
We've slightly trimmed the long signature. Click to see the full one.
Re: PID Controller Design for Ventilator
On a sunny day (Mon, 17 Aug 2020 00:38:18 -0700) it happened Don Y

Quoted text here. Click to load it
:-)


Yes, this reminds me of the first test with xgpspc
On the ocean captain said: Now let's test Jan Pantetje's auto-pilot.
I was happy I got the chance, we had been for weeks on 4 hours on 4 hours off
using auto-pilot would give us all some much needed sleep.
So I fired up the raspberry and we all went to our cages.
Had some much needed sleep, but woke up
because the boat was moving in a peculiar way.
Number 1 was also awake now and we wondered if we drifted of course
Switched on the monitor, there was the message 'no satellites' on the screen
realized the beeping sound we heard all night was not from the wind whistling
but an heading alarm.

Now as most of you know who have a globe when at lower than 45 degrees north
the angle gets steeper, and there is a risk you fall off.
Anyways where were we now? it was dark and did see no north star,
just a bunch of small satellites moving across the sky
I immediately knew it was a new bunch of SpaceX sats ..
Grabbed the good old sextant
 http://panteltje.com/pub/davis_sextant_IMG_6556.JPG
but could not get a fix.
The compass was moving in a strange way, always pointed at the captain
I asked 'cap, do carry anything magnetic with you?'
'Oops'. cap said, 'I bought this set for my grandkids'
 https://www.supermagnete.de/eng/magnet-sets/set-114_Z-04
I remembered that song
 
https://www.youtube.com/watch?v=PxYU7A6qCnc

water around us had bubbles, ship was laying deep...
Where are we? Asked the little shipmate to turn down the radio..
'No' he said, 'Bermuda radio has great music'.
OK, Bermuda, the triangle, I have read that gas bubbles form under water
making the upwards pressure lower so that would explain something.
Captain was having some fish on deck when a tentacle appeared from behind
him and grabbed first the fish, and then pulled cap into the depth.
I screamed 'man overboard' and we started maneuvering to get cap back.
More tentacles appeared and grabbed the boat, some with sucking things on them.
So what can you do? switched on the radio and called 'Day in May Day In May'
US coast guard replied 'who are you?'
Then 'Where are you?'
'Bermuda I think' I answered, the reply was that they needed a more precise location specified.
OK, now what? I still had some pizza left from the night before and started feeding it to the octopus
 https://en.wikipedia.org/wiki/Giant_Pacific_octopus
it seemed to like it, took the whole plate, said 'thank you ' burbed, and disappeared.
Immediately a submarine surfaced next to us and threw us a line, moments later we were
imprisoned ..
Luckily it was a nuclear sub, unmarked, so at night I shorted the cipher lock on our cage
made my way to the reactor and connected my raspberry to it.
Just a short script  and inertial navigation took us back home into Amsterdam.
 
https://www.youtube.com/watch?v=ASYlAnI-wEg

We disconnected the raspi, stepped on land, send the sub back.
Our little boat was also there, the captain replaced by the octopus.
I bought some fresh pizza for it.
It was grateful, and gave me the plutonium it pilfered from the sub in return.
  

Re: PID Controller Design for Ventilator
On 8/15/2020 9:44 PM, Ricketty C wrote:
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

.

Re: PID Controller Design for Ventilator
On 8/16/2020 12:20 AM, bitrex wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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!

Re: PID Controller Design for Ventilator
On Sunday, August 16, 2020 at 12:32:46 AM UTC-4, bitrex wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  

ol.  
Quoted text here. Click to load it

CPU  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  

 the  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
s  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
,  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
s  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load 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
We've slightly trimmed the long signature. Click to see the full one.
Re: PID Controller Design for Ventilator
On 8/16/2020 1:47 AM, Ricketty C wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

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.


Site Timeline