Hello, I want to say way is the way so set the 3 axis to zéro?
It will better for reduce tensions on the main body.
I don’t uderstand the full procedure to initialize my microscope.
Regards
1 Like
The microscope has not got any physical position sensors. The motors do have a memory of their total movement in steps which is retained when the microscope is switched off. This will be close to a record of the actual position, not accounting for creep, missed steps etc.
Initially you will need to set the step count to zero with the stage physically centred. The central position is with the legs vertical, or the base of the moving arms in line with the base of the microscope. Use the motors to move the stage to this position. There is then a button in the microscope interface to set the step counts to zero.
After that you can move the stage around, and if you want to return to the central position you enter 0 in the coordinates boxes and press move.
Ok thanx.
I have do that.
It’s nice now.
What is 1? A nanometer count?
What is unity of the coordinate.
Thank again for your many replys!
The count is in steps of the stepper motor. If you have the version that we use, there are 4096 steps for each rotation of the small gear on the microscope. 64 steps per revolution of the actual motor, and a gearing of 64. Set a 2000 steps move and see the small gear rotate about 1/2 turn.
The small to big gearing is x2. The M3 screw thread is 0.5mm per turn. I forget the lever ratio of the stage, about x2 again. With that you can calculate the nm per step.
1 Like
If I calculate correctly, it comes out to 107nm/unit for the standard build.
(The lever ratio is given as 4/7 in microscope_parameters.scad, which is the inverse; so 7/4 x 0.4 / 4096 / 2) .
(edited to include the gear ratio)
The number I hold in my head is 50nm/step, though that may be for the smaller stage (which has 1:1 lever ratio), so that’s about right. The motion is slightly less than the theoretical value because of bending in the plastic.
The units are half-steps: I believe there are 32 full steps per revolution of the stepper, but the recommendation is to drive it with half steps (i.e. instead of energising coil 1, then coil 2, then coil 3, you do ([1], [1+2], [2], [2+3], [3], etc.). That gives 64 half-steps per rev, and 1:64 reduction gearing inside the motor.
It’s also worth noting that the camera-stage mapping (auto-calibration available in the settings tab) will give you a pretty good estimate of how many half-steps of the motor there are per pixel in the image. If you take an image of a known object (like a calibration target) you can then get a calibration in units of actual distance - though currently the software only understands pixels and steps, it’s not units-aware.
At some point I’d love to get lots of people to run this calibration so we can assess how consistently the microscope is being reproduced - but we probably need to improve the documentation around how you calibrate it first.
1 Like
Perhaps this question fits in here as well:
The “Move-to” section in the guy, does it move to absolute or relative coordinates?
Once I press “MOVE”, what I’m supposed to see in the X,Y,Z fields and is there some display to show the current coordinates somewhere?
And one more question: For the autofocus, is it possible to change the stepsize with the “STEP SIZE” set in the GUI as well?
Thanks a lot! 
The Move To is absolute. The numbers in those fields change if you do moves by other methods, such as keyboard or click on the image to move.
When you manually change the numbers and click Move, it just goes to those coordinates.
The server has relative move and absolute move. In the GUI relative move is mapped to the keyboard using the step size.
I think the autofocus parameters are fixed, at least they are not in the GUI, may be in a config file that you could edit.
1 Like
Perfect! That’s exactly what I wanted to know!
Thanks!
The autofocus parameters are fixed in the GUI - you can specify the range etc. in the HTTP request if you make it yourself, but I’m fairly sure the GUI buttons are hard-coded. It’s that old trade-off between making everything super configurable and making it “just work”. It wouldn’t be hard to figure out a way to make it tweakable though, if that’s useful for you (I guess your GRBL code will need quite different step sizes?). On the other hand, you’re running on a fork anyway - so perhaps just pointing you at the right vuejs file to change the values in the interface would be more helpful?
Hey, again, something out of the blue: @WilliamW, I remember, that we were talking about the position update in the GUI. Is there any way to introduce a thread which reads out the position values periodically? Does this makes sense to you? In my case, the stage (GRBL), will update the location at the end of its motion, and the OFM GUI won’t recognize that of course because it thinks it’s done already. Maybe it’s a special case though.
I don’t know about the workings of the GUI code. Everything is HTTP requests to the server, so any refresh would need scheduling somehow in the GUI and it would mean more request traffic to the server which may have a time penalty that you don’t want.
I hope the overhead won’t be disasterous… raise an issue and I’ll see what I can do!