PID Controller Design for Ventilator...

[Ricketty C]

On Monday, August 17, 2020 at 12:53:25 AM UTC-4, Flyguy wrote:

On Sunday, August 16, 2020 at 5:56:53 PM UTC-7, Ricketty C wrote:
On Sunday, August 16, 2020 at 7:12:06 PM UTC-4, Flyguy wrote:
On Saturday, August 15, 2020 at 6:44:08 PM UTC-7, 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

--

Rick C.

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

Here is a cheap, patented ventilator that doesn\'t need PID control (volume of air delivered is regulated mechanically by the angular motion of a cam):

https://foro.coronavirusmakers.org/uploads/516/FADE0V3E2AAI.pdf
The volume of air is not what is controlled by the PID.

--

Rick C.

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

Pressure is a dependent variable, not the controlled variable.

There are many good presentations on this topic available on the Internet. Try checking some out. It will be very educational.

--

Rick C.

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

 

[Ricketty C]

On Sunday, August 16, 2020 at 11:56:01 PM UTC-4, bitrex wrote:

On 8/16/2020 8:09 PM, Three Jeeps wrote:
On Sunday, August 16, 2020 at 11:45:57 AM UTC-4, Ricketty C wrote:
On Sunday, August 16, 2020 at 11:33:16 AM UTC-4, Lasse Langwadt Christensen wrote:
søndag den 16. august 2020 kl. 17.14.22 UTC+2 skrev jla...@highlandsniptechnology.com:
On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen
lang...@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.del...@gmail.com> wrote in
d2d879c1-cf13-42f8...@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.


I very much doubt they\'ll be allowed to hook anything living up to a ventilator hacked together by amateurs, no matter how well-meaning they are

seems like an exercise in feeling like they are \"doing something\"
There are a couple of companies we are talking to about running the design through a certification process and into manufacturing. So that will be covered. When we hit certain bumps in the road the solution is to not worry about it since the company taking it over will be redoing that anyway. This is not a rational to take technical shortcuts, more procedural things. So the documentation will be sparse I expect.

That is my single biggest issue with the process. They are not doing a proper requirements analysis. This means many aspects of the design are not planned out properly and various sections have been redesigned several times and may be again in the future as we find bends in the road.

Oh well, keeps me off the streets. I need to design a high side current monitor since the one in the motor controller has very poor accuracy. There is a nominal current ratio, but at lower currents the tolerance is worse than ±34%.

--

Rick C.

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

hmmm running it through certification process with \'documentation is rather sparse\'?
My suggestion is to get the documentation as it will be part of the assurance case that will be made to the FDA (or whoever). Ultimately, the FDA certifies the as-built system and will need to see proper design docs and *rational* that when reasoned about, can make the argument that the system will behave as required and is safe.
Understanding PID controllers is one thing. Writing a discrete version of the PID control law is something else. Understanding the system dynamics and developing is control loop goes beyond understanding a PID controller.
I know nothing about how a ventilator works. I do know a bit about developing control systems. From the number of posts and your \'wondering\' of what the control variable is, it sounds like one need to make a model of the system in order to better understand the components and linkages and develop a realistic transfer function. I am quite surprised that the system is characterized as a simple first order system.
For a voltage controlled DC motor the rotational speed/torque transfer function is first order. Closed loop control rotational speed/voltage is always a second order system - in fact, it is the quintessential example in any first control theory course. And there is a \'simplifying assumption\' - if one assumes the time constant of the electrical circuit is much smaller than the time constant of the load dynamics, the transfer function may be reduced to a first order transfer function. Not clear that this simplifying assumption is applicable in this case.

So, don\'t know the open loop transfer function of the system? run a frequency test and measure the response. Create a simulink model. Understand where the poles and zeros of the system are and determine the natural frequency of the system.
Once one understands what they are dealing with then one can think about an effective control approach...there is usually more to it than throwing a PID controller at the system.
Gee, what happens if noise gets coupled into the system? Does your design compensate for that (hardware and digitally) You should also consider doing stability analysis to see if your controlled introduced an oscillation.
With all due respect, this is not a design problem for amateurs (no insinuation about your skills or experience - just a lesson learned from spending lots of time in the control and certification domain (both FDA and Mil) ).



