Sprocket does not reset to 12:00 automatically in calibration step 9b

Greetings,

I am in the midst of setting up my Maslow for the first time. I’ve made it to the initial calibration, which I’m working through with the assistance of madgrizzle’s (very helpful) “How To: Get Calibrated!” guide.

In six or so repeated attempts, I have gotten stuck at step 9b, in which you reset the left sprocket to vertical after having measured the chain. The guide (and common sense, I think) suggests that you should be able to hit “Automatic” to spin the sprocket back home. But doing so does not work for me: it rotates to a position that is consistently about 95 degrees clockwise of where it should be.

The guides suggests that this means something is seriously wrong and to try again, but I keep getting the same result. Everything up to this point goes quite well — the measured chain length is very reasonable and quite consistent between attempts. FWIW, I’m using Firmware and GroundControl version 1.21.

I’m stuck. Any suggestions?

Thank you,

  • Andy
2 Likes

Welcome to the Forum!
I’ve noticed that as well. The first ‘automatic’ will work, but the second one is off. Continue by turning the sprocket to 12 with the degree buttons.

1 Like

Well, that is interesting (I’ve never had to do it because I’m still top feed). Is everyone experiencing the same thing? I ask because if this is happening, that’s potentially a serious bug that would throw off calibration.

The automatic procedure requests the chain lengths from the controller, then performs a modulo operation with the distPerRotation (chainPitch*gearTeeth… typically 63.5 mm) to get the distance past the zero point. It then sends a command to move back (retract) that distance amount.

The only way I see it having this issue is if the read command responds with an incorrect distance… and being 95 degrees off is significant (~17 mm)

Sorry for the message spamming…

Andy, you are in a off-the-bottom-feed configuration, correct (i.e., slack chain runs horizontally across the top beam)? If so, I wonder if the problem might be that GC temporarily switches the machine from bottom-feed to top-feed to do the chain measurements and then switches-back. It’s possible that the computation isn’t accounting for this swap… It’s about the only thing I can come up with to explain the large error.

Nevertheless, @gero is correct. Just reset the chains manually and you should be fine. I’ll edit the wiki to make it clear.

2 Likes

My instinct is that the bug is a small one in the working of the “automatic” button. I remember not feeling great about that code when I added it

1 Like

Thank you all for the advice. I’ll give it a shot with the manual reset of the left sprocket tonight and report back.

@madgrizzle I am, indeed, in the off-the-bottom feed configuration. The measured motor distance that I’m getting from the calibration process is certainly within a couple of mm of the truth.

2 Likes

@bar, what about at the end of the motor measurement routine when the 10mm of slack is added, that instead we just rotate the sprocket back to zero? After that, we switch back to bottom feed configuration if necessary.

Im not sure those two functions are interchangeable. The 10mm of slack is there to make chain easy to unhook from the sprocket. If we got the auto rotate to 12 to work 100% of the time we could call it automatically in the On_Enter function of the step to set the sprockets vertical, that way it would always happen with the option to adjust it manually if you want after

My hypothesis is that the problem is that originally the controller is in top-feed configuration, chain let out and retracted, and then switched to bottom-feed before going to the set vertical screen to allow you to return to 12 o’clock… If it was told to turn to 12 o’clock while still in top-feed mode, it might work correctly. It just seems that this (switching from top-feed to bottom-feed) could be the cause for being so far off.

1 Like

turn to 12 o’clock needs to be done based on encoder steps, not distance
(especially as we add chain sag and slop to the calculations for distance)

David Lang

This command sends a B09 which uses singleAxisMove. singleAxisMove converts the distance to encoder steps using only the mmPerRot value. Chain sag, slop, etc. don’t come into play for singleAxisMove.

I think those values do come into play, check my logic.

Yes, you’re partially right. I was thinking about the modified firmware I’m working on where I removed the change to the sprocket radius based upon chain tolerance. However, chain sag is only used in triangularInverse and afaik, that’s not called unless you are using coordinatedMove.

Just to update on my build: I was able to manually reset to 12 o’clock in this step and then successfully complete the calibration process. We made it through cutting the final sled today — so far, so good!

5 Likes

Just wanted to add my experiences here… I’m using firmware version 1.25, with a bottom fed machine, and automatic has never properly reset the sprockets. I always check but then I always have to do it manually.

1 Like

Is your observation that it works the first time, but not the second?

In the “standard” calibration routine this step is performed twice; is that what you are referring to?

Yes, I think I recall that once stored, it would work once in a new calibration routine but not the second time in the same calibration. Hope I will get to do it later and will check.

1 Like

Possibly, I don’t recall all of the times that I have done it previously as I never took notes. Last night I wiped everything and started over taking notes and making a copying of the INI file at each step. Some interesting results… I will try to organise and post when I get a chance.

1 Like