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
