High resolution linear encoder & 7i77

akb1212 wrote:

Out of curiosity why don't you use an interpolator from iC-Haus? They have a BISS interface that will connect to the ISS ports on the Mesa cards. And you can have as many as you need. And you won't have any issues with speed being a problem. They come with up to 16 bit interpolation, and isn't expensive (about $90 for an evaluation board ready to use).

I'm trying to figure out if anyone else have tested this, but so far I haven't found anyone. PCW mentioned in a post he was waiting for his eval. board. But I haven't seen any results from that. Did you do that test, and did it work PCW? I'd be very interested in knowing. And also know more about how to implement it.

Anders

Maybe i will use iC-Haus interpolator if I can't use mine, but in any case, it will be in quadrature output. I have no benefit to run BISS interface, my speed is limited by my ballscrew.
Beside this; 12 bits is already a lot, and you will need a very low amount of noise with 16 bits of interpolation.

I have read your topic, maybe you can run dual interpolation ?
A high one for low speed/positioning mode; and an lower/none (rail to rail comparator) one for high speed (inertia will help you for stability).
Btw it's strange to talk in mm for a rotary axis, arc-sec or radian is the unit for angle.
If my calculation are good you are asking for a sub arc second (0.36 arc sec) accuracy with a low resolution encoder ? If you can't correct positioning accuracy (like ballscrew mapping but for an axis) it will be impossible.
Take a quick look at this: www.heidenhain.co.uk/fileadmin/pdb/media...Integral_Bearing.pdf
They got nothing accurate to sub arc-sec, and they are high resolution. You can make one but you will require interpolation and correction in software; with of course the right metrology tools to measure/correct.

Not meaning to discourage you but you are asking to much for a little encoder.

I finally found a YouTube clip demonstrating something along the lines of what I want:

As you can see in the video this is a direct driven servo motor, not very unlike my setup where I have a direct driven induction drive. With high resolution encoders and a good drive I'm hoping to be able to get something similar, although I realize the resolution and accuracy here is more than I can hope to achieve.

But to give a quick summary, they use a high pole count (8 or 16) permanent servo motor. This makes it possible to get very high torque at the cost of having lower max speed. In this case 500 RPM. With a normal 2 or 4 pole motor we can expect to loose some low speed accuracy, but gain in the top speed. My spindle will have 5000 RPM at 254 Hz.

They also state they use sin encoders. We can assume they are interpolated, just like we talk about here. The question is how many periods/rev they use, and how many bits they use for interpolation.

The accuracy they get are 0.0001 inch, or 2.54 um at a radius of 27 inches, or 685.8 mm. This gives 1,696,460 counts/rev, or 0.76 arc sec resolution.

Now to be able to get motion with this repeatedly is impressive! That would mean the system have an internal resolution possibly 10 times that! after all it's not possible to get repeatability of 1 arc second if your encoder have 1 arc second resolution. To be able to achieve that repeatedly and reliably like they have in this clip they will have to have 10 fold the resolution internally.

Now since this axis has a limited speed of 500 RPM they can (and should) increase the resolution on the encoders used.

The Heidenhain encoders you linked to would most all of them fit right in this range. Many of them comes in resolution in the 10,000 to 150,000 pulses/rev, all in sin/cos. Which mean if you use 10 bit of interpolation you can get 10,000,000 to 150,000,000 counts/rev.

Now this is high enough to do what's shown in this video and then some. So I don't understand what you are saying when you say the mentioned encoders aren't accurate enough.

Now to get true micrometer accuracy at the radius mentioned here would obviously demand highly accurate mapping and temperature compensation and what not. Not something any of us using LinuxCNC would ever dream of.

The main goal for me with wanting this high resolution is to be able to calculate speed in an accurate fashion at low speeds. If you look at even low priced servo/drive system from china they use 20 to 22 bits/rev resolution encoder system these days. And that is because it's easily and cheaply available now.