The simple hydro-mechanical ventilator + lung system is an oscillator,
is it not?

It\'s fed with energy from the compressed air supply, and it
chunk-chunk-chunks in and out like a steam engine.

So in even the simplest case I think the overall system of lungs + vent
has to be at least second order. Sure it can oscillate, that\'s what it\'s
supposed to do when the system is operating normally.

Sure, it will oscillate if you control it with an oscillator.

It is not supposed to oscillate when you try to ramp up the rising edge of the pressure. You talk about second order but you don\'t seem to actually understand it, you just sort of wave hands over it.

The spring and dashpot of the lung is the same as my car\'s suspension. That is not going to oscillate. The motor, arm and bag are actually a pretty simple system of move the motor arm and air moves out of the bag under pressure. The action of the motor inflating the lung is slow enough that with an adequately quick control loop there will be no overshoot, no ringing, no nothing. The control loop will runs tens of times faster than the edge rate of the pressure or flow rate, so the control loop will only be driven at frequencies much lower than it can deal with.

Whatever. I won\'t likely get a chance to work on the software. I will let them figure it out. It\'s not rocket science.

--

Rick C.

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

 

[Jan Panteltje]

On a sunny day (Sun, 16 Aug 2020 13:32:06 -0700) it happened Don Y
<blockedofcourse@foo.invalid> wrote in <rhc54e$m7e$1@dont-email.me>:

...sniped good stuff...

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

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!
?

 

[Don Y]

On 8/16/2020 11:47 PM, Jan Panteltje wrote:

On a sunny day (Sun, 16 Aug 2020 13:32:06 -0700) it happened Don Y
blockedofcourse@foo.invalid> wrote in <rhc54e$m7e$1@dont-email.me>:

..sniped good stuff...

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

It is a fun subject, not so different from driving a rudder in a ship,
been playing with that with steppers, *immediate response!*

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

> http://panteltje.com/panteltje/xgpspc/index.html

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!]

> scroll down to the pictures of the ballscrew in the vice...

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.

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,

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+]

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! ;-)

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\"!

> It is something for J. Larkin iterative design!

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

 

[server]

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

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

 

[Don Y]

On 8/17/2020 5:38 AM, pcdhobbs@gmail.com wrote:

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

Good trick! A bit hard on the keel though.

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.

 

[Don Y]

On 8/17/2020 6:39 AM, Don Y wrote:

On 8/17/2020 5:38 AM, pcdhobbs@gmail.com wrote:
We circumnavigated Cape Cod on our test voyage -- without touching the wheel.

Good trick! A bit hard on the keel though.

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

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>

 

[George Herold]

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.

Do you know any good control \'theory/practice\' books. I\'ve got a few, but
I tend to get a little lost in the Laplace transforms, And would
love something with a more \'hands on\' feel, an AoE type of book.

Tim Wescott\'s book is fine.
https://www.wescottdesign.com/actfes/actfes.html

George H.

--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Phil Hobbs]

On 2020-08-17 09:39, Don Y wrote:

On 8/17/2020 5:38 AM, pcdhobbs@gmail.com wrote:
We circumnavigated Cape Cod on our test voyage -- without touching
the wheel.

Good trick! A bit hard on the keel though.

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.

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

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Don Y]

On 8/17/2020 11:15 AM, Phil Hobbs wrote:

On 2020-08-17 09:39, Don Y wrote:
On 8/17/2020 5:38 AM, pcdhobbs@gmail.com wrote:
We circumnavigated Cape Cod on our test voyage -- without touching the wheel.

Good trick! A bit hard on the keel though.

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.

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

The skipper got nervous as there\'s \"traffic\" in the canal.
My autopilot can\'t \"see\" anything other than it\'s global position
so would merrily drive over/through any obstacles encountered
(boats, people, land masses, etc.).

