Forums

PID Controller Design for Ventilator

Started by Ricketty C August 15, 2020
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!&nbsp; 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&oslash;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