500 p/rev sin/cos encoders and an iC-House chip is all it takes to get ~1,000,000 counts/rev resolution (not repeatable accuracy that is, resolution only, with spread and inaccuracy between steps). The BISS protocol is an open standard which will handle this easily and reliably. So there is no problem for any of the servo system manufacturers to take advantage of this. They also have magnetic solution with similar capabilities that are even cheaper (as you don't need an analogue encoder).

The question is when LinuxCNC users will start to do the same. I'm hoping we can get out of the limitations quadrature encoders impose. In the same way most of us now have gone beyond the limited frequency possible when using a parallel port for direct step/dir signals as used to be the standard way back when it used to be called EMC2.

Anders

What you see on youtube is quite similar on what i'm working. Keep in mind they only show us repetability, not accuracy.
I use little (30Nm) and very big (15000Nm) Torque motor on my job, I know them very well. (working on motion simulator for calibration of MEMS/FOG).

I took a look on Kollmorgen product they say it's 136 million resolution. I'm not surprised to see sin/cos encoder with; of course; interpolation, at least 12 bits.
More resolution = more speed stability at low speed; and It's more like 100 time more resolution to get accuracy, especialy with high dynamics.

If you look at IC-haus interpolator they "only" sell 16 bits interpolator, that gives you a resolution multiplied by 65536 ! You're 500 line count encoder just became a 32 millions count/rev.
Sin/cos encoder works with 1 Volt of signal, if you divid it by (number of bits) interpolator will give you a change of output value every (1/16=) 62.5mV
It's fairly low, and easy to catch noise on this level.

I was talking about your encoder of 500 line/rev. To achive a resolution of 136 000 000 you will need a encoder of 2075 line/rev with 16 bits of interpolation, or 33203 line/rev with 12 bits.

Interesting! Could you elaborate more on what you are doing?

I would believe the Kollmorgen resolution would be 27 bits, or 134.2 million. At least everything would be easier to calculate with that..... This would be possible with 16 bits interpolation and a 2048 (11 bits) couts/rev encoders. Or higher number of count's/rev and lower interpolation. Not entirely impossible with todays available

And you are right, at these levels of resolution a factor of 100 is possibly more realistic. Which makes an even higher demand on the resolution needed to achieve the results we want.

And with most high quality interpolators that resolution would be "easy" to achieve with a high quality sin/cos encoder. The Heidenhain ones you linked to the catalogue would most certainly manage that.

And I'm fully aware of that they show repeatability only. An absolute accuracy of the level shown in the video would demand a lot! Very thorough calibration and absolute control of temperature and other factors. So I guess that's out of the question for most of us, including the ones who built the system in the video.

So the whole point in the high resolution here would probably be as you mention to get smooth operation at low speed. This way it's possible for the control system to have a high enough number of counts even at very low speed, even though the control loop is operating at a relatively high frequency.

That is my only reason for this as well.

I have a Maho MH600E with Heidenhain 20 uA sin/cos encoders on the linear axes. Now those encoders have a low level current signal coming out of them, not like modern encoders where they have a relatively higher level voltage.
That means it's not possible to interpolate them with as high resolution as it would have been possible if they were the modern ones.
Nevertheless I increased the interpolation rate from the original 5 time interpolation (giving me 1 um resolution) to 25 times interpolation (giving me a resolution of 0.2 um resolution).

Doing this with LinuxCNC made everything behave so much better! All motion is now very much more smooth and I was able to eliminate most of the hunting it was doing before the upgrade.

I have since learned that Heidenhain have up to 400 times interpolators to their 20 uA encoders. But those interpolator boxes are way to expensive as it is now. I was able to get the 25 time interpolators for a reasonable price, and for now I think I will stick with them.

And you are correct, 16 bit interpolation of 1V signals will be very sensitive to noise! In particular if you are using long wires. So the best way to implement this is to put the iC-Haus interpolators physically as close to the read heads of your encoders as possible. Possibly even inside of the housing of your encoder if possible!

But you are wrong on one important part though! iC-Haus do offer lower interpolation versions. In fact most of their interpolators have 13 bits, but they also have 8 bit ones.
Take a closer look here: www.ichaus.de/keyword/Interpolators
The only one with 16 bits even have the possibility to choose the interpolation rate all the way down to 4 times (that is 2 bit!) with hardware jumpers on the demo board. And for some reason the highest interpolation rate possible on the demo board is 10.000, not even close to 65536 which is 16 bits. I'm not sure about why this is, but 10.000 is more than enough for me anyway.
I remember reading about a LinuxCNC user who had problems with noise and had to reduce the interpolation rate, but I don't remember what interpolation rate he used. It wasn't in the absolute upper range.

Depending on how well I'm able to make this work on the rotary axis I'm considering it for the linear axes as well. It should be possible to convert the 20 uA signal inside the encoders to 1V/pp signals. And then use an iC-Haus converter to BISS in the same unit. Then feed those signals back to the controller.
The best alternative would be if iC-Haus decided to make 20 uA versions of their interpolators, but I guess that technology isn't as much used. So I can understand if they don't. But they do make 1V/pp signal conditioning chips though. So a dedicated converter chip would be an alternative. I'll look in to that if things work out well with the first attempt.

And Andy, thanks for the offer to check my hardware! I really appreciate the effort you and everybody else here offer for support. But unfortunately my encoder wheel is mounted on to my spindle, which will be next to impossible to transport to you. And being a precision piece of equipment adjusted and working I won't risk removing it if not absolutely necessary.

That being said, is there any one who have a working set of config files with BISS encoders in them? For now that is what's keeping me from trying to make it work in LinuxCNC. The information in the documentation isn't enough for me to make a working config. Not even by a long shot..... I will have to see a working example to have something to copy.
One major reason I need this is that BISS is supposed to be able to handle high speed movements (with reduced resolution) as well as slow movement (with high resolution). The whole point would be to not need two encoders or similar to achieve this. And this isn't straight forward in LinuxCNC as it is now. So I would need working examples of this to be able to make my own working config.
Alternatively I could try out configs you guys write for me and check if they work. But first I have to make my drive run the spindle. I'm working on that at the moment. I hope to have that working in not so long, and then start on the BISS encoder implementation.

Anders

Do you have any BISS hardware?

It should be pretty simple to test if you have a Mesa FPGA card,
a RS-422 capable daughtercard (7I44,7I74,7I47,7I47S,7I77,7I76,7I85, 7I85S etc)
and are running linuxcnc 2.7

late versions of linuxcnc 2.6 may work but I'm not sure if the DPLL is supported in 2.6
and the DPLL is needed for de-jitter and pretrigger of the BISS read cycle

I can finally say yes to that now.

I decided to order a demo card from iC-Haus, and went ahead and ordered the one I thought would do the trick.

That proved not to be as easy as I was hoping for. First I ordered the iC-TW8 card. That is the one with best resolution, and is possible to configure with hardware. It also has an automatic calibration feature, so I figured this was the best alternative.

That was until I discovered that this chip doesn't have the BiSS interface...... I wasn't aware they had chips without that, and just assumed all of them had that as standard.

Ok, RTFM....

So I started reading through the data sheets of the different chips they have, and soon found that the iC-NQC was the one they recommend as it is the latest version with BISS, and was supposed to supersede the other alternatives.

And sure enough, it has BISS. And it even has a very nice feature I haven't seen in the datasheets of any of the alternatives: It will adjust the resolution down as the input frequency goes up above the frequency limitation of each interpolation rate.

It will frees the LSB each time the frequency shifts above the limit of the present interpolation rate. And it will sense when the frequency shifts down again and update LSB again as normal.

This is in fact the feature I'm looking for to be able to use the 4th axis as both high speed lathe and highly accurate C-axis. By setting the max interpolation rate I need for low speed I will be able to get the accuracy I need when I need it. And I will get lower accuracy when I don't need it at high speed turning.

The downside with the NQC chip though is that it doesn't have the automatic calibration feature of the TW8 chip.

Then comes the real downside.....

All but one of their chips (a simple 8 bit interpolator, not suitable for my use) require external eeprom to store configuration and calibration data. And they sort of assumes you buy their USB-BiSS interface to do this configuration/calibration.
And that is NOT as cheap as the interpolator chips and demo-boards.

The question is if it will ever be possible to use the Mesa cards to do this calibration? From what I understand the chip will be able to program the eeprom. All that is needed is a driver to talk to the device through the BiSS compatible interface.

Even choosing what version of interpolator isn't straight forward. They don't have one chip with all the features I want. They all lack one or two of the features I'd like.

I have come to realize it won't be as easy as I first hoped to use these iC-Haus interpolators. I'm still hoping though, and if we could get them to give support here like Mesa do we might get somewhere!

They have more or less all parts needed to make DIY versions of high resolution encoderstoo, all for very reasonable prices. I will mention LinuxCNC as a possible way for them to make themselves a market here. I guess Mesa is as popular around here as it is because of the high quality support we get (so thanks Peter!).

Anders

I am trying to cummunicate with Etel DSB2P also, but unfortunatelly without success.
How did you manage to access DSB2P parameters from PC?
Thanks.

Hello,
With old PC on win xp, etel software version 4.xx.
Communication is made with rs232, and a cable with RJ-45 to connect on DSB2-P.
You can find wiring in the big manual.
You will also need knowledge, there is a lot of parameters.

About three months ago, I prepared hardware as you described (according to Etel manuals). But, catch is that I couldn't find Etel ett.exe software. Tried to search on Net- didn't find anything. Sent couple of mails to Etel representatives/cintact mails - got answer that they could not give me or sell me software.
Is there any possibility to get Etel software?

In meantime, tried to cummunicate to drive using simple 'telnet' clients. A lot od work, but didn't get successfull answer.