PID Controller Design for Ventilator

On a sunny day (Sun, 16 Aug 2020 11:03:24 -0700) it happened
jlarkin@highlandsniptechnology.com wrote in
<i4tijfpgmocd67d1b46sl6hmud35nurg74@4ax.com>:

>I we are going to have capital punishment, nitrogen sounds like the
>way to do it to me.

 From the last testament
in the twentieth century when the Evil Ruler Donald Trump came to power
God send the corona virus to punish the people

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

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

>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

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.

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>

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&#371;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

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

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

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&#371;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 &plusmn;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 &plusmn;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