Hi, i assembled my high resolution microscope and was testing it out on the sample, when i put the X value to be very high, causing the motors to keep rotating and suddenly heard cracking sounds, since then the X axis of my stage is not moving. Whenever i put some X value and click move in the navigate pane, the motor and the gears both move but the stage does not move.
The actuator column shows no change, confirming my suspicion that the stage is infact not moving.
Kindly help me figure out the issue and any possible fixes. I can provide images for more insights
Your diagnosis sounds to be correct, the mechanism for the x-axis is broken.
Unfortunately this means that you will need to print a new main body and re-assemble the microscope.
There is no sensor for the travel, so if you tell the stage to move, then it will try to move. You need to keep an eye on the stage to make sure that it has not moved too far. We are working on the hardware and software to help this. In the hardware we are looking at what makes the stage stop moving, and trying to make that happen in a way that does not strain the actuators. In the software we are developing methods to find the centre of motion and the range of motion on an assembled microscope. This can then help users to keep within the design motion.
This is why many of us want endstops as an option, for a kind of closed-loop control. It just isn’t reliable to expect the software to keep track of where the stage is, no matter how hard you wish.
Hardware endstops add a level of complexity in assembly and wiring, as well as sourcing components, that will be justified in some situations. The core team have not had any breakthrough thoughts on how to do it well.
I feel that hardware limit switches may well be addressed best specifically in different uses. For example, microscopes destined for routine non-technical use are likely to need more enclosure. Something like A box a box, my kingdom for a box encloses the mechanism, which then provides opportunities to mount endstop switches on the box against the stage top. This would be much simpler to design and to install than fitting ultra small switches in the actuators.
In the core uses of the OpenFlexure system a user is placing a sample onto the microscope. This means that there is a frequent opportunity to check that a microscope has not wandered from centre. There was a bug in the Sangaboard motor control software that caused it to record steps incorrectly when there were a large number of moves. This is now addressed, and with the way that the steps are stored on the Sangaboard it is relatively hard to have failures where the total step count is not correct - provided that the user does not reset the counts accidentally.
A user will also be able to see when the image stops moving. With the OpenFlexure v2.11 software you cannot stop an on-going move without drastic action like pulling the power! We are accelerating development of v3, which allows moves to be cancelled from the web-app. This is a massive user help in mitigating crashes. Automatic unattended scanning will also always have the information available from the camera to know when a sample is not moving as expected.
The core software developers are particularly working on setup and calibration, both better calibration artifacts and calibration routines in the software that find the stage centre and the range of motion (eg merge requests !273, !335, !429), and better user instructions. These work very well. I am also working on the hardware, so that when the end of motion is reached the strain is not taken by the weak flexures (merge requests !513 and !512).
We do have a bit of a gap in the user experience between the physical assembly of a microscope and getting it set up for first use. Basic positioning of the illumination and centring the stage were improved on the latest v7.0.0-beta5 release of the Microscope.