>
>
> "langwadt@fonz.dk" wrote:
>
>> On 27 Apr., 06:36, Jerry Avins ?j...@ieee.org? wrote:
>>
>> ? Has anyone here designed or even seen a high-performance servo with an
>> ? air-powered actuator? The compliance is usually a killer.
>> ?
>>
>> maybe it is doable: http://machinedesign.com/article/servocontrol-with-pneumatic-actuators-1011
>>
>> though I'd expect it to be a bit like driving a car using a pair of
>> rubber bands
>
> I had a car in 70's that uses air logic and amplifiers in its engine
> controller. Gains were analog needle valves and I had two
> "incidents" where an air amp locked up and the car accelerated
> until the ignition was turned off with the key. In both cases it
> buried the tach almost instantly. That was the bad news, the
> good news was when it was properly set up it worked well.
Power brakes are usually vacuum operated (at least they were when I
first became acquainted with them). Pneumatics can work quite well when
force is the controlled variable. I had position servos in mind when I
asked the question.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by John Ferrell●April 30, 20122012-04-30
On Sat, 28 Apr 2012 11:36:30 +0300, Tauno Voipio
<tauno.voipio@notused.fi.invalid> wrote:
>>> maybe it is doable: http://machinedesign.com/article/servocontrol-with-pneumatic-actuators-1011
>>>
>>> though I'd expect it to be a bit like driving a car using a pair of
>>> rubber bands
>>>
>>>
>>> -Lasse
>> My 1962 Beech Bonanza (airplane) had a vacuum driven TACTAIR autopilot
>> that was steady as bedrock. No electronics required. There is a lot of
>> technology that has been abandoned. Way too many pilots out there on
>> instruments that relied completely on the TACTAIR!
>> John Ferrell W8CCW
>
>Did you have a second vacuum pump?
I no longer own the airplane. It did not have a backup vacuum pump.
The electronics and vacuum systems were each others backups.
The point I was trying to make is that pneumatic systems can be
constructed in a manner to be precise, robust and strong. Dirt & dust
are the main problems encountered.
John Ferrell W8CCW
Reply by Walter Banks●April 29, 20122012-04-29
"langwadt@fonz.dk" wrote:
> On 27 Apr., 06:36, Jerry Avins ?j...@ieee.org? wrote:
>
> ? Has anyone here designed or even seen a high-performance servo with an
> ? air-powered actuator? The compliance is usually a killer.
> ?
>
> maybe it is doable: http://machinedesign.com/article/servocontrol-with-pneumatic-actuators-1011
>
> though I'd expect it to be a bit like driving a car using a pair of
> rubber bands
I had a car in 70's that uses air logic and amplifiers in its engine
controller. Gains were analog needle valves and I had two
"incidents" where an air amp locked up and the car accelerated
until the ignition was turned off with the key. In both cases it
buried the tach almost instantly. That was the bad news, the
good news was when it was properly set up it worked well.
w..
Reply by Tauno Voipio●April 28, 20122012-04-28
On 27.4.12 11:55 , John Ferrell wrote:
> On Fri, 27 Apr 2012 08:59:27 -0700 (PDT), "langwadt@fonz.dk"
> <langwadt@fonz.dk> wrote:
>
>> On 27 Apr., 06:36, Jerry Avins<j...@ieee.org> wrote:
>>> On 4/24/2012 3:46 PM, upsided...@downunder.com wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Tue, 24 Apr 2012 03:59:16 GMT, Al Clark<acl...@danvillesignal.com>
>>>> wrote:
>>>
>>>>> As far as I know, Microchip does not have a floating point device. Generally
>>>>> speaking, floating point emulation is very inefficient with fixed point
>>>>> processors and more times than not, a bad idea if you care about performance.
>>>>> It's usually better to use a fixed point version of the function or migrate
>>>>> to a device with native floating point support.
>>>
>>>> How many embedded applications really do any heavy floating point
>>>> operations ?
>>>
>>>> OK, if you do a lot of floating point matrix multiplications and
>>>> inversions with large arrays, a real HW FP is a must.
>>>
>>>> However, in most cases the need for floating point processing in the
>>>> embedded environment is simply due to constructs like
>>>
>>>> sprintf (TextString, "Length %6.2f meters", Integer_cm_value/100.0) ;
>>>
>>>> Thus, the total number of floating point instruction is typically very
>>>> low and not justify any FP HW. Of course, the emulation code needs
>>>> some space, so there are some tradeoffs to be made.
>>>
>>> Has anyone here designed or even seen a high-performance servo with an
>>> air-powered actuator? The compliance is usually a killer.
>>>
>>
>> maybe it is doable: http://machinedesign.com/article/servocontrol-with-pneumatic-actuators-1011
>>
>> though I'd expect it to be a bit like driving a car using a pair of
>> rubber bands
>>
>>
>> -Lasse
> My 1962 Beech Bonanza (airplane) had a vacuum driven TACTAIR autopilot
> that was steady as bedrock. No electronics required. There is a lot of
> technology that has been abandoned. Way too many pilots out there on
> instruments that relied completely on the TACTAIR!
> John Ferrell W8CCW
Did you have a second vacuum pump?
--
Tauno Voipio OH2UG, flying a very electric airplane, DA42
>On 27 Apr., 06:36, Jerry Avins <j...@ieee.org> wrote:
>> On 4/24/2012 3:46 PM, upsided...@downunder.com wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > On Tue, 24 Apr 2012 03:59:16 GMT, Al Clark<acl...@danvillesignal.com>
>> > wrote:
>>
>> >> As far as I know, Microchip does not have a floating point device. Generally
>> >> speaking, floating point emulation is very inefficient with fixed point
>> >> processors and more times than not, a bad idea if you care about performance.
>> >> It's usually better to use a fixed point version of the function or migrate
>> >> to a device with native floating point support.
>>
>> > How many embedded applications really do any heavy floating point
>> > operations ?
>>
>> > OK, if you do a lot of floating point matrix multiplications and
>> > inversions with large arrays, a real HW FP is a must.
>>
>> > However, in most cases the need for floating point processing in the
>> > embedded environment is simply due to constructs like
>>
>> > sprintf (TextString, "Length %6.2f meters", Integer_cm_value/100.0) ;
>>
>> > Thus, the total number of floating point instruction is typically very
>> > low and not justify any FP HW. Of course, the emulation code needs
>> > some space, so there are some tradeoffs to be made.
>>
>> Has anyone here designed or even seen a high-performance servo with an
>> air-powered actuator? The compliance is usually a killer.
>>
>
>maybe it is doable: http://machinedesign.com/article/servocontrol-with-pneumatic-actuators-1011
>
>though I'd expect it to be a bit like driving a car using a pair of
>rubber bands
>
>
>-Lasse
My 1962 Beech Bonanza (airplane) had a vacuum driven TACTAIR autopilot
that was steady as bedrock. No electronics required. There is a lot of
technology that has been abandoned. Way too many pilots out there on
instruments that relied completely on the TACTAIR!
John Ferrell W8CCW
Reply by lang...@fonz.dk●April 27, 20122012-04-27
On 27 Apr., 06:36, Jerry Avins <j...@ieee.org> wrote:
> On 4/24/2012 3:46 PM, upsided...@downunder.com wrote:
>
>
>
>
>
>
>
>
>
> > On Tue, 24 Apr 2012 03:59:16 GMT, Al Clark<acl...@danvillesignal.com>
> > wrote:
>
> >> As far as I know, Microchip does not have a floating point device. Generally
> >> speaking, floating point emulation is very inefficient with fixed point
> >> processors and more times than not, a bad idea if you care about performance.
> >> It's usually better to use a fixed point version of the function or migrate
> >> to a device with native floating point support.
>
> > How many embedded applications really do any heavy floating point
> > operations ?
>
> > OK, if you do a lot of floating point matrix multiplications and
> > inversions with large arrays, a real HW FP is a must.
>
> > However, in most cases the need for floating point processing in the
> > embedded environment is simply due to constructs like
>
> > sprintf (TextString, "Length %6.2f meters", Integer_cm_value/100.0) ;
>
> > Thus, the total number of floating point instruction is typically very
> > low and not justify any FP HW. Of course, the emulation code needs
> > some space, so there are some tradeoffs to be made.
>
> Has anyone here designed or even seen a high-performance servo with an
> air-powered actuator? The compliance is usually a killer.
>
On 4/24/2012 3:46 PM, upsidedown@downunder.com wrote:
> On Tue, 24 Apr 2012 03:59:16 GMT, Al Clark<aclark@danvillesignal.com>
> wrote:
>
>>
>> As far as I know, Microchip does not have a floating point device. Generally
>> speaking, floating point emulation is very inefficient with fixed point
>> processors and more times than not, a bad idea if you care about performance.
>> It's usually better to use a fixed point version of the function or migrate
>> to a device with native floating point support.
>
> How many embedded applications really do any heavy floating point
> operations ?
>
> OK, if you do a lot of floating point matrix multiplications and
> inversions with large arrays, a real HW FP is a must.
>
> However, in most cases the need for floating point processing in the
> embedded environment is simply due to constructs like
>
> sprintf (TextString, "Length %6.2f meters", Integer_cm_value/100.0) ;
>
> Thus, the total number of floating point instruction is typically very
> low and not justify any FP HW. Of course, the emulation code needs
> some space, so there are some tradeoffs to be made.
Has anyone here designed or even seen a high-performance servo with an
air-powered actuator? The compliance is usually a killer.
Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
Reply by ●April 24, 20122012-04-24
On Tue, 24 Apr 2012 10:29:32 +0530, "Anand P. Paralkar"
<anand.paralkar@gnospammale.com> wrote:
>Hope I do not end-up triggering a huge "Floating Point vs Fixed Point"
>debate here. I am trying to implement a PID controller for valve control.
>
>I read through a bit of the literature that is available on making a
>choice between Floating Point and Fixed Point. For a newbie in signal
>processing like me, Floating Point seems to be the easiest and safest
>thing to use. (Especially given the fact that it is going to be custom
>built and not destined for production en mass.)
>
>Your comments regarding the choice of processor or any aspect about PID
>control for valve positioning are welcome.
So this is about PID control using pneumatic actuators.
In practice, do you need sampling rates above 10 Hz, perhaps in
extreme cases perhaps 100 Hz ?
Any processor since the tube era should be able to handle this, with
or without floating processor hardware.
Reply by ●April 24, 20122012-04-24
On Tue, 24 Apr 2012 03:59:16 GMT, Al Clark <aclark@danvillesignal.com>
wrote:
>
>As far as I know, Microchip does not have a floating point device. Generally
>speaking, floating point emulation is very inefficient with fixed point
>processors and more times than not, a bad idea if you care about performance.
>It's usually better to use a fixed point version of the function or migrate
>to a device with native floating point support.
How many embedded applications really do any heavy floating point
operations ?
OK, if you do a lot of floating point matrix multiplications and
inversions with large arrays, a real HW FP is a must.
However, in most cases the need for floating point processing in the
embedded environment is simply due to constructs like
sprintf (TextString, "Length %6.2f meters", Integer_cm_value/100.0) ;
Thus, the total number of floating point instruction is typically very
low and not justify any FP HW. Of course, the emulation code needs
some space, so there are some tradeoffs to be made.
Reply by Al Clark●April 24, 20122012-04-24
"Anand P. Paralkar" <anand.paralkar@gnospammale.com> wrote in
news:9vmvu9F8amU1@mid.individual.net:
> Hope I do not end-up triggering a "Floating Point vs Fixed Point" debate
> here. :) I am trying to implement a PID controller for valve control.
I don't think this application will trigger the float/fixed debate. I think
the others have given you good advice. Understand your system requirements
first.
PID controllers do not take very many MIPs, at least with slow mechanical
systems. Any DSP will probably have MIPs to burn. A SHARC would probably
use less than 1% of its theoretical computation power.
Since this is a limited production application, the cost of the processor
is irrelevant. I would use whatever you want to become more proficient at
once you understand what you need to implement.
If you want the easy option of using either fixed or float then a SHARC is
a good candidate (perhaps ADSP-21489) since it does both equally well (32
bit fixed or 32/40 bit float). The TI camp can probably make a similar
case.
Al Clark
www.danvillesignal.com
>
> I read through a bit of the literature that is available on making a
> choice between Floating Point and Fixed Point. For a newbie in signal
> processing like me, Floating Point seems to be the easiest and safest
> thing to use. (Especially, given the fact that it is going to be a
> custom built product and not destined for production en mass.)
>
> Your comments regarding the choice of processor or any aspect about PID
> control for valve positioning are welcome.
>
> Thanks,
> Anand
>
>