On a sunny day (Mon, 17 Aug 2020 00:38:18 -0700) it happened Don Y <blockedofcourse@foo.invalid> wrote in <rhdc5m$j5k$1@dont-email.me>:>We circumnavigated Cape Cod on our test voyage -- without touching the wheel. > >[minor lie... we stopped for some deep sea fishing off the northeast >coast of the Cape for an hour or two -- catching several Blue Fish. >Sadly, this stop took us off "automatic control" and relied on the >skipper to keep turning the vessel back "into the waves" lest it >rock too severely (boats want to align themselves with the incoming >waves, otherwise). So, the plot of our trip has a huge "anomaly" >in the otherwise perfect record of our travel!]:-) Yes, this reminds me of the first test with xgpspc On the ocean captain said: Now let's test Jan Pantetje's auto-pilot. I was happy I got the chance, we had been for weeks on 4 hours on 4 hours off using auto-pilot would give us all some much needed sleep. So I fired up the raspberry and we all went to our cages. Had some much needed sleep, but woke up because the boat was moving in a peculiar way. Number 1 was also awake now and we wondered if we drifted of course Switched on the monitor, there was the message 'no satellites' on the screen realized the beeping sound we heard all night was not from the wind whistling but an heading alarm. Now as most of you know who have a globe when at lower than 45 degrees north the angle gets steeper, and there is a risk you fall off. Anyways where were we now? it was dark and did see no north star, just a bunch of small satellites moving across the sky I immediately knew it was a new bunch of SpaceX sats .. Grabbed the good old sextant http://panteltje.com/pub/davis_sextant_IMG_6556.JPG but could not get a fix. The compass was moving in a strange way, always pointed at the captain I asked 'cap, do carry anything magnetic with you?' 'Oops'. cap said, 'I bought this set for my grandkids' https://www.supermagnete.de/eng/magnet-sets/set-114_Z-04 I remembered that song https://www.youtube.com/watch?v=PxYU7A6qCnc water around us had bubbles, ship was laying deep... Where are we? Asked the little shipmate to turn down the radio.. 'No' he said, 'Bermuda radio has great music'. OK, Bermuda, the triangle, I have read that gas bubbles form under water making the upwards pressure lower so that would explain something. Captain was having some fish on deck when a tentacle appeared from behind him and grabbed first the fish, and then pulled cap into the depth. I screamed 'man overboard' and we started maneuvering to get cap back. More tentacles appeared and grabbed the boat, some with sucking things on them. So what can you do? switched on the radio and called 'Day in May Day In May' US coast guard replied 'who are you?' Then 'Where are you?' 'Bermuda I think' I answered, the reply was that they needed a more precise location specified. OK, now what? I still had some pizza left from the night before and started feeding it to the octopus https://en.wikipedia.org/wiki/Giant_Pacific_octopus it seemed to like it, took the whole plate, said 'thank you ' burbed, and disappeared. Immediately a submarine surfaced next to us and threw us a line, moments later we were imprisoned .. Luckily it was a nuclear sub, unmarked, so at night I shorted the cipher lock on our cage made my way to the reactor and connected my raspberry to it. Just a short script and inertial navigation took us back home into Amsterdam. https://www.youtube.com/watch?v=ASYlAnI-wEg We disconnected the raspi, stepped on land, send the sub back. Our little boat was also there, the captain replaced by the octopus. I bought some fresh pizza for it. It was grateful, and gave me the plutonium it pilfered from the sub in return.
PID Controller Design for Ventilator
Started by ●August 15, 2020
Reply by ●August 18, 20202020-08-18
Reply by ●August 18, 20202020-08-18
On Tue, 18 Aug 2020 05:44:36 -0700 (PDT), Three Jeeps <jjhudak4@gmail.com> wrote:>On Sunday, August 16, 2020 at 9:09:08 PM UTC-4, Ricketty C wrote: >> On Sunday, August 16, 2020 at 8:09:27 PM UTC-4, Three Jeeps wrote: >> > On Sunday, August 16, 2020 at 11:45:57 AM UTC-4, Ricketty C wrote: >> > > On Sunday, August 16, 2020 at 11:33:16 AM UTC-4, Lasse Langwadt Christensen wrote: >> > > > s�ndag den 16. august 2020 kl. 17.14.22 UTC+2 skrev jla...@highlandsniptechnology.com: >> > > > > On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen >> > > > > <lang...@fonz.dk> wrote: >> > > > > >> > > > > >s?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 �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 �33%. The high side sensor should be within 5% even using 1% resistors throughout. I used a very small sense resistor to minimize voltage drop and the first amp stage drops that to a third, so a second amp is used to get to a 3V range. The amount of signal conditioning circuitry is adding up. We are also out of I/Os on the MCU. They are talking about needing to add LEDs for alarms, but no indication of how many or what color... oh, there are requirements for flash rate to indicate severity along with the color. I can get one I/O back from the interface to the battery charge chip and maybe another elsewhere. Two I/Os and an I2C chip will get you a lot more I/Os as long as you don't require them to set interrupts. >> >> -- >> >> Rick C. >> >> -+- Get 1,000 miles of free Supercharging >> -+- Tesla referral code - https://ts.la/richard11209 > >No time for analysis? Requirement issues are always around. Requirements creep can be deadly. How they manage that process is direct indication of how the project will turn out. Building a model of the system is an ideal way of determine where the requirements are missing/ambiguous/wrong. >You can pay me now or pay me later...unfortunately 'later' may be when a person dies. Sounds like a bunch of clowns running (mangling) the project...(let me guess...'just give it to the engineers, they will figure it out' and the famous 'there is always a hero that pulls it out') >One can't fix stupid....run away...fast. >JThey should test it on themselves. -- John Larkin Highland Technology, Inc Science teaches us to doubt. Claude Bernard
Reply by ●August 18, 20202020-08-18
On 18/08/20 15:29, jlarkin@highlandsniptechnology.com wrote:> On Tue, 18 Aug 2020 05:44:36 -0700 (PDT), Three Jeeps > <jjhudak4@gmail.com> wrote: > >> On Sunday, August 16, 2020 at 9:09:08 PM UTC-4, Ricketty C wrote: >>> On Sunday, August 16, 2020 at 8:09:27 PM UTC-4, Three Jeeps wrote: >>>> On Sunday, August 16, 2020 at 11:45:57 AM UTC-4, Ricketty C wrote: >>>>> On Sunday, August 16, 2020 at 11:33:16 AM UTC-4, Lasse Langwadt Christensen wrote: >>>>>> søndag den 16. august 2020 kl. 17.14.22 UTC+2 skrev jla...@highlandsniptechnology.com: >>>>>>> On Sun, 16 Aug 2020 07:53:41 -0700 (PDT), Lasse Langwadt Christensen >>>>>>> <lang...@fonz.dk> wrote: >>>>>>> >>>>>>>> s?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 ±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 ±33%. The high side sensor should be within 5% even using 1% resistors throughout. I used a very small sense resistor to minimize voltage drop and the first amp stage drops that to a third, so a second amp is used to get to a 3V range. The amount of signal conditioning circuitry is adding up. We are also out of I/Os on the MCU. They are talking about needing to add LEDs for alarms, but no indication of how many or what color... oh, there are requirements for flash rate to indicate severity along with the color. I can get one I/O back from the interface to the battery charge chip and maybe another elsewhere. Two I/Os and an I2C chip will get you a lot more I/Os as long as you don't require them to set interrupts. >>> >>> -- >>> >>> Rick C. >>> >>> -+- Get 1,000 miles of free Supercharging >>> -+- Tesla referral code - https://ts.la/richard11209 >> >> No time for analysis? Requirement issues are always around. Requirements creep can be deadly. How they manage that process is direct indication of how the project will turn out. Building a model of the system is an ideal way of determine where the requirements are missing/ambiguous/wrong. >> You can pay me now or pay me later...unfortunately 'later' may be when a person dies. Sounds like a bunch of clowns running (mangling) the project...(let me guess...'just give it to the engineers, they will figure it out' and the famous 'there is always a hero that pulls it out') >> One can't fix stupid....run away...fast. >> J > > They should test it on themselves.Nice idea; I've tried it and it isn't a good test. Basically while I could play at being "almost recovered", I was no good at pretending to be "dead".
Reply by ●August 18, 20202020-08-18
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.htmlWould 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> George H. >> >> >> >> -- >> >> John Larkin Highland Technology, Inc >> >> Science teaches us to doubt. >> >> Claude Bernard >
Reply by ●August 18, 20202020-08-18
On 8/18/2020 3:05 PM, 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 helpfulOr the short-short version: power series coefficients are vectors in a vector space. Under some constraints, continuous functions are also vectors. The Laplace transform is a change of basis in a vector space of continuous functions, a basis where differential and integral operators become algebraic operators, and convolution becomes multiplication.
Reply by ●August 18, 20202020-08-18
On 8/18/2020 3:17 PM, bitrex wrote:> On 8/18/2020 3:05 PM, 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 > > Or the short-short version: power series coefficients are vectors in a > vector space. Under some constraints, continuous functions are also > vectors. The Laplace transform is a change of basis in a vector space of > continuous functions, a basis where differential and integral operators > become algebraic operators, and convolution becomes multiplication. >To a basis where..should say
Reply by ●August 18, 20202020-08-18
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ų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 BernardBack 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
Reply by ●August 18, 20202020-08-18
On Sunday, August 16, 2020 at 3:57:04 AM UTC-4, bitrex wrote:> On 8/16/2020 12:01 AM, 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. > > > > I've already thought about the "transfer functions" which you seem to want to make complex. They are rather simple at a first approximation. The 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. > > > > 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. > > > > In the electrical analogy it sounds more like the squeeze-bag is the RC > system, with an "output resistance" that varies with respect to the > volume of air (charge?) in the bag. And the lung model is something that > produces a "back EMF" (pressure) against it proportional to A*I + > B*dI/dt (What's I? flow rate?) > > and the goal of the PID is to keep the mass flow rate (current) constant > during the main portion of the inhale cycleIn your equations I would be the mass moved. I would consider the equations to be a spring constant A times the integral of the flow rate to give pressure and the airways would provide a direct result of B*I to give pressure. I can't find the post now, but I thought you had pointed out that a system could oscillate if there were enough time delay in the loop. If the only time delay were the sample cycle - take a sample, process to a response, impose that response on the system, take another sample, etc., then the frequency of ringing would be 1/Tsample, no? This is assuming there is no element in the system that is a derivative of the flow rate. The "plant" won't oscillate on its own. The data I saw showed periods of oscillation of maybe 100ms which would be 100 sample times. -- Rick C. +-+ Get 1,000 miles of free Supercharging +-+ Tesla referral code - https://ts.la/richard11209
Reply by ●August 19, 20202020-08-19
On 8/18/2020 12:59 PM, Three Jeeps wrote:> 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' .You're "lucky" (?) -- when I learned this stuff the idea of using an ANALOG computer to implement the control was "state of the art"! :<> 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.I think the (formal) theory helps you understand WHY the problems manifest. And, give you an idea of where to go looking for them. Once you know the roles the "actual details" play in the response, you can come up with more creative ways of addressing them (esp in a "computerized" solution)! For example, in an air handler, distance between actuator and sensor translates to delay as the air physically has to transit that distance in order to affect the sensor (d'uh!). If, however, one of the variables you are controlling is blower (air) speed, then the delay is not a constant but, rather, related to the current state of THAT control loop. So, tuning the heating or dehumidification loop on the assumption of a constant delay leads to an overdamped response -- as it has to handle every possible delay that might creep in as the blower loop acts. [But, you can compensate for these types of thing in a digital control *if* you know how they impact the system's transfer function and how that is handled in your response]> 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+42 for MatLab. Their Control Toolbox is quite capable. But, again, you have to know WHY you're using particular functions not just "plug them in". Having a look at commercial controllers also is enlightening as you can see the odd/unexpected features that they have chosen to implement and ponder how they might be of use in your control situation. Even simple mechanisms can have subtle differences in their consequences, based on implementation. How do you implement deadband? Prevent integrator windup? Clamp error terms? Clamp actuator responses? How to differentiate setpoint changes from process disturbances? etc. *So* many more tweeks available in a digital implementation!
Reply by ●August 19, 20202020-08-19
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 helpfulYeah 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.> > > > George H. > >> > >> > >> > >> -- > >> > >> John Larkin Highland Technology, Inc > >> > >> Science teaches us to doubt. > >> > >> Claude Bernard > >
