Forums

PID Controller Design for Ventilator

Started by Ricketty C August 15, 2020
Am 16.08.20 um 23:28 schrieb bitrex:
> On 8/16/2020 4:01 PM, Tom Del Rosso wrote: >> bitrex wrote: >>> >>> In Singapore they just hang the condemned; it's quick and cheap and >>> they don't worry too much about whether when they violate some >>> Abrahamic commandment, which they don't have, that they should at >>> least be nicer about breaking it, so they may go about their business >>> afterwards secure in the knowledge they are still good Christians in >>> the eyes of God. like the first Commandment actually says "Thou shalt >>> not kill, except if..." >> >> What it actually says is thou shall not commit murder.  The commandment >> against "false witness" is also misinterpreted as a commandment against >> lying in general. >> >> >> > > 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.
< https://www.youtube.com/watch?v=CE8ooMBIyC8&t=396s > Carlin got it right. Murder is at 5:00 Gerhard
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
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: >>> bitrex wrote: >>>> >>>> In Singapore they just hang the condemned; it's quick and cheap and >>>> they don't worry too much about whether when they violate some >>>> Abrahamic commandment, which they don't have, that they should at >>>> least be nicer about breaking it, so they may go about their business >>>> afterwards secure in the knowledge they are still good Christians in >>>> the eyes of God. like the first Commandment actually says "Thou shalt >>>> not kill, except if..." >>> >>> What it actually says is thou shall not commit murder.&nbsp; The commandment >>> against "false witness" is also misinterpreted as a commandment against >>> lying in general. >>> >>> >>> >> >> 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
"Only God can judge. However God seems unavailable at the moment to take this particular case, so I, as God's lawfully-authorized acting representative, hereby declare your execution as an obvious criminal to be God-sanctioned."
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: >>> bitrex wrote: >>>> >>>> In Singapore they just hang the condemned; it's quick and cheap and >>>> they don't worry too much about whether when they violate some >>>> Abrahamic commandment, which they don't have, that they should at >>>> least be nicer about breaking it, so they may go about their business >>>> afterwards secure in the knowledge they are still good Christians in >>>> the eyes of God. like the first Commandment actually says "Thou shalt >>>> not kill, except if..." >>> >>> What it actually says is thou shall not commit murder.&nbsp; The commandment >>> against "false witness" is also misinterpreted as a commandment against >>> lying in general. >>> >>> >>> >> >> 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.
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) ).
On Sunday, August 16, 2020 at 1:14:10 PM UTC-4, Jan Panteltje wrote:
> On a sunny day (Sun, 16 Aug 2020 08:13:04 -0700 (PDT)) it happened Ricketty C > <gnuarm.deletethisbit@gmail.com> wrote in > <1dd215d5-ecd0-4314-a29b-f5aacbab0760o@googlegroups.com>: > > >On Sunday, August 16, 2020 at 10:31:14 AM UTC-4, Jan Panteltje wrote: > >> 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. > >> > >For example, when I try biking very fast I need deeper and more often breathing > >> > >than when I am pressing buttons on a mouse or keyboard and sitting still. > >> In the 'overall loop' one should measure oxygen level in the blood > >> and based on that pump more or less air, there is where your loop is. > >> Compare it to those funny thermostats mounted outside that control the heating > >inside > >> I have seen those, never the correct temperature inside... > >> Measure where you want it controlled, not somewhere else. > >> I would not want to be on a machine that without the oxygen level feedback > >was just pumping > >> me, could be vary dangerous. > >> Very important with people with covid-19 related changing lung damage. > > > >Your post is very confusing. > > > >If the heat comes on so hard it sets the house on fire, maybe you should have > >a controller that prevents that even if the bedroom is not quite warm enough. > > > > > >The vent is concerned with getting air into the lungs without causing damage > >to the lungs. Setting the volume goals of the machine is up to the operator > >who is monitoring the patient's O2 levels. > > > >If there is a problem with getting the O2 from the air in your lungs into your > >blood stream, perhaps you would not want a person monitoring the machine > >and just allow it to inflate your chest like a balloon causing embolisms and > >death. The machine controls aspects that are appropriate for the machine > >to control. More complex factors are controlled by a trained human. > > > >I appreciate that you have designed many control systems and I value your input. > > But you don't understand the problem fully. > > Well, OK, but I want the 'operator' out. > An operator 24/7 is fatal if he does not pay attention.
Sorry, you aren't making yourself at all clear. I'm pretty sure this is because you know so little about how the machines work that you don't understand what is going on. The machine runs the course of ventilation the operator programs. It does this with all manner of automatic monitoring of the various parameters and results. The operator is summoned by an alarm if anything is going wrong. So is there something that you take exception to? If so, can you explain it clearly?
> The amount of air and its oxygen percentage (assuming it can also mix in extra > oxygen) is something that must be checked breath by breath, try it ! > It is not as simple as a pumping in - out .
What is your point??? I think again you are showing your ignorance of what this machine does.
> That said with over 20,000 fatal medical mistakes made in Germany alone each year > https://www.thelocal.de/20140121/more-die-from-hospital-mistakes-than-on-roads > automating what counts is interesting. > Best of luck with it.
Ok, glad you are a supporter. -- Rick C. +- Get 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209
On Sunday, August 16, 2020 at 1:18:53 PM UTC-4, bitrex wrote:
> > In supportive ventilation the patient triggers the inhale, the autonomic > nervous system is still working 100% and knows when to take a breath. > > I don't think you'd do forced ventilation in a covid-19 illness > situation, that's for when the patient is in a coma or deeply sedated or > something.
There are modes that combine the two, controlled and assisted. The patient is forced to take a breath when required, but if the patient starts a breath they are supported. There seems to be some reason to let the patient control the breathing. I haven't dug into the basis of these decisions. -- Rick C. ++ Get 1,000 miles of free Supercharging ++ Tesla referral code - https://ts.la/richard11209
On Sunday, August 16, 2020 at 4:32:20 PM UTC-4, Don Y wrote:
> On 8/15/2020 9:01 PM, 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. > > Gee, silly me! I'd have thought you'd have driven the mechanism with a > FORCE necessary to overcome the losses in the mechanism and not exceed the > patient's airway capability. Let the motor attain whatever SPEED it > needs to use up that available current and do so at a rate limited > by it's -- and the mechanism's - dynamics... without being hindered > by the control loop's performance. > > [You do realize you'll have to ensure you don't command the motor to > change speed faster than it/mechanism can support? Otherwise your > analysis of the control system will fall apart] > > > I've already thought about the "transfer functions" which you seem to want > > to make complex. > > Because they ALWAYS are when there's anything more than a "motorshaft with > an encoder on it". Mechanisms and 'real world applications" invariably > introduce lag. Lag leads to oscillation -- or, highly overdamped tuning. > > > They are rather simple at a first approximation. The > > Which means you're likely missing many of the "little things" that will > conspire to make tuning harder and loop performance far from ideal. > I.e., why have a loop if you don't expect to GAIN something from it? > > You have some capture delay for the sensed variable. If it's a flash > converter, that can be near instantaneous. But, in practice, there's > likely some signal conditioning in front that limits the sensor's > response (adds delay). > > There's the location of the sensor wrt the actuator. (Also, wrt the > actual field variable). You're inevitably measuring something that > isn't the same (instantaneous) thing as what you are controlling/influencing. > (And, isn't really the same as the field variable that you REALLY > want to be dealing with!) > > There's some delay in bringing about the actuator's action. Some > of this is related to the drive interface while some is inherent > in the capabilities (limitations) of the actuator. The mechanism > coupling the actuator to the process may have nonlinearities and > delays (backlash in gearboxes is a common foe). > > There's a delay in the processing required to decide how to > drive the actuator, "now". > > How each of these respond over their operating ranges and within > a particular "cycle" need to be analyzed BEFORE you can dismiss them > as being irrelevant (*if* you can dismiss them). Otherwise, you'll > scratch your head wondering why the loop performs like crap.
Good thing I've considered all the above which I believe in every case is trivial and not a factor that needs any special consideration.
> > 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. > > And the "lung" will vary from one individual to the next. Concentrate on > the things you have control over, first -- the product's design. If there > are variables in its performance, figure out how to compensate for them > BEFORE you add the variable that is the "lung" (or, the provider operating > the device!)
You are showing your ignorance of the situation. There is a trained operator to specifically address issues like differences between patients. It is not up to the machine to magically know the characteristics of the patient it is connected to.
> > 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. > > (sigh) True to form, you underestimate the complexity of the problem and > dismiss folks who have experience solving similar problems because they > say things that you don't want to hear (e.g., FDA approval process) or > ask questions that you can't answer ("That's not important"). > > [The FDA process would have told you that you should PROVE those things to > be unimportant -- instead of hand-waving them away in "first-order > approximations".] > > Classic example of Dunning-Kruger Effect. > > If I said I've designed and implemented 50 PID loops, I'd probably be low by > a factor of 5! And, yours is "trivial", by comparison! It's not interacting > with 6 or 7 other loops, simultaneously. > > For example: > > Noticing a higher than desired ejection force for a tabletting station (35-75 > in operation concurrently) would lead the associated controller to move the > formation of the tablet *up* in the die. This requires updating the upper > punch penetration and lower punch penetration settings (mechanisms!) > in-synchrony to ensure the distance between punch tips remains unchanged. > (heaven forbid you let the punch tips TOUCH -- crunch!). Of course, the > mechanisms for each are different so the mechanical gains and dynamics of > their mechanisms differ. I.e., the control loops governing their "positions" > (at the end of motorized mechanisms; revolutions becomes tenths of thousandths > of inches) differ and can't be assumed to travel (adjust) at identical rates. > > Less distance to travel between it's formation and ejection AND likely out of > any "barreled" portion of the die (even steel wears when subjected to 10T > events at 200Hz day in and day out). > > Ah, but that means EVERY tabletting station will now form a tablet at that > new displacement! (And, stations are forming tablets WHILE THE PUNCHES > PENETRATIONS ARE "IN MOTION"!) What if some other station NOW exhibits a > higher ejection force? Do you move the tablet up even further in the die? > Do you ignore the "problem"? Coerce the previous station to tolerate a > compromise position? > > How many tablets do you end up discarding for each tradeoff? When do you > halt the process and signal the operator to change the tooling (punches/die) > because the process has moved out of your control region? > > While the punches are in motion, tablets are being formed. The forces they > experience in their formation is approximately (nonlinearly!) related to the > weight (mass) of the tablet thus formed. This is intuitive -- a "fixed" > amount of material being compressed to a particular "final size". > > So, if there is any variation between punch-tip-to-punch-tip distance WHILE > UNDER ADJUSTMENT, it manifests as "weight variation" (though you can't deduce > whether a high force means an overweight tablet or an underweight tablet > because you don't know the dimensions of the actual tablet!). > > So, the control loop that adjust the amount of material to install in each > die sees that it needs to compensate (even though it might be operating > at the ideal point IF THE PUNCHES HAD SETTLED INTO THEIR CORRECT PLACES). > As a result, it alters the fill -- and, thus, weights -- of the other > tabletting stations that haven't experienced this disturbance -- yet! > > I.e., the loop can make WORSE product than if it hadn't been in place! > [Do you remember that threee-letter agency, begins with an F?] > > As the tablet is formed higher in the die, there is increased opportunity > for material ("tablet powder... 'granulation') to incompletely fill the > die (it is gravity fed). This will likely affect ALL tabletting > stations so you want to pool the observations of all of the control > loops before deciding that you have a "fill problem". > > If so, you tweek the setpoint of the hopper controllers -- which then > feeds back into the mechanical processing of all of the tabletting > stations served by that hopper (typically two hoppers per machine). > > All of these changes affect real physical characteristics of the > tablets produced: weight, hardness, friability, dissolution time, > etc. > > Thus, there are "offline" tests performed by manufacturing staff to > test these parameters and tweek the press based on their results. > But, these tests often take on the order of minutes or fractional > hours... the machine is no longer in the same configuration it > was when the tablets sampled were produced! > > So, you have to keep track of which tablets were actually sampled, > along with the observations made during their formulation, in > order to apply the desired corrections to the CURRENT process. > > This is ONE product. With *dozens* of interacting control loops > manufacturing product (at 200 completed items per second) for a > regulated (FDA) industry. > > Would you like to discuss using control theory to assist in > autopilot navigation? Or, controlling temperature/humidity/flow > in a process air handler? Or controling the intensity of a lamp > to ensure it accurately detects the "color" of a blood assay? > Or, controlling the formulation of a "candy shell" on a small, > oval piece of chocolate?? :> > > But, hey, I'm clearly "overwhelmed" by a paddle pushing on an Ambubag. > > Yeah, that.
Are you offering to participate in the PID design for this product? -- Rick C. --- Get 1,000 miles of free Supercharging --- Tesla referral code - https://ts.la/richard11209
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
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