[Note that I\'m doing this with a couple hundred bytes of RAM;
not an online digitized atlas!]

But, in theory, it could have navigated the canal. The current
in the channel flows in the same (or opposite) direction of
your travel (depending on whether flood or ebb). So, there\'s
nothing to *divert* you from your established course -- you\'re
just \"helped along\" or \"bucking the current\". All my device
has to do is point the craft in the correct direction! This
isn\'t the case in open water where the currents can come at
varying angles and intensities.

LORAN gives a positional fix to within ~50 ft in areas of low GDoP
(geometric dilution of precision). The 9960 chain is mastered off
Nantucket. So, the geometry is pretty good in that area:

<https://3.bp.blogspot.com/-s5mRwhXNNqY/XEymM6azcxI/AAAAAAAAMqY/zZTMbn-4ILoDbhVtS9rcsYnIgI_rkEBoQCLcBGAs/s1600/LoranChartBostonA.png>

as long as the receiver picks the \"right\" position for any given
pair of time-differences. LORAN\'s geometry is inherently ambiguous;
mapping two lat/lons to each pair of TDs -- really obvious in
this chart in and around the area of the baseline extension
(the BROWN dashed line radiating southwest from the Master at
Nantucket)

The canal is pretty wide so \"hitting it\" within 50 ft is not a problem.
We had no problem using it to exit and later return to the dock in
the harbor where we\'d left our (land) vehicles.

But, it\'s unclear we could have stayed in our \"lane\" when transiting
the canal (we were willing to foot the expenses for the day trip but
not keen on paying any fines or damages! :> )

[We managed to come within spitting distance of every buoy that we
used as a \"landmark\" (waypoint), along the way (though buoys move
with the tides)!]

 

[Three Jeeps]

On Sunday, August 16, 2020 at 9:09:08 PM UTC-4, Ricketty C wrote:

On Sunday, August 16, 2020 at 8:09:27 PM UTC-4, Three Jeeps wrote:
On Sunday, August 16, 2020 at 11:45:57 AM UTC-4, Ricketty C wrote:
On Sunday, August 16, 2020 at 11:33:16 AM UTC-4, Lasse Langwadt Christensen wrote:
søndag den 16. august 2020 kl. 17.14.22 UTC+2 skrev jla...@highlandsniptechnology.com:
On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen
lang...@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.del...@gmail.com> wrote in
d2d879c1-cf13-42f8...@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.


I very much doubt they\'ll be allowed to hook anything living up to a ventilator hacked together by amateurs, no matter how well-meaning they are

seems like an exercise in feeling like they are \"doing something\"
There are a couple of companies we are talking to about running the design through a certification process and into manufacturing. So that will be covered. When we hit certain bumps in the road the solution is to not worry about it since the company taking it over will be redoing that anyway. This is not a rational to take technical shortcuts, more procedural things. So the documentation will be sparse I expect.

That is my single biggest issue with the process. They are not doing a proper requirements analysis. This means many aspects of the design are not planned out properly and various sections have been redesigned several times and may be again in the future as we find bends in the road.

Oh well, keeps me off the streets. I need to design a high side current monitor since the one in the motor controller has very poor accuracy. There is a nominal current ratio, but at lower currents the tolerance is worse than ±34%.

--

Rick C.

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

hmmm running it through certification process with \'documentation is rather sparse\'?
My suggestion is to get the documentation as it will be part of the assurance case that will be made to the FDA (or whoever). Ultimately, the FDA certifies the as-built system and will need to see proper design docs and *rational* that when reasoned about, can make the argument that the system will behave as required and is safe.
Understanding PID controllers is one thing. Writing a discrete version of the PID control law is something else. Understanding the system dynamics and developing is control loop goes beyond understanding a PID controller.
I know nothing about how a ventilator works. I do know a bit about developing control systems. From the number of posts and your \'wondering\' of what the control variable is, it sounds like one need to make a model of the system in order to better understand the components and linkages and develop a realistic transfer function. I am quite surprised that the system is characterized as a simple first order system.
For a voltage controlled DC motor the rotational speed/torque transfer function is first order. Closed loop control rotational speed/voltage is always a second order system - in fact, it is the quintessential example in any first control theory course. And there is a \'simplifying assumption\' - if one assumes the time constant of the electrical circuit is much smaller than the time constant of the load dynamics, the transfer function may be reduced to a first order transfer function. Not clear that this simplifying assumption is applicable in this case.

