Hi,
I just finished the scope and all looks great, I only have a question, maybe I missed some documentation or is not there at all.
What’s the keyboard shortcut for Z movement?
Autofocus is hit and miss and would like to have some manual control.
Also, my steppers are getting pretty hot, is this something common?
Thanks a lot for this beautiful design,
Bogdan
Thanks - I believe page up/page down will move the Z motor, and you can set the step size in the “settings” section of the “move” tab. Autofocus should be pretty good these days - what sort of samples are you looking at? The fast autofocus algorithm isn’t quite as reliable as the old algorithm (still used for “medium” and “fine” but seems good for the majority of samples. I’d be curious to see what you’re looking at, if it doesn’t work nicely for you.
The motors should get warm but not painful to touch. It’s worth pointing out that you do need to drive them with only 5v, higher voltages will cause overheating and that’s been an issue for some folk. I swapped to these motors after having issues with the small NEMA steppers actually melting the plastic!
Thanks,
I found the shortcuts in the end but how can I change them?
I’m using a small keyboard and pgup and pgdown are in the same place with up and down arrows, I need to press Fn key in the same time to action them so it’s a bit messy. 
ah, I’m not sure there is an easy way to do that. You’d need to edit the Vue app that runs the interface, and then put a compiled version of that on your microscope. Possible, but there are a few development tools required 
It’s worth mentioning that the microscope does have built-in support for a USB SNES controller, if you plug it in (before booting up the microscope) it will then give you hardware buttons for moving, autofocusing, and taking a picture. I paid about £3 for mine, it’s definitely more fun than the keyboard!
Does the wireless version is compatible too or do it only work with USB wire version ?
Can it be native compatible with orther controller band ?
Ahaha that’s beautiful, I have one for my Retropie, fill definetely try it. 
I just try with a Nvidia shield controller, and it work so I think any kind of Xbox compatible controller will do the staff to.
That’s cool - we’ve not tried with anything other than the SNES controller. I’ve no idea if it will work with a wireless one (is that bluetooth?). The library that supports it was written by @j.stirling in an afternoon while travelling in Tanzania, and it just looks for Linux-compatible controllers. @Gris74 did the controls map to sensible buttons?
Yes, but if you mean by that gradable movement so it is not working, and the move step is too small … their is a way to adjust the step movement ?
I think the “SNES client” as it’s called will make successively larger movements if you hold down the button - so it starts with small steps (so that you can move a small distance by tapping the button) and then takes larger steps (so that it’s sensible to hold down the button for a while, and the microscope moves pretty much at its top speed). Is that not what happens? or is it just that the motors are very slow?
There should be a button to switch from fast to slow mode. I added in as part of the “jungle hack” version of the client when I was using low mag objectives in the rainforest in Panama. I am pretty sure this is now merged into master.
Really exciting to hear that it works with other controllers. I did set up a USB N64 controller once.
I have an issue open with a suggestion to add some code to sangaboard which releases the motors when not actively moving - it should reduce the heat and power consumption quite a lot: https://gitlab.com/bath_open_instrumentation_group/sangaboard/-/issues/10
Any progress on a method for getting the motors to turn off after a timeout period of say 5 minutes? Mine are getting hot and I tend to walk away from the microscope and come back 20 minutes later and it’s worrying me how hot they are.
I am just using 5V to power the motors so I imagine they’re getting this hot for everyone else. I can still touch them and not get burned. I haven’t seen any plastic melt either, but I now find that I tend to reboot the Raspberry Pi just to get the motors to turn fully off on reboot, or now I’m SSH’ing in and restarting the ofm restart just to get the motors reset.
It would be wayyyyy nicer to have the ofm server software just ask the Arduino to turn off the motors, or have the Arduino code do it which is the way CNC control hardware that runs on microprocessors is doing it these days like Grbl or TinyG.
BTW, in the CNC world, running your stepper motors on a higher voltage actually helps them run cooler but that tends to work when you have chopping stepper drivers like the DRV8825. I haven’t tried running these little steppers on the microscope at 12v, but it’s possible that actually would help the heating problem.
Thanks @wschalle and @jlauer I agree we need to look into this. We are pretty scattered during lockdown which has made easy access to hardware some what difficult. We have just ordered a bunch more Sangaboard for the lab so hopefully one of us will get to this soon.
The difficult thing is trading off the fact that we will loose steps when de-energising as there is tension in the system. But I agree that after a configurable time we could send the command. @jc2450 How easy would it be to do this in the server? The release command is already in pySangaboard.
You don’t have a way to check the temperature? It would be interesting just to know how hot it is so we can measure the difference quantitatively when we try to fix this.
As a stopgap solution have you tried attaching little heatsinks?
Yep adding an API view and a button to de energise should be easy enough.
I’m thinking manually de-energise with a button, and energise automatically when you next ask it to move?
I’m wary of adding an energise timeout as you run the risk of people accidentally enabling it and losing steps. I think it needs to be a very explicit action.
I would consider putting it in an option with a timeout value. But then long running processes that keep the camera lock also stop the timeout counting. So it won’t skip on scans, but if you just leave the microscope sitting somewhere for 5 mins then things will have drifted a bit anyway.
Worth checking with @r.w.bowman though.
@jlauer the drivers we use are super simple (four Darlington pairs per motor) so driving a 5V motor with 12V will probably just make the problem worse (if you’re unlucky, quite a lot worse!). As @j.stirling says, you only get the improvement with chopping drivers.
I think a timeout to disable the motors might make sense, but you’d want it to be minutes rather than seconds because otherwise you’ll lose positioning accuracy (the internal backlash in those motors is quite significant). Also, if we do this I think it should be very obvious to the user that it’s timed out, because otherwise this is one of those issues that will bite us in the bum when we least expect it. Would it make sense to disable the camera stream too, effectively pausing the microscope completely when it’s idle? @jlauer are there times when you’d want the motors to de-energise but you’d want the video feed to stay live?
All good points. Maybe best is after 1 or 2 hours. The problem for me is I left it on overnight without thinking about it the first night I built the microscope and I could have almost burnt my house down with how hot those motors were. Granted, they didn’t melt the plastic, but I think I was right at the edge of that.
Agreed that if you turn the motors off you’ll lose position and it defeats the purpose of the microscope. I’d just leave the camera going too as that doesn’t pose a fire problem.
Maybe what would be cooler is 50% power on idle. That way you keep position, but aren’t burning up the motors.
I agree that would probably be best, but unfortunately we can’t vary the power very easily. Probably a long timeout is the right compromise, perhaps combined with something in the client that explicitly requests a motor release and warns the operator.
Turning off the camera feed was less about saving power (though for sure it would) and more about making sure it’s obvious that something timed out. My experience is that adding in subtle features like this leads to people forgetting about then and spending ages debugging something because the motors were turning off while the microscope still looked ok…
I think if we say 30 mins for the time out and we make the interface so that it drops a message across the main microscope view in Connect saying:
“Microscope motors turned off after 30 mins of activity, to stop this in future change *** setting.”
