Electronics-Related.com
Forums

PID Controller Design for Ventilator

Started by Ricketty C August 15, 2020
Am 17.08.20 um 01:25 schrieb bitrex:
> On 8/16/2020 6:54 PM, Gerhard Hoffmann wrote: >> Am 16.08.20 um 23:28 schrieb bitrex: >>> On 8/16/2020 4:01 PM, Tom Del Rosso wrote:
>>> Interpreting it as "thou shalt not murder" which may be closer to the >>> original Hebrew meaning, 5000 years ago, adds an escape route. what's >>> a murder? "killing of an innocent person." Well what's an innocent >>> person. Someone who isn't guilty. Who convicts people and determines >>> if they're guilty? Humans do. Based on what. On what their particular >>> ideas of what is "moral" in a particular situation. >> >> <&nbsp; https://www.youtube.com/watch?v=CE8ooMBIyC8&t=396s&nbsp;&nbsp;&nbsp; > >> >> Carlin got it right. Murder is at 5:00 >> >> Gerhard > > Nothing is more respectable than a humble man who acts with full > conviction he is doing God's work.
Yeah, $GOD would do exactly the same if he knew all those little facts and if HE would not hide carefully behind the humble man's broad shoulders. The average god is an asshole, and we admire HIM because he gets away with it (just like Trump). For example the idea of killing your son on the altar, fucking everyone who's not on a tree when count==3 like Zeus or taking a blood bath every other day like these meso-american gods. The nordic gods proved to be assholes when they betrayed the giant who built their castle on the Heidubreit in Iceland. Promising the sun and Freya, the deity of fertility (== Venus) were a stake really bad to loose. One of them, Loki, a male deity, seduced the horse of the giant to keep it from working when the giant was close to declare "DONE", and Loki even gave birth later to a six-legged horse named Sleipnir from this adventure who served well for Odin. In a homophobic warrior society you could not sink any deeper. Just impossible. That the nordic gods declared war to the Giants over a huge brewing kettle is harmless in comparison, even J&ouml;rg might possibly forgive them. :-) Cheers, Gerhard
On 8/16/2020 5:54 PM, Ricketty C wrote:
>> But, hey, I'm clearly "overwhelmed" by a paddle pushing on an Ambubag. >> >> Yeah, that. > > Are you offering to participate in the PID design for this product?
Hell no. It looks like a doomed project. I donate my 500+ /pro bono/ hours, annually (for the past 20+ years) to projects where I know I (and they) can do some good. [OTOH, I'm not entirely altruistic in my choice of projects! I deliberately pick projects -- and their solutions -- that I can use to learn about some technology that is of interest to me, at the time. The last two projects allowed me to experiment with unattended RDBMS management techniques and self-modifying -- learning -- Expert Systems.] I'm merely suggesting why you've missed the boat on how to approach the *process* and the design -- PID and otherwise. Get a good book on control system *theory*. Read it. Understand it. It's "old news" but many schools don't include it in their REQUIRED curricula. What's changed is the move to sampled systems instead of continuous and electronic/smart control vs. pneumatic/etc. controls. E.g., Ziegler-Nichols tuning was devised in the 40's! The more practical idea of applying it (and variants) to "self-tune" is more modern. (No need to bother yourself with more esoteric things like SPC). Then look for "control theory for dummies" examples on the web. There are also modeling tools available, nowadays, that let you PLAY with "systems" to see what they will do in certain circumstances. You can see why the systems behave the way they do and "where" the "issues" creep into the models. There are myriad approaches to "solving" these issues that have been developed over the years. Often very specific to particular application domains. (e.g., how do you control the temperature in a process vessel where the "worker" can periodically open the vessel -- for whatever reason -- and introduce a large disturbance to your controller?) You can use these -- and the Genuine Article -- to see how close your model is to reality. And, evaluate remedial measures to compensate for exposed shortcomings. Instead of asking how the system will respond to a step function, apply one to the model and WATCH. Use this understanding of the system (as modeled) to JUSTIFY why your control algorithm is "suitable" (to the regulators).
On 8/16/2020 6:09 PM, Ricketty C wrote:

> 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.
And what guidelines are they using to decide these issues? Having a multicolored flashing christmas tree isn't going to help a provider decide "what's going wrong". [And a good fraction of the population suffers from one or more forms of color-blindness. And, not all colors are readily discernible in different lighting conditions.] I went through this exercise, recently, with the design of a large "discrete indicator panel" (if you need a cheat-sheet to understand what's trying to be conveyed, then you're failing at that goal!).
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&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) ). > >
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.
On Sunday, August 16, 2020 at 11:25:05 PM UTC-4, Don Y wrote:
> On 8/16/2020 6:09 PM, Ricketty C wrote: > > > 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. > > And what guidelines are they using to decide these issues? > Having a multicolored flashing christmas tree isn't going to > help a provider decide "what's going wrong".
You literally know nothing about this. You ask a question, but it's not genuine. You just want to hear something you can maybe trash the project over. So why should anyone bother with you? This is a case where you are not part of the solution, you are part of the problem.
> [And a good fraction of the population suffers from one or more > forms of color-blindness. And, not all colors are readily > discernible in different lighting conditions.]
Sorry, you need to talk to the people who set the standards for traffic lights, and medical ventilators, not me.
> I went through this exercise, recently, with the design of a large > "discrete indicator panel" (if you need a cheat-sheet to understand > what's trying to be conveyed, then you're failing at that goal!).
I'm sure you are very accustomed to failing. Thanks anyway. -- Rick C. -++ Get 1,000 miles of free Supercharging -++ Tesla referral code - https://ts.la/richard11209
On 8/16/2020 9:18 PM, Ricketty C wrote:
> On Sunday, August 16, 2020 at 11:25:05 PM UTC-4, Don Y wrote: >> On 8/16/2020 6:09 PM, Ricketty C wrote: >> >>> 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. >> >> And what guidelines are they using to decide these issues? Having a >> multicolored flashing christmas tree isn't going to help a provider decide >> "what's going wrong". > > You literally know nothing about this. You ask a question, but it's not > genuine. You just want to hear something you can maybe trash the project > over. So why should anyone bother with you?
(sigh) AGAIN you assume that I have no first-hand knowledge of the issue.
> This is a case where you are not part of the solution, you are part of the > problem.
From here, it seems like your ignorance IS the problem! Good luck on your upcoming failure! Clown.
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.
On 8/17/2020 12:53 AM, 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. >
Here is a summary of the different modes: <https://www.openanesthesia.org/modes_of_mechanical_ventilation/> "a more modern approach describes ventilatory modes based on three characteristics &ndash; the trigger (flow versus pressure), the limit (what determines the size of the breath), and the cycle (what actually ends the breath)."
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
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&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) ). > > > > > > 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