D
Don Y
Guest
On 8/15/2020 9:01 PM, Ricketty C wrote:
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]
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.
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!)
(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.
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]
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.
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!)
(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.
