The stepsize is huge compared to what it is on the Sangaboard. I can increase the gearing in the printer.cfg and raise the max speed - this probably ends up with the same motion, but more steps in-software, so probably more repeatable movement.
Edit: I’ll also be trying to make a direct-drive Z actuator to see if settling time can be reduced further. It’s the most unstable motor, compared to the other two
Okay, changing the Z drive was the correct choice it seems. This is ~450 images in an hour, at 0.2 overlap like previously. I turned autofocus off, since that was something that was messing it up a lot for some reason? I use 0.1 settle time for consistency, used to have it at 0.07 and it worked fine too, with 0.05 having some blurry areas. Default is 0.3. I think the rubber bands are limiting going lower than 0.07, but maybe input shaping or other tricks can get this even faster.
I think next up would be to swap over X and Y to direct drive too. I’ll need to hammer out two holes in the base and hook up a fan on a rubber duct to keep the temps under control.
The coupling is a 3d printed part with a hole big enough to insert the long screw through it. The side with the stepper motor gets a woodscrew on the flat to keep it from moving. This makes it so the entire thing is really high off the mount, but I didn’t think of a way to avoid that. One additional thing I did, which can also be done for the regular large gears, is I screwed on a nut right next to the bolt head to give it additional stability as compared to just using the bolt head. This makes it so the screw doesn’t wobble as much. Crucial with the direct drive being so high up.
Edit: the scan died because I ran out of disk space. Will run another overnight
Edit2: Scan number two, timeouted again. I think I might have an idea on what’s happening, I’ll need to do some error handling to see if I’m right. For some reason, klipper just restarts sometimes, losing connection. This might make it so the request to the API times out and the exception gets bubbled up to the surface. Will try to make the timeout longer and see if it changes anything.
X and Y mounts printed and mounted. I sped up the stage once again by ~50%. I ran the stage calibration and saw 0 steps estimated for backlash.
Edit: Another scan, this time at 0.1 overlap
Edit2: I ran another scan overnight, the fix to the timeout situation seems to work great.
I’ve tidied up the repository and posted the FreeCAD / stl files and latest printer.cfg. With the fix to the timeout working and the latest multi-hour scan going through, I have removed the “work in progress” from the thread title and consider it good enough if someone wants to make their own to test the concept. It still isn’t ready “for the field”, since I’m powering it from a lab power supply. That being said, adding a DC socket and running a 24V 1A power supply brick is a matter of an hour or so of work. I’ll be messing around with it a bunch and seeing if I can find something that isn’t working well. I’ll also be adding instructions on how to setup everything and tidying up the code to create a PR to the official repo with the software / hardware changes.
Also, one thing I didn’t talk about much is that the setup is done on the SKR Pico, but should be universal to use any 3d printing board that can run klipper + moonraker on it. The printer.cfg file would need to be made with a specific board in mind, but it’s a config file that is provided for most of the popular boards - which can then be edited using the SKR Pico one as a template, to get it working with the OFM in mind. I chose the SKR Pico because of its form factor and it fulfilling all of the requirements of the project. A conversion from an old printer for example is very doable, though I haven’t tried doing that yet.
I’ve just caught up on this thread and it looks really cool 
Direct drive is something I’ve been curious about for ages, so it’s nice to see an implementation. I keep suggesting we try it with the current steppers, but I suspect the benefit would be less there as there’s so much internal backlash in those motors.
I wasn’t totally sure if you’d fixed the issue with autofocus - you probably already figured out that it will be quite sensitive to both the distance and the speed. When I used the OFM software with a commercial stage (from Prior Scientific) I had to dial the Z speed right down in order to make it work. I suspect a similar trick would be useful here: the default “fast” autofocus method relies on looking at the frames in the video stream during the move, which are 30fps. That means your move (from -dz/2 to dz/2) should take a second or two, otherwise there won’t be enough data points to find the focus.
You have probably figured all this out by now - I’d intended to reply ages ago but got distracted before I read to the bottom of this thread, sorry!
The amount of backlash I had with the gearing was very large comparatively, I wouldn’t worry about it being less of a benefit. Especially since to try it, you’ll just have to edit the connection file that I made to change the profile of the motor cutout to the 28byj and place the pillars in the correct position in the main body. Since @WilliamW already did that here, it should be pretty straightforward
I’ll work on the autofocus to try to get it working a bit faster. One of my ideas was to drop the resolution and up the framerate for the “fast“ focusing, but I haven’t really looked into how this all works in the background
oh cool, I hadn’t realised @WilliamW had beaten me to it!
It’s certainly possible to swap video modes and do autofocus at 100fps, though I’d wager the extra time wasted swapping video modes and waiting for the camera to stabilise would probably outweigh the increase in speed. Messing with the camera mode can be a bit of a can of worms, though, so it’s only worthwhile if it delivers a serious benefit. Swapping modes every autofocus might also cause camera crashes, for reasons I don’t yet fully understand…
I will watch with interest to see what you’re able to squeeze out of it!
Just wanted to clarify, WilliamW edited the body to accept the NEMA14 steppers, so it wouldn’t require the standoffs that I printed (and that was still assuming geared drive). I don’t think a direct-drive 28byj was tried, but once I have more time beginning of April, I might see how that looks.
Setup an accelerometer today. It screws in the stage, across it to align X and Y. The results vary by ~5hz from run to run.
#*# shaper_type_x = mzv
#*# shaper_freq_x = 83.2
#*# shaper_type_y = mzv
#*# shaper_freq_y = 88.0
It looks to be worse than previously?
Edit: might have just used minimal settings - overlap at 0.1, 3 images to test focus. I’ll run a more normal scan, at 0.3, 5 focus tests
Edit2: yeah this is 100% because of the very low overlap / focus sampling
Did you have the accelerometer in place when doing the afterwards measurement?
I suppose if the difference between having the cable and not having the cable shifts the response frequency enough then the vibrations could constructively not destructively interfere?
No, I have to disassemble it and assemble the slide raiser. Probably why it isn’t working well, since it’s essentially a totally different setup. One additional problem, is that apparently this chip is an older one that is less sensitive than it could be? We might be at the level of precision where we’re chasing additional zeroes and it might actually matter.
I’ll be messing around with all of this shortly again, though I would probably try to eliminate the autofocus overshooting first, since that’s a huge time improvement. I’ll also try simply disabling the resonance compensation. If I get noticeable improvement, then that means that we can calibrate it to get rid of it, we were just unlucky about it.
I ran a 0.1 overlap x40 scan of a sample I have. This ended up with ~40 mins with the alpha4 version of focusing, at 300 images. Really promising, I’ll be trying to get the time lower, which probably starts with me migrating the microscope over to a faster SD card and to alpha5. I’m also looking into a higher microscope to see if I can get the stage working area larger.
I have made a second prototype using the stepper motors, this one experimenting with a larger work area in addition to the steppers. I did mess up the Z axis though, which means it’s a bit more unstable than I’d like it to be. I hooked some velcro around the objective to help with that, though it isn’t perfect.
The issue I’m facing now is the changes to the stage classes and the jogging. Klipper is a look-ahead system, which buffers gcode commands. There is no way of realtime controlling of the microscope - specifically no “sudden stop” command.
I have changed the buffer to be minimal, seems to work, though there is now a hardcoded stepsize when using the arrow buttons. The app seems to ignore stage control preferences - instead sending stepsize = 600 all the time. Seems to be an issue in stageControlButtons.vue - line 97, “jogDistance: 600”. Line 124 also seems to ignore Z axis inverse setting.
Stage control preferences are ignored in Alpha5 when using buttons or keyboard (#760) · Issues · OpenFlexure / openflexure-microscope-server · GitLab though I guess with the jogging changes the sangaboard probably handles this differently and stops movement the second the button isn’t pressed down anymore
I think probably in the custom GRBL class for the the nema motors you may need to override how jogging works. GRBL does support jogging:
I’m not using grbl though, I’m using klipper and moonraker. Ultimately it isn’t possible because as I mentioned - klipper works “in the future”, so jogging would stop after like a second or longer after the user stops moving, since the buffer would be full of commands. Marlin is an alternative, especially since the SKR Pico supports it, and it has realtime features. This week I’ll try to make a working version of the current implementation and see if I can get the SKR Pico setup for Marlin instead after.
Ah sorry! In my mind klipper was an interface for GRBL in the backend. Don’t know why I thought that, but it very much isn’t.