So, don\'t know the open loop transfer function of the system? run a frequency test and measure the response. Create a simulink model. Understand where the poles and zeros of the system are and determine the natural frequency of the system.
Once one understands what they are dealing with then one can think about an effective control approach...there is usually more to it than throwing a PID controller at the system.
Gee, what happens if noise gets coupled into the system? Does your design compensate for that (hardware and digitally) You should also consider doing stability analysis to see if your controlled introduced an oscillation.
With all due respect, this is not a design problem for amateurs (no insinuation about your skills or experience - just a lesson learned from spending lots of time in the control and certification domain (both FDA and Mil) ).
I would love to do something more rigorous, but I can\'t even get them to do a proper requirements analysis. \"We don\'t have time.\" So instead we have a hardware \"check list\".

Yeah, I know. I think I\'ve already said I will stick around to get see that a design review is done on the next board rev, then I am out.

I did design a high side current sensor today. The motor controller has a current sensor circuit but at lower current the tolerance is terrible ±33%. The high side sensor should be within 5% even using 1% resistors throughout. I used a very small sense resistor to minimize voltage drop and the first amp stage drops that to a third, so a second amp is used to get to a 3V range. The amount of signal conditioning circuitry is adding up. We are also out of I/Os on the MCU. They are talking about needing to add LEDs for alarms, but no indication of how many or what color... oh, there are requirements for flash rate to indicate severity along with the color. I can get one I/O back from the interface to the battery charge chip and maybe another elsewhere. Two I/Os and an I2C chip will get you a lot more I/Os as long as you don\'t require them to set interrupts.

--

Rick C.

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

No time for analysis? Requirement issues are always around. Requirements creep can be deadly. How they manage that process is direct indication of how the project will turn out. Building a model of the system is an ideal way of determine where the requirements are missing/ambiguous/wrong.
You can pay me now or pay me later...unfortunately \'later\' may be when a person dies. Sounds like a bunch of clowns running (mangling) the project...(let me guess...\'just give it to the engineers, they will figure it out\' and the famous \'there is always a hero that pulls it out\')
One can\'t fix stupid....run away...fast.
J

 

[Jan Panteltje]

On a sunny day (Mon, 17 Aug 2020 00:38:18 -0700) it happened Don Y
<blockedofcourse@foo.invalid> wrote in <rhdc5m$j5k$1@dont-email.me>:

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!]

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.

 

[server]

On Tue, 18 Aug 2020 05:44:36 -0700 (PDT), Three Jeeps
<jjhudak4@gmail.com> wrote:

On Sunday, August 16, 2020 at 9:09:08 PM UTC-4, Ricketty C wrote:
On Sunday, August 16, 2020 at 8:09:27 PM UTC-4, Three Jeeps wrote:
On Sunday, August 16, 2020 at 11:45:57 AM UTC-4, Ricketty C wrote:
On Sunday, August 16, 2020 at 11:33:16 AM UTC-4, Lasse Langwadt Christensen wrote:
søndag den 16. august 2020 kl. 17.14.22 UTC+2 skrev jla...@highlandsniptechnology.com:
On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen
lang...@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.del...@gmail.com> wrote in
d2d879c1-cf13-42f8...@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.


I very much doubt they\'ll be allowed to hook anything living up to a ventilator hacked together by amateurs, no matter how well-meaning they are

seems like an exercise in feeling like they are \"doing something\"
There are a couple of companies we are talking to about running the design through a certification process and into manufacturing. So that will be covered. When we hit certain bumps in the road the solution is to not worry about it since the company taking it over will be redoing that anyway. This is not a rational to take technical shortcuts, more procedural things. So the documentation will be sparse I expect.

