Some progress on this rotary table

This is all regarding this old Troyke CNC rotary table that I wanted If you recall, the latest stumbling block with the rotary table was
that it was using a old technology "resolver" for position feedback.
I was able to get a hold of Joe at Harowe, who made this resolver. Apparently, this resolver is still in surrent production and sells for a modest sum of $1,423.00.
http://www.dynapar.com/Accessories.aspx?sPartNumber BRW-300-F10/10
Joe emailed me a diagram of this motor with all electrical information.
http://igor.chudov.com/manuals/Harowe-Resolvers/11BRW-300-F10-10.pdf
This looks like super duper space age technology from very many years ago and is, apparently, a high quality product that is likely in good shape.
So, at this point, I have two routes to take:
1) Attach a shaft extension in the back and a new encoder from US Digital or 2) Add a resolver to encoder converter.
Both have the same cost, these ir some machining involved in both cases. In the first I have to add a shaft extension, in the second I have to add an enclosure for the converter and a plug/receptacle to the rotary table. This is so, because I may need to unplug the rotary table and remove it from the mill from time to time.
After some thinking and talking to EMC guys on IRC, I will go with the resolver. It is, in a certain way, a better device (though far more expensive!)
This is so because if the encoder misses a pulse due to noise, it eventually recovers the absolute position. Plus they are more "crap-proof".
i
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Aug 3, 3:35 pm, Ignoramus30076 <ignoramus30...@NOSPAM. 30076.invalid> wrote:

Iggy,
With your background you can appreciate the electronics of the conversion. Some texts will tell you that the rotor is energized with a sine wave, and the Sine Cosine outputs are quadrature decoded to find the current position of the rotor. This sounds straightforward, but in fact by definition the Sine and Cosine levels will rise and fall to zero as the rotor revolves. This makes the detection circuitry susceptible to noise. The difference between the Sine and Cosine signals indicate the rotary position. Another method to read a resolver position, which I found to be technically superior, was to drive the Sine Cosine coils with digitally synthesized Sine Cosine signals. The rotor coil then became the sensing element.
As the rotor rotates, the signal from the rotor coil will be a fairly constant amplitude, but will vary in phase relationships to the Sine/ Cosine drive signals.
To summarize the circuit, there is a master counter that counts up to the maximum resolution of the resolver, and resets. The output of that drives the Sine and Cosine lookup ROMs which drive the D/A and drive the Sine/Cosine Drivers to the resolver. The rotor signal is simply fed to a Zero Crossing detector. When it detects a Zero crossing, the current value of the free running counter is captured, and that is the current position of the resolver. So, it acts as an absolute encoder. The signals from the resolver are always at full amplitude, and only timing of the zero crossing point determines the absolute position.
I thought you would fine that interesting, from a design point of view.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

http://www.analog.com/library/analogdialogue/archives/38-08/dds.html
Decoding the I and Q (Sine and Cosine) signals in digital radios was done in software and I have no experience with it.
jsw
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
That is exactly the design used for aircraft magnetic compass repeaters. Typically they use a 400 to 600 Hz oscillator as a reference. Steve
30076.invalid> wrote:

Iggy,
With your background you can appreciate the electronics of the conversion. Some texts will tell you that the rotor is energized with a sine wave, and the Sine Cosine outputs are quadrature decoded to find the current position of the rotor. This sounds straightforward, but in fact by definition the Sine and Cosine levels will rise and fall to zero as the rotor revolves. This makes the detection circuitry susceptible to noise. The difference between the Sine and Cosine signals indicate the rotary position. Another method to read a resolver position, which I found to be technically superior, was to drive the Sine Cosine coils with digitally synthesized Sine Cosine signals. The rotor coil then became the sensing element.
As the rotor rotates, the signal from the rotor coil will be a fairly constant amplitude, but will vary in phase relationships to the Sine/ Cosine drive signals.
To summarize the circuit, there is a master counter that counts up to the maximum resolution of the resolver, and resets. The output of that drives the Sine and Cosine lookup ROMs which drive the D/A and drive the Sine/Cosine Drivers to the resolver. The rotor signal is simply fed to a Zero Crossing detector. When it detects a Zero crossing, the current value of the free running counter is captured, and that is the current position of the resolver. So, it acts as an absolute encoder. The signals from the resolver are always at full amplitude, and only timing of the zero crossing point determines the absolute position.
I thought you would fine that interesting, from a design point of view.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Steve Lusardi wrote:

Yes, however it is of little benefit on the RT, with the resolver on the servo shaft, where a given servo shaft position equates to some 90 possible RT positions. If the resolver were connected directly to the RT it might provide some benefit over and encoder, but not when mounted to the servo. In this case I'd recommend Iggy just replace the resolver with another encoder, and sell the resolver to someone who needs it for a tidy profit.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

the
RT
I wonder if that might be a way to "remote" an encoder. Make the resolver into half a SlowSyn pair, and mount the encoder on the other one. ???
I still have reservations about the difficulty of extending that motor's shaft.
One thought came to mind, Ig:
I know there's a scant 1/8" of shaft "showing" past the bearing, but given the almost vanishingly small load that extension will be under, and given the quality of modern metalworking adhesives, I wonder if you could just make a short hub that fit snugly over the stub of shaft with the bottom of the hole in the hub milled flat to aid in alignment, and was secured with a permanent anaerobic adhesive.
LLoyd
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Lloyd E. Sponenburgh" wrote:

