Delta stage accumulated error

Hello, first of all thanks for this amazing project. I’m impressed by what has been achieved here.

I have just finished putting together a delta stage microscope using the latest version of everything. However unlike the regular non-delta microscope, I’m having lots of issues with the motion of the stage.

I know the issue isn’t with the motors or the mechanical parts of the microscope because if I switch the stage configuration back to non-delta, then all my movements are reversible. I.e. if I go 10,000 steps in one direction then 10,000 steps back then I return to the original position.

But with the delta stage configuration enabled, if I move 2000 steps in any direction, then 2000 steps back the other way, I am a somewhat random distance and direction from the starting point.

Is this a normal experience?

For troubleshooting, I have replaced all three motors, and replaced all of the nitrile O-rings with very weak elastic bands (so that the gears turn very easily) without any improvement. I have also tried deleting all the microscope’s config so that it returns to a fresh install.

The factor of switching back to non-delta stage in the software completely resolving the issues (obviously, the travel directions are out but repeatability is very good) but then returning to the delta stage bringing it back makes this very confusing.

I’ve made a video of the behaviour I’m experiencing here… https://www.youtube.com/watch?v=0xv1q0XDAz4

Anyway, I don’t wish to sound like a complainer because the microscope is indeed very impressive, but I’d like to do stack & scan imaging of objects that are too large for a single micrograph and the problem is that it ends up drifting off into the void outside the sample after 5-10 images.

Any help would be appreciated!

Simon

1 Like

That does sound like an odd behaviour. I have not had time to look at the video yet.

You are certainly not being a complainer, we always like to know about issues as it helps us improve the project.

I am going to have to think about this. I don’t really use the delta stage so I don’t have a lot of experience, but I understand the mechanical system well. Everything I can think of that would cause poor movement would be repeatable even if weird unless it is backlash. But this should be the same between the two modes.

The purpose of the Viton o-rings is to keep the nut in tension removing backlash and making the stage move through the lower half of the actuator travel. I’d guess that weaker elastic bands would make the issue worse.

Thank you for the report!

The factor of switching back to non-delta stage in the software completely resolving the issues (obviously, the travel directions are out but repeatability is very good) but then returning to the delta stage bringing it back makes this very confusing.

Is this true for all 3 axes? That drift is likely way too large for this but one possible source of error accumulation in the delta stage is rounding, the steps have be integer but are computed as float (this caused issues with the Sangaboard firmware earlier so now the conversion to int is done there) and as the moves are sent as relative moves it could accumulate error, but not more than ±1 step/move/axis.

Hello, thank you for your replies.

The purpose of the Viton o-rings is to keep the nut in tension removing backlash and making the stage move through the lower half of the actuator travel. I’d guess that weaker elastic bands would make the issue worse.

Just to explain my logic here: I initially had the microscope set up with the standard Viton bands, but due to the delta stage actuators being taller than the non-delta ones, the bands are stretched very tight, to the point where it takes a reasonable amount of force to turn the gears. The symptoms I’m seeing are the kind of thing that could be explained by missed motor steps, so by putting the weaker bands in, I was aiming to confirm or eliminate that possibility. While it would definitely make the stage less accurate, I didn’t notice any superficial difference after changing them over. I have bought some slightly longer o-rings for a proper solution to that but am just waiting for them to arrive.

Is this true for all 3 axes? That drift is likely way too large for this but one possible source of error accumulation in the delta stage is rounding

It’s not always predictable, but it seems to mostly drift toward the right. Usually if I move left and right there is no up/down (“C”) error at all (although some horizontal error). And if I move up and down, then I almost always see quite noticeable simultaneous “wandering” horizontal movement.

It seems to be hundreds of steps out of place after each movement so I agree with you that it probably isn’t caused by final rounding up or down of the 1 step at the end of each move.

Sorry for the slow replies, I’ve been caring for a sick person and ended up busy all day yesterday - I’m going to keep testing whatever I can to try to narrow things down. I might buy another Pi and Sangaboard in case there’s a hardware fault in the electronics. I’m using a Sangaboard 0.5 and a Pi 4B (2GB) by the way.

Thanks again! I’ll post again I discover anything new.

Simon

Hmm this is not good. I had not realised that the delta stage actuators are longer. I am not sure why this design change was made and if the travel is longer or just the length. I did actually hear that the new tool for the microscope doesn’t work with the delta stage, so this all checks out. Hopefully it is just a taller actuator column with the same or similar range of motion and then we can just specify a longer band.

[Edit to confirm that the Delta stage actuators columns have been 30mm rather than 25mm since very near the start. I think do wonder if this makes the total path for the band about 20mm longer. I would assume that a 36x2mm o-ring would perform better.]

I agree that the motors may be missing steps and it may be more likely in one direction than the other. Can you get a marker pen and make a vertical mark on the motor and the gear so you can see initial alignment? If you then run this again we can check if the gear isn’t returning to the right place? Assuming it isn’t then it is either a software bug or it is missing steps.

How are you powering your motors? I am wondering if it doesn’t have the power to run all 3 motors at the same time hence it works worse in the Delta Stage.

1 Like

Sorry, I explained the part about the all 3 axes poorly, I was referring to this:

I know the issue isn’t with the motors or the mechanical parts of the microscope because if I switch the stage configuration back to non-delta, then all my movements are reversible. I.e. if I go 10,000 steps in one direction then 10,000 steps back then I return to the original position.

Basically just to confirm that non of the motors are skipping steps. You can try moving in all 3 axes at the same time too with the Cartesian configuration to better replicate the delta moves.

With Sangaboard v0.5, it is likely you would see a voltage warning on the Pi if this is a power issue (you can check in dmesg)

Hello again.

After putting the original viton o-rings back on, I started doing a few tests of movement with some motors disconnected/reconnected to see if I could answer those questions. Embarrassingly, after a couple of minutes of testing it, it suddenly became reliable and I wasn’t able to continue. It has since then stayed reliable.

I had only time to observe two things:

  • I did see some wandering, but there was never a low-voltage warning in the system log. I’m using a Raspberry Pi 4 official PSU which is rated 3A.
  • (more interestingly perhaps) I observed some Y-axis wandering of the stage while moving in the X axis while I had my finger on motor C, which was stationary. The C motor gear definitely did not move in the slightest. So perhaps that means the problem was never motors missing steps at all, but something about the physical properties of my stage not being entirely correct? Whatever that is/was, it seems improved now for some unknown reason. Perhaps something was rubbing and has now worn down.

I ran a raster scan of my sample with 450 captures and it went through fine. I’m terribly sorry to have brought this up only to report that it magically fixed itself!

Here’s a victory image from the result. I’m pretty happy that I can do this successfully now :slight_smile:

Thank you both again so much for all your advice and suggestions!

3 Likes

Great to hear it is working! And thanks for reporting it originally.

Intermittent issues are always the most annoying thing to fix. Glad it’s working, let us know if the issue resurfaces! Would be good to know how to diagnose and fix it in case anyone sees a similar issue.