Keyboard shortcuts and motor temperature

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

1 Like

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.

1 Like

@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…

1 Like

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.”

Sure, that sounds ideal. My reason for suggesting we pause the video stream too was to make it obvious to other clients (e.g. if you’re running an experiment from a notebook) that something has happened. Also, I’m not sure there is currently a nice mechanism in the interface for a global status message for the microscope - though I think that would be a helpful thing to have if @jc2450 has a sensible way to implement it.

Yeah adding a modal that blanks out the entire display should be easy enough.

I do worry though like you said about cases where people are using notebooks or something instead of the JS client.

I have motors sitting here powered up and moving about a sample for hours. They are barely warm. I think the timeout may be more of a sticking plaster to cover a problem that is actually about motors.
These little steppers surely should not get hot. If they are I think it best to sort that out as a hardware issue. For the problems @jlauer and @Bogdan have seen, are they just bad batches of motors, or are they driven at the wrong voltage, or are they labeled incorrectly?

They heat up when not moving. When moving there’s actually less power going through them as it’s getting turned on/off averaging about 50% current. When not moving it’s at 100% current.

Moving or not moving, these ones here stay barely warm. Hot enough to burn you sounds as though there is something wrong. I want to do some current monitoring to see what power they are taking.,

I have a step-down converter with a current and voltage display. I have connected this to power the motors only. At 5V with all three motors energised it is 0.57A, so about 2.8W for the three.
Interestingly when x or y motors move it drops to 0.55A, but when z moves it drops all the way to 042A. I shall clearly need to check whether this is a difference in the motor or a difference in the stiffness of the z-axis.

Hi,

Was a solution ever found to the problem of the motors overheating? I’ve built mine with the recommend 5v motors in the build guide and like the first poster, they get blistering hot. Is there a trick to prevent this? I don’t want to have to disable them because the big selling point for me was having it automated for tile images, but it is not possible to operate it for much longer than 30 min without it over heating.

Thanks in advance,
Robert

If you have the 5v version of the motors and run them at 5v they should not get hot. These are very low cost and it appears that one consequence of that is that some batches take too much current and get very hot.

On my setup none of the motors gets hot, but they do perform very differently. One seems to have twice the resting current if the other two, even though the running current is the same.

I think the only real solution to hot motors is unfortunately trying some different items of the same type, but a different batch. Unless anyone has a better suggestion? Or a way that this could be a problem with the H-bridge, not the motor?

It’s just one Darlington pair per motor coil, not even an H bridge! I’d be surprised if the driver was at fault, though it’s easy enough to check by swapping channels, if your motors differ. Re: lower current while moving, there are 8 possible states, alternating between 1/4 and 2/4 coils being energised - I think the reason for lower current while it moves is to do with the impedance of the motor changing when it stops?

I suspect this could be sorted out with current control (rather than simple on/off voltage control) but that would take fancier drive electronics, which usually requires bigger, bipolar motors…