That is my single biggest issue with the process. They are not doing a proper requirements analysis. This means many aspects of the design are not planned out properly and various sections have been redesigned several times and may be again in the future as we find bends in the road.

Oh well, keeps me off the streets. I need to design a high side current monitor since the one in the motor controller has very poor accuracy. There is a nominal current ratio, but at lower currents the tolerance is worse than ±34%.

--

Rick C.

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

hmmm running it through certification process with \'documentation is rather sparse\'?
My suggestion is to get the documentation as it will be part of the assurance case that will be made to the FDA (or whoever). Ultimately, the FDA certifies the as-built system and will need to see proper design docs and *rational* that when reasoned about, can make the argument that the system will behave as required and is safe.
Understanding PID controllers is one thing. Writing a discrete version of the PID control law is something else. Understanding the system dynamics and developing is control loop goes beyond understanding a PID controller.
I know nothing about how a ventilator works. I do know a bit about developing control systems. From the number of posts and your \'wondering\' of what the control variable is, it sounds like one need to make a model of the system in order to better understand the components and linkages and develop a realistic transfer function. I am quite surprised that the system is characterized as a simple first order system.
For a voltage controlled DC motor the rotational speed/torque transfer function is first order. Closed loop control rotational speed/voltage is always a second order system - in fact, it is the quintessential example in any first control theory course. And there is a \'simplifying assumption\' - if one assumes the time constant of the electrical circuit is much smaller than the time constant of the load dynamics, the transfer function may be reduced to a first order transfer function. Not clear that this simplifying assumption is applicable in this case.

So, don\'t know the open loop transfer function of the system? run a frequency test and measure the response. Create a simulink model. Understand where the poles and zeros of the system are and determine the natural frequency of the system.
Once one understands what they are dealing with then one can think about an effective control approach...there is usually more to it than throwing a PID controller at the system.
Gee, what happens if noise gets coupled into the system? Does your design compensate for that (hardware and digitally) You should also consider doing stability analysis to see if your controlled introduced an oscillation.
With all due respect, this is not a design problem for amateurs (no insinuation about your skills or experience - just a lesson learned from spending lots of time in the control and certification domain (both FDA and Mil) ).
I would love to do something more rigorous, but I can\'t even get them to do a proper requirements analysis. \"We don\'t have time.\" So instead we have a hardware \"check list\".

Yeah, I know. I think I\'ve already said I will stick around to get see that a design review is done on the next board rev, then I am out.

I did design a high side current sensor today. The motor controller has a current sensor circuit but at lower current the tolerance is terrible ±33%. The high side sensor should be within 5% even using 1% resistors throughout. I used a very small sense resistor to minimize voltage drop and the first amp stage drops that to a third, so a second amp is used to get to a 3V range. The amount of signal conditioning circuitry is adding up. We are also out of I/Os on the MCU. They are talking about needing to add LEDs for alarms, but no indication of how many or what color... oh, there are requirements for flash rate to indicate severity along with the color. I can get one I/O back from the interface to the battery charge chip and maybe another elsewhere. Two I/Os and an I2C chip will get you a lot more I/Os as long as you don\'t require them to set interrupts.

--

Rick C.

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

No time for analysis? Requirement issues are always around. Requirements creep can be deadly. How they manage that process is direct indication of how the project will turn out. Building a model of the system is an ideal way of determine where the requirements are missing/ambiguous/wrong.
You can pay me now or pay me later...unfortunately \'later\' may be when a person dies. Sounds like a bunch of clowns running (mangling) the project...(let me guess...\'just give it to the engineers, they will figure it out\' and the famous \'there is always a hero that pulls it out\')
One can\'t fix stupid....run away...fast.
J

They should test it on themselves.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Tom Gardner]

On 18/08/20 15:29, jlarkin@highlandsniptechnology.com wrote:

On Tue, 18 Aug 2020 05:44:36 -0700 (PDT), Three Jeeps
jjhudak4@gmail.com> wrote:

