A visit to Lucas Mesu's workshop

[tonyowens_uk]

On 23/08/2024 at 22:25, orly_andico said:

I'm a big fan of Howard's work with Onstep and have been following it since the earliest days. I think a bit of the approachability and simplicity of Onstep was lost with everything that's been added to it. The early Onstep was something I could understand code-wise, the new versions, not so much.

But to the cost point: the Swiss Maxons aren't cheap - because they are Swiss made. I think they are $200 a pop each. My 15-year old Mach1 has Maxon servos. Interestingly.. the last Mach1's and all of the Mach2's now use steppers.

You can buy 2 for $20 NEMA17 steppers out of China... or a $200 model made by Vexta in Japan (in other words, Maxon price). There's nothing inherently inferior about steppers - they are made to a price, but the price spread is huge.  Just as there are cheap servos (like the infamous Igarashi - Japan, but made in India - servos with the infamous 8/3 harmonic in the gearbox, used in Celestron CGEM mounts).

One of the major reasons for the proliferation of OnStep and the cheap steppers is the 3D printer industry, which is far, far larger than the telescope mount industry. Many of the 3D printer boards (at least, the older ones like the MKS Gen-L which were Arduino-based) can run Onstep directly. And they already have 4-axis stepper control (X, Y, Z, extruder) so you can run RA, DEC, and focuser, and a rotator off one of these $30 3D printer motherboards.

About Onstep I entirely agree Orlando. I once saw Onstep as a way of making precision imaging mounts for a variety of purposes without being locked into a commercial ecosystem such as Synscan, or Scitech which I have no influence on. While I love the fact that some ESP32-based printer controllers can be turned into 4-axis motion controllers for a telescope, I prefer to stick with traditional motion control architecture that uses separate motor drives and a step/direction interface. This should in principle make integration of closed loop steppers (integrated stepper/encoder/drive packs) or any other suitable motor technology possible, without need to refine the Onstep firmware. But it isnt clear to me, from the Onstep forum posts I have looked at, how to put together an Onstep firmware/hardware/ALPACA driver configuration that can do this.

And why am I interested in doing this?
For low friction mount types e.g. roller-drive friction mounts or staged or differential timing belt designs, microstepped steppers that can exploit the vast low cost industrial base of stepper-based motion will deliver excellent open-loop telescope pointing, with OK high speed dynamics (for most use-cases), provided autoguiding is being used for position loop closure. But for high friction mount types e.g. worm gearing, closed-loop axis control is required to consistently build a mount that will deliver RMS tracking good enough so that autoguiding is unnecessary.   Given that no Onstep platform I am aware of currently supports at least two high-speed BISS interfaces that would support high resolution axis encoders, the only current way to provide closed loop motion with Onstep would be by using the step/direction interface and using a separate motor drive that has such an encoder interface. Or using integrated motors, as I mentioned. Or am I missing something? 

[orly_andico]

Hi Tony,

 

OnStep uses these little stepper carrier boards (e.g. A4988, or the TMC2230 SilentStepStick) that *all* have step and dir inputs… I imagine you could just pop off those little stepper boards and wire the step/dir wires to your high-end stepper control box (which aren’t cheap either.. I saw some 5-phase Vexta’s for $500 ish per axis).

 

I’m not certain on-axis control is that easy. AP, 10Micron all do it, but the axis encoders are very expensive. I built my own axis encoder using Renishaw magnetic read heads and a tape, but the encoder wheel had to be huge given the low resolution of magnetic encoders versus optical.

 

The whole encoder concept has been beaten to death, but it’s a solved problem if you have the big bucks for a Renishaw *or a Heidenhain*. It’s when you try to build to a small budget that you get oddities like the interpolation errors in iOptron encoder mounts.
 

I got a quote for Heidenhain absolute encoders at roughly $600 per axis. And they were 24-bit. But extremely dodgy - they use a 2048 slot wheel internally and use a heck of a lot of interpolation. The SDE of that encoder was something like +/- 20” - plenty for an elevator or CNC control, but no good for a telescope mount.

Edited September 5 by orly_andico

[orly_andico]

Incidentally, I was reading the Baader patent (the basis of the encoders built into 10Micron mounts) and figured a high resolution webcam with a microscope objective screwed to the front, would have sufficient magnification to achieve sub arcsecond resolution with a sensibly sized encoder disk (say 6” diameter) with a 2D barcode on it for absolute positioning. Basically you use pixel displacement between images to measure the angular speed, but if there is a slew, movement will be so fast that the microscope and camera can’t keep up - which is why you’d need hard coded angular positions on the encoder wheel every few degrees to recover the axis position.

[tonyowens_uk]

On 05/09/2024 at 21:04, orly_andico said:

Incidentally, I was reading the Baader patent (the basis of the encoders built into 10Micron mounts) and figured a high resolution webcam with a microscope objective screwed to the front, would have sufficient magnification to achieve sub arcsecond resolution with a sensibly sized encoder disk (say 6” diameter) with a 2D barcode on it for absolute positioning. Basically you use pixel displacement between images to measure the angular speed, but if there is a slew, movement will be so fast that the microscope and camera can’t keep up - which is why you’d need hard coded angular positions on the encoder wheel every few degrees to recover the axis position.

You saw that patent too, good Andy! That, together with the motion control strategy and Dave Rowe's sky pointing modelling code have given 10Micron a huge pricing advantage in the market for professional-oriented mounts. But there are other routes to 23-24 bit angle encoding. I was an early user of Netzer Precision's capacitive encoder technology for precision automated assembly machines using a servo-controlled 'dial plate' and found their encoder easy to install without the ultra-precision positioning of read-head and engraved ring that optical encoders impose on assembly. Some of these capacitive, magnetic or inductive options offer high resolution 'on paper', even high repeatability, but it is hard to find non-optical techologies that offer actual accuracy anywhere near 23 bits. The Netzer encoders I believe they go to 21 bits repeatability, perhaps 22 bits (i.e., not enough), but the actual quoted accuracy was closer to 18 bits. Pricing per axis was comparable to your modular Heidenhains. There are other options from the UK and China that also are worth exploring, particularly Chinese options. I have a mount upgrade project starting soon that is likely to involve this FWIW. 

[orly_andico]

18 bits is 256K counts, more than enough for telescope RA axis tracking. I would be curious as to what is the SDE in arc-seconds, because the axis would move with the error…