Electronics-Related.com
Forums

PID Controller Design for Ventilator

Started by Ricketty C August 15, 2020
On Tuesday, August 18, 2020 at 3:59:43 PM UTC-4, Three Jeeps wrote:
> On Monday, August 17, 2020 at 11:53:56 AM UTC-4, George Herold wrote: > > On Sunday, August 16, 2020 at 11:14:22 AM UTC-4, jla...@highlandsniptechnology.com wrote: > > > On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen > > > <lang...@fonz.dk> wrote: > > > > > > >s&#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. > > Do you know any good control 'theory/practice' books. I've got a few, but > > I tend to get a little lost in the Laplace transforms, And would > > love something with a more 'hands on' feel, an AoE type of book. > > > > Tim Wescott's book is fine. > > https://www.wescottdesign.com/actfes/actfes.html > > > > George H. > > > > > > > > > > > > -- > > > > > > John Larkin Highland Technology, Inc > > > > > > Science teaches us to doubt. > > > > > > Claude Bernard > > Back in the day when I did design and teaching of this stuff, I used books by Brogan, Kou, Ogata, Diazzo & Haupis and Astrom. All are fairly theoretical, but Astroms book "Computer Controlled System: Theory and Design - 3rd edition was one that rolled in the use of Matlab & Simulink, as well as a chapter on 'implementation details' . There may be more applications oriented "how to' books around as of late, I just don't know about them. The Westcott book seems to be a valuable collection of 'things I learned when implementing control systems' Anyone who lived in the trenches can identify with having learned those lessons. > > Actually, some of the detailed example problems in Matlab & Simulink are quite good, and they have a example on how to use their code generator which is helpful. Getting it set up for your target machine can be a little tricky. > Good luck > J
Thanks, I'll give 'em a look see. George H.
On Wed, 19 Aug 2020 08:05:08 -0700 (PDT), George Herold
<ggherold@gmail.com> wrote:

