Hello,
What you are talking about here is a rotary transformer (resolver). I have
not put
much thought into a rotary transformer interface as of yet, however I may
make one in the future. Keep in mind, however, most of the (older) rotary
transformer applications were done by sending a pair of PWM signals to the
stationary windings (sine/cosine), the resulting signal from the rotor
winding was used to produce an analog voltage to control the motor amp.
The motor would run to move the rotor to where there was zero output from
the rotor winding. (There was usually a motor tachometer signal that was
inverted and mixed with this, so the error in position was converted to a
speed.) Jogging was accomplished by setting the sine/cosine to the rotary
transformer to the destination position, then overriding the output from
the rotor winding and forcing the amp input to a specific voltage while
counting the zero crossings from the rotary winding. When the destination
is within the last zero crossing, the amp override is removed, and the
output of the rotor winding (and tach) is used to settle into the final
position. (At the end of the day, this still ends up as the same concept
as ignoring the quadrature and only counting index pulses above a certain
speed as I had discussed before.)
I have seen some newer methods that simply convert the rotary transformer
signals to counts which are read by a computer which does some
calculations to come up with motor driving values, and while many claim
that these work just as good as the old analog stuff, I have yet to see
this proven in the field. (I am sure I stepped on a few toes with
that comment, and many are likely to disagree, but I must point out
that those old designs used DC brush motors and analog amps, the only
digital signals were the PWM inputs to the transformers, the result
was a VERY smooth operation that has been proven as difficult to
obtain with much more complex digital control.) Also, while I am on this
subject, the
electronics that convert the rotary transformer signals to counts only run
a few hundred times per second, in some very high speed stuff I have seen
as high as 2 khz, but this is also VERY rare, because once the speed
exceeds a certain point, it is assumed that the resolver has turned more
than 180 degrees since the last check and this is simply added to the
result. This approach, given the inertia of the motor and every other
moving part causes a limited amount of change over time so it becomes
just as easy in software to determine if the transformer has turned
once or a hundred times since the last sample. The position of the
transformer can move
thousands of counts (or full turns) in either direction between checks
which is just fine
because the result is absolute within 180 degrees (90 or 45 depending
which transformer is used). So let's say that you check the resolver 100
times per second, this gives you a 3000 RPM before you
have to assume that the transformer has rotated more than 180 degrees,
then your next position reading is however many counts for 180 degrees
plus the current position. Once you cross the 6000 RPM mark, you simply
add the amount of counts for 360 degrees each time. Since the transformer
is usually mounted directly to the screw and not the motor, that
translates to 3000 SCREW rpms before you have to add counts. And by the
way, most rotary transformers are good for up to 200 counts per 180
degrees, after this point the distance between steps becomes inaccurate at
various locations due to manufacturing limitations. This is much less of a
problem with the analog approach I discussed above.
-Neil Whelchel-
C-Cubed
760 366-0126
- I don't do Window$, that's what the janitor is for -
Show business is just like high school, except you get paid.
-- Martin Mull
On Mon, 31 Mar 2008, Mario. wrote:
> The very basic motion resolution. Say you want a 1um resolution of a
> step (no matter how of whether you achieve that), but you also want to
> keep maximum traverse travel speed of 2m/s. That would need 2 milion
> steps per second. (Now we don't discuss that without linear drive you
> can not have accuracy better than 50 microns ;-)) All I asked for is
> GOOD *output* resolution. You simply NEED to have the potential there.
>
> As for the input... the encoders used for high microstep rate per
> second are all analog sine/cosine, so that the 14-bit ADC resolution
> (used to be 12-bit and 14-bit, not 16-bit up to 18-bit is possible) is
> capable of those say 100KHz per second. Say you divide those 10
> microsecond whole sine/cosine periods into only 100 parts and you
> suddenly ended with some 10 milion microsteps per second.
>
> Canon makes LCD litography equipment and the old projector could move
> the positioning table (with about 2x3m glass on it) 500 milimeters in
> half a second. All with acceleration, deceleration and precise stop in
> the accuracy better than 1 micrometer. How many quadrature output
> changes per second would that equal as a maximum?
>
> The theory behind this is this: the machine will be only slightly
> expensive if we make it 100% faster. But 100% faster in two-three axes
> translates up to 2-3x the production speed! (or so..) In other words,
> if you do a lot of empty moves, a faster machine will beat the slower
> machines.
>
> On 3/31/08, Neil Whelchel <[EMAIL PROTECTED]> wrote:
>> Hello,
>> It is too early to tell what the reasonable maximums are, I will have a
>> better idea when I build a few modules. However, I have plans to count 16
>> bits worth of changes, so reading the register 10 times a second would be
>> able to count just about 65536/2*10=327680 per second. With an encoder
>> with 1024 counts per rev, this works out to be 327680/1024*60=19200 rpm!
>> The microcontroller will be able to handle up to about 4.5 MHZ worth of
>> input pulses. I see the major limiting factor here as the response time
>> from the encoder itself, there are very few encoders around that don't
>> start missing pulses at around 150 khz, ones with less counts per rev can
>> usually exceed this however, but look at the resulting RPM..
>> Also, when very large RPM ranges are needed, a common trick is to use 2
>> encoders, one with a high pulse count for fine positioning, and another
>> with a low pulse count for high speed rough position. When the RPM falls
>> below a certain point, a calculation is made to determine the offset to
>> the high res pulses, and the handoff is made. (This is sometimes done in
>> the same physical encoder using only the index pulse above a certain RPM.)
>> What could you possibly need 100,000 counts per second for?
>>
>>
>> -Neil Whelchel-
>> C-Cubed
>> 760 366-0126
>> - I don't do Window$, that's what the janitor is for -
>>
>>
>> Intolerance is the last defense of the insecure.
>>
>>
>> On Sun, 30 Mar 2008, Mario. wrote:
>>
>> > Okay, if you can do turnaround of at least 100 thousand output hardware
>> > changes per second, I'm in. Quadrature outputs.
>> >
>> > On 3/30/08, Neil Whelchel <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Hello,
>> >> I guess I should have been more specific when I was discussing the
>> >> topology about connecting to a WAN, or even a non-related internal
>> >> network. I had intended to imply that
>> >> the WAN/LAN and the module network would be separate, one network card for
>> >> each. However, with a proper VLAN switch, I feel that it MAY be possible
>> >> to combine them, but I am not going to spend any time on that. ;)
>> >> I have looked into a few realtime Ethernet papers and implementations such
>> >> as Rtnet, Rether, and MicroNet, and it appears that Rtnet has most of
>> >> what is needed for the host side (if not work just fine as-is). However
>> >> for the I/O module side, the Ethernet stacks by Atmel and the like are
>> >> nearly useless to me because they are targeted
>> >> for much more complex (expensive) microcontrollers. (The compiled
>> >> Atmel stack is nearly 3 times the size of the total flash of the
>> >> microcontroller I am considering using.) Call me cheap, you'd be
>> >> right, but why throw all of the complexity and money at it when it is
>> >> likely that the cheaper, simpler approach is likely to provide the best
>> >> answer.
>> >>
>> >>
>> >> -Neil Whelchel-
>> >> C-Cubed
>> >> 760 366-0126
>> >> - I don't do Window$, that's what the janitor is for -
>> >>
>> >>
>> >> Can anything be sadder than work left unfinished? Yes, work never begun.
>> >>
>> >>
>> >> On Sat, 29 Mar 2008, Jon Elson wrote:
>> >>
>> >>> Neil Whelchel wrote:
>> >>>> Hello,
>> >>>> I have joined this list because I an working on a project to convert my
>> >>>> old CNC mill and manual lathe to EMC and I saw that there are what seem
>> >> to
>> >>>> be limited methods of interfacing EMC to the outside world, and I think
>> >> I
>> >>>> might be able to help in this area, among others. Sure there is the
>> >>>> parallel port, and a hand full of (supported) ISA and PIC boards, but
>> >> none
>> >>>> of them seem to provide an optimal interface, and others are simply not
>> >> in
>> >>>> the right price range to make a project feasible. I have been tossing
>> >>>> around the idea for a few months now of creating some very cheap (open
>> >>>> source) microcontroller based I/O modules that communicate using
>> >> Ethernet
>> >>>> at the layer 3 level (Network Layer).
>> >>> There is a real-time Ethernet driver already in existance, but
>> >>> there are a number of restrictions on how it works. Also, these
>> >>> restrictions means it won't work with off the shelf ethernet
>> >>> micros and their off the shelf ethernet stacks, such as Atmel
>> >>> and NXP make. At least, that was my understanding. Whether the
>> >>> micro's library can be adjusted to make it work with the RT-net,
>> >>> I don't know. The RT-net requires total isolation of the RT
>> >>> part from the WAN with a router that can handle the RT-net
>> >>> flavor, so that pretty much has to be another computer with two
>> >>> ethernet cards/ports.
>> >>>
>> >>> I wanted to provide an ethernet interface to my boards, which
>> >>> are parallel port based right now. But, this was just over my
>> >>> head and beyond the time I had available.
>> >>>
>> >>> Jon
>> >>>
>> >>>
>> >> -------------------------------------------------------------------------
>> >>> Check out the new SourceForge.net Marketplace.
>> >>> It's the best place to buy or sell services for
>> >>> just about anything Open Source.
>> >>>
>> >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> >>> _______________________________________________
>> >>> Emc-developers mailing list
>> >>> Emc-developers@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>> >>>
>> >>
>> >> -------------------------------------------------------------------------
>> >> Check out the new SourceForge.net Marketplace.
>> >> It's the best place to buy or sell services for
>> >> just about anything Open Source.
>> >>
>> >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> >> _______________________________________________
>> >> Emc-developers mailing list
>> >> Emc-developers@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
>> >>
>> >
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