I seem to be missing the thread with details on the current resolver connection, but per the link I did see to the resolver it is a shaft connected device, so if the resolver shaft is connected to the motor, getting a shaft for an encoder connected to the motor should be simple enough.
If the resolver is a $1,400 piece as the link indicates, I'm sure Iggy can sell it for far more than the cost of the encoder and materials to mount it.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Pete, it is too late, I already bought a converter. Both solutions are not bad. The converter solution involves zero hardware modifications to the rotary table, but costs $150 more. It is possibly slightly sub-optimal, but it is very straightforward.
i
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 2010-08-04, Lloyd E. Sponenburgh <lloydspinsidemindspring.com> wrote:

Lloyd, I bought a resolver to encoder converter from Jon, I will simply mount it in the cabinet and it will be a done deal.
It was, possibly, not the best decision in terms of money, but in any case, both ways (new encoder or Jon's converter) would give me a solid, working solution. I think that I could have sold this resolver on ebay for $175. Too bad, I cannot be perfect every time.
i
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus30382 wrote:

I wouldn't count on it. I got two Harowe Controls Harosyn resolvers in excellent but probably used condition for $25 plus shipping in two different auctions. I have seen them listed much higher, but don't know if they actually sold for more. I definitely would not count on such a specialized item bringing in a lot of money. On the other hand, I have sold stuff on eBay that I literally pulled out of a dumpster for hundreds! I had a massively modified DeVry 35mm movie camera from the 1940's that went for something like $264, and some 30+ year old microfiche from IBM field service that the IBM corporate historian bought for $500! You NEVER know what something is worth to somebody else.
Jon
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I just saw a almost the same model by Harowe sell for $175.

Yep, many great examples abound.
Anyway, I am not losing my sleep over this and I will treat it as a learning experience.
i
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus16841 wrote:

Yep, it will work fine. I just would have gone the USD encoder route for consistency between axes as well as the machining challenge of adapting the encoder to the motor.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Lloyd E. Sponenburgh wrote:

If you've ever played with selsyns, you know that an unamplified selsyn is a VERY sloppy device. It can move a pointer to within a degree or two, which is certainly good enough for many human-readable displays, but is in no way comparable to the accuracy of a resolver and resolver angle detector circuit. The particular one I use is good to 4096 encoder counts/rev, or 5.2 minutes or arc. The resolver in question in Iggy's rotary table is guaranteed to be accurate to 10 minutes of arc. That is because it is a size 11, ultra-miniature resolver, the bigger ones are even better.
Jon
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Lloyd E. Sponenburgh wrote:

Well, it repeats every revolution of the motor, just as an encoder would do. So, you have to home it to establish the true position, then count from there. Everybody with an incremental encoder does the same, you have to home the machine when you start the CNC control program.
The problem with various machines where NEMA size 11 servo-mount resolvers are fitted is that they are only 1 inch in diameter, with a 1/8" shaft, driven through a shaft coupler. While you can certainly fit an encoder there, it is not a bolt-in replacement in most cases. Many of these machines have fancy housings that are very nice, and completely designed around these small sensors. Hardinge HNC and CHNC machines are all like this, and anything with GE 1050 and similar controls. There are a lot of them out there, and in many cases a $150 external converter starts looking pretty good compared to a major hacking job to fit another encoder in the same place.
Jon
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ignoramus30076 wrote:

The idea that after missing some pulses the resolver will recover absolute position eventually is pretty useless in this application, since you have something like a 90:1 drive ratio to the table, and knowing the motor is at position X tells you nothing about the position of the RT. If you loose pulses your RT will remain off until you re-home it. You should also not have any noise issues if you use shielded cables, and ideally differential line drivers and receivers.
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Pete C. wrote:

Actually, if noise has caused some error in the solution of the equation and then the noise abates, the resolver converter WILL correct the error and produce sufficient quadrature counts to get the computer back to the exact correct encoder count. Now, if the computer has counted invalid encoder counts due to electrical noise, that will not be corrected, but it is the same situation as noise on traditional encoder circuits. I don't see the difference there. Since Iggy will be putting a differential-out resolver converter in the same cabinet as the differential-input encoder counter, the chance of counting errors between them is extremely unlikely.
The only way the resolver converter will permanently mess up is if the noise is so great that it starts reading 180 degrees out of sync with the resolver. Then when the noise clears up, it could correct position going around the wrong way, or have lost entire revolutions of the resolver. In this case, the noise problem must be corrected.
The resolver provides a unique reading at any rotation, and the converter tracks that position. It does not produce "pulses" and therefore cannot "miss some pulses".
Jon
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 03 Aug 2010 15:35:15 -0500, Ignoramus30076

#1 consideration.. the converter can go inside the old control cabinet.
#2 consideration...never never never put a plug/connector at the rotary table. Run good quality shielded cable in a length long enough to plug into the control cabinet on the side or bottom away from the machining area and all chips and splash.
Gunner
"
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Yes, I am convinced.
i
Add pictures here
✖
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.