On Sunday, August 16, 2020 at 9:09:08 PM UTC-4, Ricketty C wrote:
On Sunday, August 16, 2020 at 8:09:27 PM UTC-4, Three Jeeps wrote:
On Sunday, August 16, 2020 at 11:45:57 AM UTC-4, Ricketty C wrote:
On Sunday, August 16, 2020 at 11:33:16 AM UTC-4, Lasse Langwadt Christensen wrote:
søndag den 16. august 2020 kl. 17.14.22 UTC+2 skrev jla...@highlandsniptechnology.com:
On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen
lang...@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.del...@gmail.com> wrote in
d2d879c1-cf13-42f8...@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.


I very much doubt they\'ll be allowed to hook anything living up to a ventilator hacked together by amateurs, no matter how well-meaning they are

seems like an exercise in feeling like they are \"doing something\"
There are a couple of companies we are talking to about running the design through a certification process and into manufacturing. So that will be covered. When we hit certain bumps in the road the solution is to not worry about it since the company taking it over will be redoing that anyway. This is not a rational to take technical shortcuts, more procedural things. So the documentation will be sparse I expect.

That is my single biggest issue with the process. They are not doing a proper requirements analysis. This means many aspects of the design are not planned out properly and various sections have been redesigned several times and may be again in the future as we find bends in the road.

Oh well, keeps me off the streets. I need to design a high side current monitor since the one in the motor controller has very poor accuracy. There is a nominal current ratio, but at lower currents the tolerance is worse than ±34%.

--

Rick C.

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

hmmm running it through certification process with \'documentation is rather sparse\'?
My suggestion is to get the documentation as it will be part of the assurance case that will be made to the FDA (or whoever). Ultimately, the FDA certifies the as-built system and will need to see proper design docs and *rational* that when reasoned about, can make the argument that the system will behave as required and is safe.
Understanding PID controllers is one thing. Writing a discrete version of the PID control law is something else. Understanding the system dynamics and developing is control loop goes beyond understanding a PID controller.
I know nothing about how a ventilator works. I do know a bit about developing control systems. From the number of posts and your \'wondering\' of what the control variable is, it sounds like one need to make a model of the system in order to better understand the components and linkages and develop a realistic transfer function. I am quite surprised that the system is characterized as a simple first order system.
For a voltage controlled DC motor the rotational speed/torque transfer function is first order. Closed loop control rotational speed/voltage is always a second order system - in fact, it is the quintessential example in any first control theory course. And there is a \'simplifying assumption\' - if one assumes the time constant of the electrical circuit is much smaller than the time constant of the load dynamics, the transfer function may be reduced to a first order transfer function. Not clear that this simplifying assumption is applicable in this case.

So, don\'t know the open loop transfer function of the system? run a frequency test and measure the response. Create a simulink model. Understand where the poles and zeros of the system are and determine the natural frequency of the system.
Once one understands what they are dealing with then one can think about an effective control approach...there is usually more to it than throwing a PID controller at the system.
Gee, what happens if noise gets coupled into the system? Does your design compensate for that (hardware and digitally) You should also consider doing stability analysis to see if your controlled introduced an oscillation.
With all due respect, this is not a design problem for amateurs (no insinuation about your skills or experience - just a lesson learned from spending lots of time in the control and certification domain (both FDA and Mil) ).
I would love to do something more rigorous, but I can\'t even get them to do a proper requirements analysis. \"We don\'t have time.\" So instead we have a hardware \"check list\".

Yeah, I know. I think I\'ve already said I will stick around to get see that a design review is done on the next board rev, then I am out.

I did design a high side current sensor today. The motor controller has a current sensor circuit but at lower current the tolerance is terrible ±33%. The high side sensor should be within 5% even using 1% resistors throughout. I used a very small sense resistor to minimize voltage drop and the first amp stage drops that to a third, so a second amp is used to get to a 3V range. The amount of signal conditioning circuitry is adding up. We are also out of I/Os on the MCU. They are talking about needing to add LEDs for alarms, but no indication of how many or what color... oh, there are requirements for flash rate to indicate severity along with the color. I can get one I/O back from the interface to the battery charge chip and maybe another elsewhere. Two I/Os and an I2C chip will get you a lot more I/Os as long as you don\'t require them to set interrupts.