>On Tuesday, August 18, 2020 at 3:05:56 PM UTC-4, bitrex wrote: >> On 8/17/2020 11:53 AM, George Herold wrote: >> > On Sunday, August 16, 2020 at 11:14:22 AM UTC-4, jla...@highlandsniptechnology.com wrote: >> >> On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen >> >> <langwadt@fonz.dk> wrote: >> >> >> >>> s?ndag den 16. august 2020 kl. 16.31.14 UTC+2 skrev Jan Panteltje: >> >>>> On a sunny day (Sat, 15 Aug 2020 22:46:45 -0700 (PDT)) it happened Ricketty C >> >>>> <gnuarm.deletethisbit@gmail.com> wrote in >> >>>> <d2d879c1-cf13-42f8-9727-8ef27dc2dc65o@googlegroups.com>: >> >>>> >> >>>>> >> >>>>> He shows the only difference between patient triggered and machine triggered >> >>>>> waveforms is the negative pressure from the patient trying to draw air in >> >>>>> at the very start of the cycle. His diagrams are pretty poor with no registration >> >>>>> between the various points on different parameters, but he gets across >> >>>>> the main points. You can do a Google search to find other much better >> >>>>> diagrams. I don't think there are any new concepts to an engineer. >> >>>> >> >>>> No experience with these things >> >>>> but from _my_ life I know breathing is related to oxygen level in the blood. >> >>> >> >>> not really, your breathing is mostly related to the amount of CO2 in your lungs >> >>> that's why breathing something like pure nitrogen will kill you without you >> >>> even noticing >> >> >> >> I wonder how many old ladies ricky's team plans to kill, trying to >> >> learn PIDs and stuff. >> > >> > Do you know any good control 'theory/practice' books. I've got a few, but >> > I tend to get a little lost in the Laplace transforms, And would >> > love something with a more 'hands on' feel, an AoE type of book. >> > >> > Tim Wescott's book is fine. >> > https://www.wescottdesign.com/actfes/actfes.html >> >> Would you enjoy this fine series from MIT on ordinary differential >> equations including Laplace transforms: >> >> <https://www.youtube.com/watch?v=zvbdoSeGAgI> >> >> The whole lecture series is good. the Laplace transform (and other >> integral transforms too) are, in general, tools for solving differential >> equations. So a refresh on ODEs may be helpful >Yeah well I just replace 's' with 'i*w' (omega.. angular frequency) and >Laplace transforms are fine. My problem is that it's easy to dig down >into the math (algebra) and lose a sense of what is going on. >I sorta need the math after I understand it. > >George H. >
Right. Being able to push some equations around doesn't mean you understand it. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
On Wednesday, August 19, 2020 at 11:05:16 AM UTC-4, George Herold wrote:
> On Tuesday, August 18, 2020 at 3:05:56 PM UTC-4, bitrex wrote: > > On 8/17/2020 11:53 AM, George Herold wrote: > > > On Sunday, August 16, 2020 at 11:14:22 AM UTC-4, jla...@highlandsniptechnology.com wrote: > > >> On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen > > >> <langwadt@fonz.dk> wrote: > > >> > > >>> s&#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 > > > > Would you enjoy this fine series from MIT on ordinary differential > > equations including Laplace transforms: > > > > <https://www.youtube.com/watch?v=zvbdoSeGAgI> > > > > The whole lecture series is good. the Laplace transform (and other > > integral transforms too) are, in general, tools for solving differential > > equations. So a refresh on ODEs may be helpful > Yeah well I just replace 's' with 'i*w' (omega.. angular frequency) and > Laplace transforms are fine. My problem is that it's easy to dig down > into the math (algebra) and lose a sense of what is going on. > I sorta need the math after I understand it.
That seems a bit backwards to me. The math is what ultimately explains things. You just need to understand the math. Math is hard, so people often take short cuts. I don't want to wade through a bunch of math of a PID controller that might not be completely correct, but I can use the math to explore the nature of the beast. The lung has a dissipative element and an integral element. That tells me what the waveforms of pressure, flow and volume should look like and how the controller should function. Until I get some idea of the math, I don't know what to expect. I was just looking a the waveforms of our controller. I was being told our graphs are near, but not quite the same as the example case. I realized very quickly the differences are not from the controller. They are from differences in the lung model. With constant pressure, the spring constant creates a curve in the volume and a sloping curve in the flow. The dissipative element (like resistance) gives a pressure directly proportional to flow, so the flow would be flat like the pressure and volume would be a triangle. The example shows more influence from the dissipative element and less from the spring constant. The controller is working fine. The test case has a slower pressure release on the exhale side indicating the exhalation path is more obstructed than the example. If our test case were on a real patient the flow rate dropping near zero means the lungs are nearly full which I expect would make injury more likely and the volume needs to be reduced. Maybe I am making your case because I didn't do any math to dig out this info, but it is because I have seen the math and understand what the math tells me. -- Rick C. -++ Get 1,000 miles of free Supercharging -++ Tesla referral code - https://ts.la/richard11209
On Saturday, August 15, 2020 at 9:44:08 PM UTC-4, 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
What you might want to think about is breaking the cycle up into chunks, to remove some of the mechanical geometry from the equation. Then do PID on each of those. The arduino libraries include PID and FastPID, which as another poster mentioned, can be tuned on the fly. My thinking is that by removing mechanical variables, you've really simplified things. I would start with a sketched curve of pressure (or volume)/time. Mark on the curve the points where the geometry changes significantly. Now try to tune the PID for the leftmost segment. When that's behaving OK, tune the PID for the next segment, leaving the first settings alone. Repeat until the whole thing is working. Note - I have never done this sort of segment system, but that's where I would start. I'm a little concerned that "they" are running out of CPU with something as slow as human breathing. In fact, it's slow enough that you might consider a different approach: Map the rotation of the shaft to the volume of expelled air. Set many target points along that curve and then positively control the motor to hit those points of rotation at the proper times. This should also be easy to set up with Arduino PID controls (which will also work on higher end boards like ARM, ESP or the like). A tiny & cheap shaft encoder would make it really simple.
On Wednesday, August 19, 2020 at 8:50:05 PM UTC-4, rangerssuck wrote:
> On Saturday, August 15, 2020 at 9:44:08 PM UTC-4, 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 > > What you might want to think about is breaking the cycle up into chunks, to remove some of the mechanical geometry from the equation. Then do PID on each of those. The arduino libraries include PID and FastPID, which as another poster mentioned, can be tuned on the fly. > > My thinking is that by removing mechanical variables, you've really simplified things. I would start with a sketched curve of pressure (or volume)/time. Mark on the curve the points where the geometry changes significantly. Now try to tune the PID for the leftmost segment. When that's behaving OK, tune the PID for the next segment, leaving the first settings alone. Repeat until the whole thing is working.
The only changes in "geometry" (which I assume you mean the shape of the curve) is at the points were we change our set point. The ideal curve would be a square wave for which ever variable is being controlled. The rate of the leading edge will be limited by the details of the control loop. The trailing edge is not in control since that is simply the patient exhaling. Nothing much is needed really. I think the ringing curve they showed me was pure P with no I or D terms in the control loop, but the gain was set far too high. Without the I term the P term requires an error to maintain a non-zero output. To minimize the error the gain is set way high resulting in excessive acceleration and ultimately ringing in the controlled parameter. The other day they showed me working graphs where the exact shape is slightly different from the examples, but not in any way I would not attribute to the details of the lung model. I don't know what they did, but it is working.
> Note - I have never done this sort of segment system, but that's where I would start. > > I'm a little concerned that "they" are running out of CPU with something as slow as human breathing.
I don't recall saying they had run out of CPU. Some weeks ago we switched from an Arduino CPU to an ARM CM4F when we needed more I/Os. No one objected to switching to a better CPU, but it has lots of room for growth in the project... except for I/Os. We are nearly out and they've decided to add more LEDs.
> In fact, it's slow enough that you might consider a different approach: Map the rotation of the shaft to the volume of expelled air. Set many target points along that curve and then positively control the motor to hit those points of rotation at the proper times. This should also be easy to set up with Arduino PID controls (which will also work on higher end boards like ARM, ESP or the like). A tiny & cheap shaft encoder would make it really simple.
That would work for flow rate control, but the pressure depends on the patient and they are not all the same. It also depends on all the mechanical parts being the same with the same friction and the same resilience, etc. They have gone to great lengths to design a flow meter and we have a pressure gauge, so they are going to be used! The more I think about the control loop, the simpler I think it will be. We have so much time to deal with the changes that it would require effort to muck it up. -- Rick C. +-- Get 1,000 miles of free Supercharging +-- Tesla referral code - https://ts.la/richard11209
On 8/19/2020 12:08 PM, Ricketty C wrote:
> On Wednesday, August 19, 2020 at 11:05:16 AM UTC-4, George Herold wrote: >> On Tuesday, August 18, 2020 at 3:05:56 PM UTC-4, bitrex wrote: >>> On 8/17/2020 11:53 AM, George Herold wrote: >>>> On Sunday, August 16, 2020 at 11:14:22 AM UTC-4, jla...@highlandsniptechnology.com wrote: >>>>> On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen >>>>> <langwadt@fonz.dk> wrote: >>>>> >>>>>> s&#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 >>> >>> Would you enjoy this fine series from MIT on ordinary differential >>> equations including Laplace transforms: >>> >>> <https://www.youtube.com/watch?v=zvbdoSeGAgI> >>> >>> The whole lecture series is good. the Laplace transform (and other >>> integral transforms too) are, in general, tools for solving differential >>> equations. So a refresh on ODEs may be helpful >> Yeah well I just replace 's' with 'i*w' (omega.. angular frequency) and >> Laplace transforms are fine. My problem is that it's easy to dig down >> into the math (algebra) and lose a sense of what is going on. >> I sorta need the math after I understand it. > > That seems a bit backwards to me. The math is what ultimately explains things. You just need to understand the math. Math is hard, so people often take short cuts. I don't want to wade through a bunch of math of a PID controller that might not be completely correct, but I can use the math to explore the nature of the beast. The lung has a dissipative element and an integral element. That tells me what the waveforms of pressure, flow and volume should look like and how the controller should function. Until I get some idea of the math, I don't know what to expect. > > I was just looking a the waveforms of our controller. I was being told our graphs are near, but not quite the same as the example case. I realized very quickly the differences are not from the controller. They are from differences in the lung model. With constant pressure, the spring constant creates a curve in the volume and a sloping curve in the flow. The dissipative element (like resistance) gives a pressure directly proportional to flow, so the flow would be flat like the pressure and volume would be a triangle. The example shows more influence from the dissipative element and less from the spring constant. The controller is working fine. The test case has a slower pressure release on the exhale side indicating the exhalation path is more obstructed than the example. If our test case were on a real patient the flow rate dropping near zero means the lungs are nearly full which I expect would make injury more likely and the volume needs to be reduced. > > Maybe I am making your case because I didn't do any math to dig out this info, but it is because I have seen the math and understand what the math tells me. >
What level of abstraction one needs to use at a particular time is a skill. It's rare that there are interesting problems that one can intuitively understand all the way up and down thru the levels and have some God's-eye knowledge of everything without from time to time resorting to faith in the idea that the process of pushing equations often provides answers that are correct regardless if you "grok" every piece of it. That is to say some people can read machine's "mind" I don't have this ability.
On 8/19/2020 11:05 AM, George Herold wrote:
> On Tuesday, August 18, 2020 at 3:05:56 PM UTC-4, bitrex wrote: >> On 8/17/2020 11:53 AM, George Herold wrote: >>> On Sunday, August 16, 2020 at 11:14:22 AM UTC-4, jla...@highlandsniptechnology.com wrote: >>>> On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen >>>> <langwadt@fonz.dk> wrote: >>>> >>>>> s&#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 >> >> Would you enjoy this fine series from MIT on ordinary differential >> equations including Laplace transforms: >> >> <https://www.youtube.com/watch?v=zvbdoSeGAgI> >> >> The whole lecture series is good. the Laplace transform (and other >> integral transforms too) are, in general, tools for solving differential >> equations. So a refresh on ODEs may be helpful > Yeah well I just replace 's' with 'i*w' (omega.. angular frequency) and > Laplace transforms are fine. My problem is that it's easy to dig down > into the math (algebra) and lose a sense of what is going on. > I sorta need the math after I understand it. > > George H.
Do you have a particular example of what in the process of "understanding" is a sticking-point? All that's happening is that the integro-differential equations of LTI circuits or systems in the time domain are being converted to algebraic ones. And then once the equation is solved in the s domain you can run the machine backwards and get the solution in the time domain again, if you want. The reason you can "read" the frequency response in the s domain by making that substitution and taking the magnitude is because convolution is the same as multiplication there, and the Laplace transform of the unit impulse is 1. In the time domain you'd get the frequency response by convolution of the time-domain equation with the unit impulse, in the s domain that work is mostly already done for you as-is just by virtue of the transformation process. Both functions in both domains must have equal power spectral densities so it's still the same system except the implicit convolution acting on an s-domain transfer function has made the variable "s" equivalent to complex frequency. hence you can make that substitution and it works out. Sometimes you have to do algebra to get equations in the s domain in the form of a transfer function between input and output and find magnitudes and phases, but there's nothing really interesting in the algebra of that itself, it's just a mechanical process.
On 8/20/2020 5:21 PM, bitrex wrote:
> On 8/19/2020 11:05 AM, George Herold wrote: >> On Tuesday, August 18, 2020 at 3:05:56 PM UTC-4, bitrex wrote: >>> On 8/17/2020 11:53 AM, George Herold wrote: >>>> On Sunday, August 16, 2020 at 11:14:22 AM UTC-4, >>>> jla...@highlandsniptechnology.com wrote: >>>>> On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen >>>>> <langwadt@fonz.dk> wrote: >>>>> >>>>>> s&#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.&nbsp; His diagrams are pretty poor >>>>>>>> with no registration >>>>>>>> between the various points on different parameters, but he gets >>>>>>>> across >>>>>>>> the main points.&nbsp; You can do a Google search to find other much >>>>>>>> better >>>>>>>> diagrams.&nbsp; I don't think there are any new concepts to an engineer. >>>>>>> >>>>>>> No experience with these things >>>>>>> but from _my_ life I&nbsp; 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.&nbsp; I've got a >>>> few, but >>>> I tend to get a little lost in the Laplace transforms, And would >>>> love something with a more 'hands on' feel, an AoE type of book. >>>> >>>> Tim Wescott's book is fine. >>>> https://www.wescottdesign.com/actfes/actfes.html >>> >>> Would you enjoy this fine series from MIT on ordinary differential >>> equations including Laplace transforms: >>> >>> <https://www.youtube.com/watch?v=zvbdoSeGAgI> >>> >>> The whole lecture series is good. the Laplace transform (and other >>> integral transforms too) are, in general, tools for solving differential >>> equations. So a refresh on ODEs may be helpful >> Yeah well I just replace 's' with 'i*w' (omega.. angular frequency) and >> Laplace transforms are fine.&nbsp; My problem is that it's easy to dig down >> into the math (algebra) and lose a sense of what is going on. >> I sorta need the math after I understand it. >> >> George H. > > Do you have a particular example of what in the process of > "understanding" is a sticking-point? > > All that's happening is that the integro-differential equations of LTI > circuits or systems in the time domain are being converted to algebraic > ones. And then once the equation is solved in the s domain you can run > the machine backwards and get the solution in the time domain again, if > you want. > > The reason you can "read" the frequency response in the s domain by > making that substitution and taking the magnitude is because convolution > is the same as multiplication there, and the Laplace transform of the > unit impulse is 1. > > In the time domain you'd get the frequency response by convolution of > the time-domain equation with the unit impulse, in the s domain that > work is mostly already done for you as-is just by virtue of the > transformation process. > > Both functions in both domains must have equal power spectral densities > so it's still the same system except the implicit convolution acting on > an s-domain transfer function has made the variable "s" equivalent to > complex frequency. hence you can make that substitution and it works out. > > Sometimes you have to do algebra to get equations in the s domain in the > form of a transfer function between input and output and find magnitudes > and phases, but there's nothing really interesting in the algebra of > that itself, it's just a mechanical process.
Wes Hayward's book "Introduction to RF Design" has a section about how to apply it to designing a PLL. The intuition comes in via knowing a PLL should have certain parts with certain characteristics. There's a VCO. A phase detector. Loop filter. Feedback loop around. And you figure out what the transfer functions of those are in general, and the whole loop in combination. and you construct an equation for the loop transfer function, with some unknown coefficients. What values the coefficient have to take to make the loop stable and do what you want is where the math/engineering comes in, you have to analyze the equation, make plots of various values to figure out what the coefficients should be to get the result you want. Doesn't require a lot more "understanding" than that! "it is what it is"
On Thursday, August 20, 2020 at 5:21:22 PM UTC-4, bitrex wrote:
> On 8/19/2020 11:05 AM, George Herold wrote: > > On Tuesday, August 18, 2020 at 3:05:56 PM UTC-4, bitrex wrote: > >> On 8/17/2020 11:53 AM, George Herold wrote: > >>> On Sunday, August 16, 2020 at 11:14:22 AM UTC-4, jla...@highlandsniptechnology.com wrote: > >>>> On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen > >>>> <langwadt@fonz.dk> wrote: > >>>> > >>>>> s&#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 > >> > >> Would you enjoy this fine series from MIT on ordinary differential > >> equations including Laplace transforms: > >> > >> <https://www.youtube.com/watch?v=zvbdoSeGAgI> > >> > >> The whole lecture series is good. the Laplace transform (and other > >> integral transforms too) are, in general, tools for solving differential > >> equations. So a refresh on ODEs may be helpful > > Yeah well I just replace 's' with 'i*w' (omega.. angular frequency) and > > Laplace transforms are fine. My problem is that it's easy to dig down > > into the math (algebra) and lose a sense of what is going on. > > I sorta need the math after I understand it. > > > > George H. > > Do you have a particular example of what in the process of > "understanding" is a sticking-point? >
Not at the moment. I've done mostly thermal loops, which are easy (no thermal 'momentum/ inductance'). I guess the perennial question in a thermal loop is where to put the heater/ TEC / cooler (plant) and where to put the temperature sensor. George H.
> All that's happening is that the integro-differential equations of LTI > circuits or systems in the time domain are being converted to algebraic > ones. And then once the equation is solved in the s domain you can run > the machine backwards and get the solution in the time domain again, if > you want. > > The reason you can "read" the frequency response in the s domain by > making that substitution and taking the magnitude is because convolution > is the same as multiplication there, and the Laplace transform of the > unit impulse is 1. > > In the time domain you'd get the frequency response by convolution of > the time-domain equation with the unit impulse, in the s domain that > work is mostly already done for you as-is just by virtue of the > transformation process. > > Both functions in both domains must have equal power spectral densities > so it's still the same system except the implicit convolution acting on > an s-domain transfer function has made the variable "s" equivalent to > complex frequency. hence you can make that substitution and it works out. > > Sometimes you have to do algebra to get equations in the s domain in the > form of a transfer function between input and output and find magnitudes > and phases, but there's nothing really interesting in the algebra of > that itself, it's just a mechanical process.
On Thursday, August 20, 2020 at 9:22:01 PM UTC-4, George Herold wrote:
> On Thursday, August 20, 2020 at 5:21:22 PM UTC-4, bitrex wrote: > > On 8/19/2020 11:05 AM, George Herold wrote: > > > On Tuesday, August 18, 2020 at 3:05:56 PM UTC-4, bitrex wrote: > > >> On 8/17/2020 11:53 AM, George Herold wrote: > > >>> On Sunday, August 16, 2020 at 11:14:22 AM UTC-4, jla...@highlandsniptechnology.com wrote: > > >>>> On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen > > >>>> <langwadt@fonz.dk> wrote: > > >>>> > > >>>>> s&#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 > > >> > > >> Would you enjoy this fine series from MIT on ordinary differential > > >> equations including Laplace transforms: > > >> > > >> <https://www.youtube.com/watch?v=zvbdoSeGAgI> > > >> > > >> The whole lecture series is good. the Laplace transform (and other > > >> integral transforms too) are, in general, tools for solving differential > > >> equations. So a refresh on ODEs may be helpful > > > Yeah well I just replace 's' with 'i*w' (omega.. angular frequency) and > > > Laplace transforms are fine. My problem is that it's easy to dig down > > > into the math (algebra) and lose a sense of what is going on. > > > I sorta need the math after I understand it. > > > > > > George H. > > > > Do you have a particular example of what in the process of > > "understanding" is a sticking-point? > > > Not at the moment. I've done mostly thermal loops, which > are easy (no thermal 'momentum/ inductance'). I guess the > perennial question in a thermal loop is where to put the > heater/ TEC / cooler (plant) and where to put the temperature sensor.
Earlier it was pointed out that delays in the system can impact loop stability. I believe thermal systems can have such delays, for example, when the heater itself has significant thermal mass and the object being heated also has thermal mass with some thermal impedance between. Such a system can be stabilized by using multiple loops. A fast loop to control the temperature of the first thermal mass and a second, slower loop to adjust the set point of the first loop ultimately managing the temperature of the second thermal mass. I suppose a single loop with a slow response would work, but I expect it will require a slower response than the two loop design to deal with integrator wind up because the inner loop would allow the set point to ramp up more quickly without ramping up the outer loop integrator. Yes, no? Today in the conference call I explained the idea of reducing the overshoot by instead of limiting the slew rate of the PID controller, not driving it with an abrupt step function. Rather a slope can be used appropriate for the desired ramp up of the controlled variable. Rather than focus on making the controller manage the rate, give it the rate it should follow. -- Rick C. +-+ Get 1,000 miles of free Supercharging +-+ Tesla referral code - https://ts.la/richard11209