If you are having trouble getting consistent focusing results, please READ THIS BLOG!
I recently finished working on a focuser plug-in for the Rigel Systems nFOCUS/nSTEP stepper motor focuser controllers. They are very versatile products that work with a variety of stepper motors. Not only can you replace any stock RoboFocus system with it, you can drive just about any kind of home brew stepper motor system the tinkerer crowd may dream up. This new support will be in the next daily build for both Windows and Mac.
My test system consisted of a belt driven focuser that rotates a camera lens focusing collar, and it was sitting on the desk next to me while working on this. I noticed almost immediately that there was a significant dead zone whenever I changed the focus direction. Previously I had been using a RoboFocus controller for this, and the RoboFocus has a built-in backlash setting. In fact, the RoboFocus requires a backlash setting of at least 2 steps. The nStep however did not have a programmable backlash setting, and to be useful to my own purposes as well as end users I knew I would have to add software backlash compensation myself. As a programmer it's easy to just write code that says "set backlash compensation to XX value", send it to the device, and be done with it. You really don't even need a deep knowledge of what backlash compensation is doing, and I have to confess up until now at least on the RoboFocus controller I'd been treating the backlash setting like a magic "black box". When enabled, it seemed to my casual understanding that it simply moved an extra amount in one direction to take up the slack, and then would back up. My assumption was that if you just put in a large enough number (larger than the backlash), it would just always work. I could not have been more wrong.
Implementing backlash compensation requires a more careful consideration of what is going on, and I even spent time on the phone with the smartest mechanical engineer I know (Steve Bisque!) wrapping my arms around this, and confirming that what I'd just "figured out" was actually well known and understood already by just about everyone else but me.
Here's the issue. Let's say your focuser is at position 100, and you tell it to move to position 150. If you are moving in the same direction that you were previously, then moving 50 more steps will get you to position 150. If however you have changed direction, and there is let's say 5 steps worth of "slop" in the gear train, then moving 50 steps from position 100 may only get you to position 145. The implications of this are obvious if your focusing; if the backlash is anywhere close to the size of your critical focus zone or larger, then the computed position from @focus2 cannot simply be reached by a simple move command sent to the focuser.... unless, the focuser/plug-in has knowledge of how much backlash is in your system!
Repeatability is the key to reliable focusing, and if your focuser has backlash, you will have to figure out some way of determining how much it is, and either your focuser controller (ala RobFocus, Optec, etc) needs to know, or the plug-in (nStep) does so it can take this into account when it receives a focuser movement command. For the focuser system shown in the image here, I have several lost steps in the motor itself when it changes direction, plus a few in the camera lens assembly itself.
The important underlying concept is that these steps of backlash are "lost". You can't simply go an extra bit and then backup to the specified direction. The focuser controller (or software) has to know that when you change directions it needs to offset the position value from the hardware by the backlash amount (or if the hardware has this built in the software end is home free). The simplest way to implement this is to pick a direction (forward or backward), and apply the backlash offset when moving in that direction. When you initially change directions you have to move the extra backlash amount, then backup by the backlash amount. Further you have to do this every time because if the movement is less than the backlash amount, there is no other way to reach the desired position. These are of course details for the engineers, not end users. What the end user has to figure out, is how to determine what the backlash of their system is.
First, if you spend $5000.00 on your focusing system, you probably don't have any backlash to the amount you need to worry about. Down in the $500 crowd though, we might have some issues. The first thing I tried to determine my backlash was to watch the motor. I could see/feel even a single step on the motor, and I could count... 1... 2... up to 6 steps when changing directions before the motor "grabbed" in the opposite direction. How much backlash was internal to the lens assembly was anybodies guess, so I took to the stars. I setup outside on a somewhat clear night, set the backlash to 6 and did two @focus runs back to back. My best focus was about 3.3 pixels. I then gradually started increasing the backlash and at first there was no change, then suddenly, I started creeping down 3.1... 3.0... 2.8... 2.6... finally around 2.4 it started going back up again. 17 steps of backlash compensation and I now get repeatable good focus every time.
Two more things bear mention on this topic. On a traditional drawtube type focus arrangement, you often have gravity pulling the camera/etc. down. This often cures the mechanical backlash and only whatever gear train backlash within the motor remains, and often this is less than your critical focus zone. If you have really fast optics (f/3 or so), well, this is going to be tricky and you should not skimp on your focuser purchase. The second is that with backlash compensation you have "lost" a range of focus positions. Every time you restart the system, there is no real knowledge of where it "is" +/- the backlash range. It is possible that the best focus position could actually drift from night to night continually in or out as read by the focuser controller, even though the actual physical position has not changed. I have heard of at least two reports of this happening with a RoboFocus system in the distant past, and I now wonder if the size of the drift was related to the size of the set backlash.
07-17-2016 9:24 AM