Smaller Frame and Unpredictable High Current During Calibration

Howdy Team!

I’ve been battling my Maslow all day today to get it to calibrate. My frame is 72"x96" ( I can’t fit full 4x8 sheets into my basement so I am starting off with something that I can do down there using 4x4 sheet.)

I keep on getting high current typically on the pulling motors with the amperage going just north of 4000mA. I have rebuilt and greased the arms… twice :woozy_face:. to make sure it wasn’t binding. I did have the same issues as others with the retraction but the new firmware update with the adjustments allowed me to get around this hurdle.

Now I am not sure about is why I am getting these spikes in current when there is less tension on the lines than when they are in retraction. It jumps around from motor to motor but mostly happens when the calibration starts and the only line that is tight is the lower left. Sometimes hitting calibration again allows it to continue on.

I’ve attached a picture of the build to show the last spot the Maslow failed. In this picture it was the top left motor that had high current. For reference the bottom left motor is in the upper left of the picture.

1 Like

I have a theory for what is causing this and I am working on a long term fix.

I think that I might also have a quick fix that we can test right away.

I’m not sure why some people are seeing this and others aren’t but I am 100% sure that you didn’t do anything wrong and that it’s a bug.

How things should work

In the vertical orientation we use the top to belts to move around and the lower two belts are slack. Because of gravity we can rely on the top two belts always being under tension.

In the horizontal orientation we switch around which two belts are pulling and which two are slack. We rely on friction to ensure that the pulling belts are always under tension. This works great as long as the belts are retracting.

We should always have two belts that are tight and two belts that are slack at the end of the move.

What is going wrong

The issue is that the way we are doing moves right now is not coordinating the belts so that one belt often finishes retracting before the other. The belt that finishes first goes slack.

When we start to take a measurement by pulling the belt opposite the slack belt tight the slack belt gets “startled” by going tight suddenly and overcompensates sort of like if you go to pick up a soda can that you think is full and it’s actually empty and you end up picking it up faster than expected. This leads to the current spike.

How do we fix it

The long term solution is to synchronize the belts that are pulling so that they finish at the same time. I’m working on that right now.

The short term solution (that I would LOVE your feedback on since I haven’t actually gotten my machine to do this I might be totally wrong) is to give it a little extra tug at the end of each move so that the two belts which are pulling both end up tight.

Basically we want to pull gently in the opposite direction that it’s moving. That way it has something to pull against and one of the pulling belts won’t end up going slack.

Forgive me if I’ve described that badly or if I’ve totally misunderstood the issue.

The only thing that I’m 100% sure of is that it’s not your fault, it’s a bug, and I will fix it as soon as we can understand it.

In this case my theory is that the top left belt had some extra slack at the end of the move, so when the bottom right belt went taught it (the top left motor) overcompensated and created the error.

Hey Bar!

Thanks for the quick response. I’ll give it a try and report back!

If that doesn’t work would you recommend trying this again in the vertical orientation?

PS. Everyone at Maslow did a great job putting together the instructions. They were for the most part quite thorough and easy to follow, bravo! I went full flow and have been fully absorbed in this for the whole weekend. Thank you!

1 Like

That would be tremendously helpful. If I can be sure if my theory is right or wrong it would make a huge difference in focusing on the right place to fix it.

That’s a really interesting and great idea. Yes, absolutely give that a go. Don’t forget to change the setting in the .yaml file to vertical first tho or it won’t work right.

Thanks…but that’s just because the first folks to put it together gave us some great feedback on where things needed to be re-worded and clarified :smiley:

The long term solution is to synchronize the belts that are pulling so that they finish at the same time. I¢m working on that right now.

If you aren’t sure where the machine is, I don’t see how you can do that.

The short term solution (that I would LOVE your feedback on since I haven¢t
actually gotten my machine to do this I might be totally wrong) is to give it
a little extra tug at the end of each move so that the two belts which are
pulling both end up tight.

I think you need to go around all 4 snugging them up, you can’t be sure that the
sled didn’t slip and make one of the other belts go slack. If you go around all
belts twice, I don’t see how any of them could still be slack (and if it ends up
they could, go around a third time)

David Lang

We can’t synchronize all four, but we can synchronize two. It’s just the two that are pulling that we want to keep taught.

Frame successfully vertical and calibrated with 63 points. Seems to be working now. Haven’t ran a CAM file on it yet.

Out of curiosity is the bottom right cable supposed to be loose as seen in the picture. When I clicked “Take Slack” they all pulled but the sled was 2 inches to the right off center. I moved it to the left 2 inches and now the bottom right is slack.

1 Like

Nope, it shouldn’t be like that :confused:

This is after entering the computed values into the config file → power off → power back on → retract all → extend all → take slack?

If so when you click the arrow buttons to move around all four belts should be taught

Correct. The bottom left one did not tighten up with the move and I tried it again and this time while I was moving it the belt bound up in the arm.

1 Like

Darn, with the correct locations for the anchor points in the configuration file we expect that all four belts will be taught the entire time. They should never be slack like that.

I pressed this button to make the move.

If this is the correct interface to make the moves I’ll try going in different directions to see if this happens with other arms.

1 Like

That is 100% correct.

At the end of the calibration process did it print a “fitness” number?

The thing that has got me stumped is how the calibration process can give a wrong answer that is off by that much.

Yes it read 0.04… followed by like 12 numbers.

1 Like

I was curious what the ideal should be.

1 Like

Gotcha…I need to make that more clear.

0.04 is really really low, something went wrong during the calibration process for sure. It should be somewhere closer to 0.7.

I’m going to add a warning for that to the firmware right now.

Sorry to bug you for details but how is the fitness determined?

OK, I added a warning for that.

Now the question is what could cause that low of a fitness number.

Basically what that number means is that the calibration process was only able to locate the anchor points to within about ± one inch which is going to result in a lot of slack and or too much tension in the belts depending on which way it’s off.

In terms of what could cause that, I’m not sure. Potentially if one of the belts got caught on something and wasn’t able to get a good measurement or a lot of flex in the frame? Did anything weird happen during the calibration process?

is there any way you could invert the number or otherwise show the calculation
as a approximate anchor position error? that would be far more obvious to people
what it means and drive better positioning.

David Lang

I probably shouldn’t have put a real world unit on it in saying it was off by x inches. It’s a measure of uncertainty which may or may not tell you valuable information. For example if we make the calibration grid just two points you will always get a perfect score of infinity (which if converted it to real world units would be 0.00000mm of error), the problem is that the calibration would actually likely be really bad, just that our two data points aren’t enough information to really disagree with each-other at all so we think our answer is perfect.

I think that we need to find someone with a background in statistics who would be willing to look at that part of the code and give us a more clear understanding of what that metric should be.