--

Rick C.

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

No time for analysis? Requirement issues are always around. Requirements creep can be deadly. How they manage that process is direct indication of how the project will turn out. Building a model of the system is an ideal way of determine where the requirements are missing/ambiguous/wrong.
You can pay me now or pay me later...unfortunately \'later\' may be when a person dies. Sounds like a bunch of clowns running (mangling) the project...(let me guess...\'just give it to the engineers, they will figure it out\' and the famous \'there is always a hero that pulls it out\')
One can\'t fix stupid....run away...fast.
J

They should test it on themselves.

Nice idea; I\'ve tried it and it isn\'t a good test.

Basically while I could play at being \"almost recovered\",
I was no good at pretending to be \"dead\".

 

[bitrex]

On 8/17/2020 11:53 AM, George Herold wrote:

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.

Do you know any good control \'theory/practice\' books. I\'ve got a few, but
I tend to get a little lost in the Laplace transforms, And would
love something with a more \'hands on\' feel, an AoE type of book.

Tim Wescott\'s book is fine.
https://www.wescottdesign.com/actfes/actfes.html

Would you enjoy this fine series from MIT on ordinary differential
equations including Laplace transforms:

<https://www.youtube.com/watch?v=zvbdoSeGAgI>

The whole lecture series is good. the Laplace transform (and other
integral transforms too) are, in general, tools for solving differential
equations. So a refresh on ODEs may be helpful

George H.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[bitrex]

On 8/18/2020 3:05 PM, bitrex wrote:

On 8/17/2020 11:53 AM, George Herold wrote:
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.

Do you know any good control \'theory/practice\' books.  I\'ve got a few,
but
I tend to get a little lost in the Laplace transforms, And would
love something with a more \'hands on\' feel, an AoE type of book.

Tim Wescott\'s book is fine.
https://www.wescottdesign.com/actfes/actfes.html

Would you enjoy this fine series from MIT on ordinary differential
equations including Laplace transforms:

https://www.youtube.com/watch?v=zvbdoSeGAgI

The whole lecture series is good. the Laplace transform (and other
integral transforms too) are, in general, tools for solving differential
equations. So a refresh on ODEs may be helpful

Or the short-short version: power series coefficients are vectors in a
vector space. Under some constraints, continuous functions are also
vectors. The Laplace transform is a change of basis in a vector space of
continuous functions, a basis where differential and integral operators
become algebraic operators, and convolution becomes multiplication.

 

[bitrex]

On 8/18/2020 3:17 PM, bitrex wrote:

On 8/18/2020 3:05 PM, bitrex wrote:
On 8/17/2020 11:53 AM, George Herold wrote:
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.

Do you know any good control \'theory/practice\' books.  I\'ve got a
few, but
I tend to get a little lost in the Laplace transforms, And would
love something with a more \'hands on\' feel, an AoE type of book.

Tim Wescott\'s book is fine.
https://www.wescottdesign.com/actfes/actfes.html

Would you enjoy this fine series from MIT on ordinary differential
equations including Laplace transforms:

https://www.youtube.com/watch?v=zvbdoSeGAgI

The whole lecture series is good. the Laplace transform (and other
integral transforms too) are, in general, tools for solving
differential equations. So a refresh on ODEs may be helpful

Or the short-short version: power series coefficients are vectors in a
vector space. Under some constraints, continuous functions are also
vectors. The Laplace transform is a change of basis in a vector space of
continuous functions, a basis where differential and integral operators
become algebraic operators, and convolution becomes multiplication.

To a basis where..should say

 

[Three Jeeps]

