Push to extend bug?

I spoke too soon. released tension, powered off , and now BL and BR are doing push to extend, TL and TR are working as expected.

1 Like

:expressionless: darn

Short of opening up the arm where can I find details on the encoder chip ? I cant seem to find any electronic stuff on GitHub

1 Like

Scuba Shan wrote:

[MSG:INFO: Retracting all belts]
[MSG:INFO: Bottom Left pulled tight with offset 0.011]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
[MSG:INFO: Top Right pulled tight with offset 0.000]
[MSG:INFO: Extending all belts]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Top Left pulled tight with offset 0.000]
[MSG:INFO: Bottom Left pulled tight with offset 0.011]
[MSG:INFO: Top Right pulled tight with offset -0.011]
[MSG:INFO: Bottom Right pulled tight with offset -15.310]

If you extend and retract, does the bottom right commonly show a large error
like this?

David Lang

This is our encoder chip:

That was because I’d push/extended BR ~15mm I think? . ie I retracted, tested them extending BR 15mm , then retracted

1 Like

Scuba Shan wrote:

Short of opening up the arm where can I find details on the encoder chip ? I cant seem to find any electronic stuff on GitHub

it’s the as5600

David Lang

Ok, my understanding is that if you let it retract all the way, it should always
be near zero, anything else means the motor hit the current limit first.

David Lang

1 Like

It should if it was fully retracted when the machine powered on. If the belts were slightly extended when the machine last turned on (or had the firmware updated) then you will get an offset

right, but per the log this was retract → extend → retract. If the 2nd retract
isn’t to very near zero (and the belt didn’t catch on something the first time)
there is something wrong to investigate

or am I missing something?

David Lang

2 Likes

I have a new theory:

The encoders have a direction pin which can be used to set which direction of rotation is the positive direction. I left that pin unconnected because we didn’t need to change direction, but that was bad practice. I should have tied it to something to ensure that it couldn’t float around.

My current theory is that something in your environment is causing that pin to get pulled up sometimes causing the encoder to switch directions.

I’ve just sent you a second set of encoder boards which I’ve modified to make sure that pin is connected to GND. The weird thing is that I already sent you a first set of unmodified encoder boards yesterday (maybe two days ago), but I’m sending these modified ones express so they will get to you first. Hopefully it’s something weird in your environment and not a widespread issue :crossed_fingers:

1 Like

I haven’t seen it recur yet, but the time it happened for me was after it was working fine, then I came back to it after leaving it unpowered overnight. I’m pretty sure I killed power by unplugging it.

1 Like

I do run Maslow on its own UPS, but I’d expect anything it s doing to be filtered out by the switch mode power supply? I’ll do some testing without the UPS and could also test direct from 24v batteries if you think it might help? I’ve had this happen in two separate sheds about 50 meters apart, with different lighting and not much else running nearby.

1 Like

Maslow is rebuilt and cutting again :slight_smile:

1 Like

Keep us posted on if that issue crops up again! I’m glad to hear that it’s fixed :grinning:

That was a great catch! Sorry it took me so long to figure out what was going on there!

Could you explain what fixed the bug? was it indeed the ungrounded direction pin? or a software fix?

I believe it was the direction pin. See M4: Cut fail. not much info, but potential Z axis bug after stop - #40 by bar for some images. @ronlawrence3 is trying this to try to fix his problem. We’ll see how that goes.

@bar or @arjenschoneveld, can you confirm that grounding the direction pin was (or at least appears to be) the fix for this issue?

1 Like

That’s my impression, but I haven’t had it happen so I can’t confirm hands on. I think we need a somewhat larger sample size to be 100% sure and to wait a bit long and see that the issue doesn’t come back

TL;DR: A few users have reported that when they try to Extend All one or more of their arms operates kinda backwards. To get the motor to extend, they must push on the belt. The motor extends the amount of belt they push into the arm enclosure.

Status: As of mid-May 2024 this issue is still open but we have a hypothesis that a pin on the encoder chip which is supposed to be at ground voltage is instead picking up some voltage. That pin controls the direction the chip reports, so the encoder works backwards. If this hypothesis is correct, grounding the pin should fix this.

3 Likes

Came out this morning after several successful cuts two weeks ago and had the same issue with the BL belt. It would not extend. I tried the push thing per the video but that did not work.

I swapped the ethernet cables TL to BL and BL to TL, restarted and was able to kinda do the push pull thing however, when I pushed in on the BL belt, the TL belt would start extending then when I pulled the TL belt, I was able to pull the BL belt in the amount I pushed in. I did this until I got the BL belt fully extended.

I powered off and switched the cables back to how they should be. Then powered up and retracted all. I tried extend all and the belts never got to a point where the machine though they were all extended. I tried this several times with power on/off in between but not luck.

I then went into the fulid NC tab and edit the Config Items and set all of the /Maslow/br*, /Maslow_tl*, /Maslow_bl*, and /Maslow_tr* to zero and saved. Restarted.

I then tried to run a fresh calibration. I set my frame size (12’ width x 8’ height) and saved. Retract all then extend all and this time got [MSG:INFO: All belts extended to center]. I attached it to the frame and clicked Calibrate. It ran the calibration but the result was:

MSG:INFO: Zeroing z-axis position]
[MSG:INFO: Measured waypoint 0]
[MSG:INFO: Center point deviation: TL: 0.124 TR: 2.325 BL: -62.998 BR: 47.844]
[MSG:INFO: Measured waypoint 1]
[MSG:INFO: Measured waypoint 2]
[MSG:INFO: Measured waypoint 3]
[MSG:INFO: Measured waypoint 4]
[MSG:INFO: Measured waypoint 5]
[MSG:INFO: Measured waypoint 6]
[MSG:INFO: Measured waypoint 7]
[MSG:INFO: Measured waypoint 8]
CLBM:[{bl:2134.95,   br:2245.79,   tr:2200.27,   tl:2198.07},{bl:2131.14,   br:2131.27,   tr:2227.38,   tl:2312.99},{bl:1921.19,   br:2390.30,   tr:2431.00,   tl:2073.56},{bl:1953.51,   br:2457.71,   tr:2410.04,   tl:1994.85},{bl:2035.52,   br:2524.52,   tr:2349.22,   tl:1920.94},{bl:2221.61,   br:2269.75,   tr:2131.32,   tl:2174.41},{bl:2429.92,   br:2073.61,   tr:1921.07,   tl:2387.01},{bl:2409.94,   br:1994.90,   tr:1953.61,   tl:2456.23},{bl:2349.19,   br:1921.18,   tr:2032.16,   tl:2519.58},]
Computing... This may take several minutesFitness: 0.3472710 in 100
Fitness: 0.3476718 in 200
Fitness: 0.3476718 in 300
Fitness: 0.3481720 in 400
Fitness: 0.3823645 in 500
Fitness: 0.3856728 in 600
Fitness: 0.3856728 in 700
Fitness: 0.3856728 in 800
Fitness: 0.3856728 in 900
Fitness: 0.3856728 in 1000
Fitness: 0.3856728 in 1100
Fitness: 0.3856728 in 1200
Fitness: 0.3856728 in 1300
Fitness: 0.3856728 in 1400
Fitness: 0.3856728 in 1500

WARNING FITNESS TOO LOW. DO NOT USE THESE CALIBRATION VALUES! 

I tried to jog but the controls seemed to take the machine in random directions with some belts becoming loose. I’m running v .73 and had updated my .yaml and index file with the firmware update prior to this whole ordeal.

I’m stuck. Any ideas.