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
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 
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 
1 Like
Keep us posted on if that issue crops up again! Iām glad to hear that itās fixed 
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.