On Monday, August 17, 2020 at 11:53:56 AM UTC-4, George Herold wrote:

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
lang...@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.del...@gmail.com> wrote in
d2d879c1-cf13-42f8...@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.
Do you know any good control \'theory/practice\' books. I\'ve got a few, but
I tend to get a little lost in the Laplace transforms, And would
love something with a more \'hands on\' feel, an AoE type of book.

Tim Wescott\'s book is fine.
https://www.wescottdesign.com/actfes/actfes.html

George H.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

Back in the day when I did design and teaching of this stuff, I used books by Brogan, Kou, Ogata, Diazzo & Haupis and Astrom. All are fairly theoretical, but Astroms book \"Computer Controlled System: Theory and Design - 3rd edition was one that rolled in the use of Matlab & Simulink, as well as a chapter on \'implementation details\' . There may be more applications oriented \"how to\' books around as of late, I just don\'t know about them. The Westcott book seems to be a valuable collection of \'things I learned when implementing control systems\' Anyone who lived in the trenches can identify with having learned those lessons.

Actually, some of the detailed example problems in Matlab & Simulink are quite good, and they have a example on how to use their code generator which is helpful. Getting it set up for your target machine can be a little tricky.
Good luck
J

 

[Ricketty C]

On Sunday, August 16, 2020 at 3:57:04 AM UTC-4, bitrex wrote:

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

In your equations I would be the mass moved. I would consider the equations to be a spring constant A times the integral of the flow rate to give pressure 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 time delay were the sample cycle - take a sample, process to a response, impose that response on the system, take another sample, etc., then the frequency of ringing would be 1/Tsample, no? This is assuming there is no element in the system that is a derivative of the flow rate. The \"plant\" won\'t oscillate 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
+-+ Tesla referral code - https://ts.la/richard11209

 

[Don Y]

On 8/18/2020 12:59 PM, Three Jeeps wrote:

Back in the day when I did design and teaching of this stuff, I used books
by Brogan, Kou, Ogata, Diazzo & Haupis and Astrom. All are fairly
theoretical, but Astroms book \"Computer Controlled System: Theory and Design
- 3rd edition was one that rolled in the use of Matlab & Simulink, as well
as a chapter on \'implementation details\' .

You\'re \"lucky\" (?) -- when I learned this stuff the idea of using an
ANALOG computer to implement the control was \"state of the art\"! :<

There may be more applications
oriented \"how to\' books around as of late, I just don\'t know about them.
The Westcott book seems to be a valuable collection of \'things I learned
when implementing control systems\' Anyone who lived in the trenches can
identify with having learned those lessons.

I think the (formal) theory helps you understand WHY the problems manifest.
And, give you an idea of where to go looking for them. Once you know the
roles the \"actual details\" play in the response, you can come up with
more creative ways of addressing them (esp in a \"computerized\" solution)!

For example, in an air handler, distance between actuator and sensor
translates to delay as the air physically has to transit that distance
in order to affect the sensor (d\'uh!). If, however, one of the variables
you are controlling is blower (air) speed, then the delay is not a
constant but, rather, related to the current state of THAT control loop.

So, tuning the heating or dehumidification loop on the assumption of a
constant delay leads to an overdamped response -- as it has to handle
every possible delay that might creep in as the blower loop acts.

[But, you can compensate for these types of thing in a digital control
*if* you know how they impact the system\'s transfer function and how
that is handled in your response]

Actually, some of the detailed example problems in Matlab & Simulink are
quite good, and they have a example on how to use their code generator which
is helpful. Getting it set up for your target machine can be a little
tricky. Good luck J

+42 for MatLab. Their Control Toolbox is quite capable. But, again, you
have to know WHY you\'re using particular functions not just \"plug them in\".

Having a look at commercial controllers also is enlightening as you can
see the odd/unexpected features that they have chosen to implement and
ponder how they might be of use in your control situation. Even simple
mechanisms can have subtle differences in their consequences, based on
implementation.

How do you implement deadband? Prevent integrator windup? Clamp error
terms? Clamp actuator responses? How to differentiate setpoint changes
from process disturbances? etc.

*So* many more tweeks available in a digital implementation!