When I had this issue, the experience was that it was rigid when I would pull, and it would spool out more when I pushed in. I essentially would push, pull, push, pull, in tiny increments over and over to get it to feed out more.
The way the others have described it is spot on to what I saw.
Ok. Went out to maslow after being turned off for ~18hrs. SD /mmc card error when powered on , the same as yesterday. Reboot resolved that.
Now all 4 arms are exhibiting the push to extend behaviour.
Well I guess that eliminates the need to swap the cable.
It seems like it’s software to me…I just have no idea where in the software.
Can you try going back to an earlier version of firmware/index.html/maslow.yaml (make a back up of your current file first so you don’t lose calibration) and see if that fixes the issue?
clearer video showing the behaviour
Tried going back to 0.70 , same result with all 4 now doing push to extend. (with the GitHub provided maslow.conf with no changes, as I figure we’re not even getting the to the extending everything bit so the dimensions dont matter)
Tried 0.68, now only TL is exhibiting the issue. The other 3 are fine.
Back to .70.2 and only TL is doing the push to extend. Nothing untoward in the log
Im going to make a special firmware version today that prints out more information to see if that will tell us more. I was hoping that I would have some fresh ideas in the morning but I’ve got nothing.
We tried swapping the Ethernet cable with a different arm and that didn’t fix it, right?
Swapped, checked for damaged pins, and cleaned them 
Well, after digging into this I’ve learned absolutely nothing. I have truly no idea what could be causing that behavior I’ve made a firmware version which will print out more information about what is going on which can hopefully tell us something. I’m building that into a firmware.bin file now
I can confirm that pushing the belt in shouldn’t do anything at all. The only thing that I can think is that it’s either a timing issue or a memory overflow issue somewhere?
This will print out some more information during the extend all step which might shed some light on what’s going on so we’re not totally blind:
firmware.bin (1.6 MB)
First observation, retract all started to spew out huge amounts of TR, like it was running backwards. Trying to sort out this mess, will report back soon!
So weird!
The more I think about it the more it seems like this is some sort of weird memory corruption thing. This might reset everything:
Could be, just got another sd card error. Will try the full install when I have this belt sorted
Serial Messages
[MSG:INFO: Channel auto report interval set to 50 ms]
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
[MSG:ERR: sdmmc_card_init failed code 0x0x102]
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
[MSG:INFO: Caution: Unlocked]
error:152
Log attached.
tl.rtf (22.7 KB)
Well that looks completely normal I think. I see nothing wrong with the encoder values and the error message that I added to detect if the function wasn’t being called often enough didn’t run.
Pretty sure this is pure coincidence, but
[MSG:INFO: Top Left pulled tight with offset 63.708]
.
.
.
[MSG:INFO: Position: -63.826 Distance moved: 0.000 on axis Top Left]
you extended the belt to within 0.1mm of how far you pulled it out last time which is great repeatability.
My new theory is that maybe we’re calling stop somewhere else in the code…let me make a version to test that.
Edit: New version which will tell us if the motors are being commanded to stop somehow.
firmware.bin (1.6 MB)
tl.rtf (26.4 KB)
All 4 belts are doing push to extend
I did the full-install , same result. All 4 are doing push to extend.
Log of install attached, there was a few panics, not sure if this is normal? I am running this in parallels on a M2 Mac.
Command Prompt - full-install.bat.txt (23.1 KB)
Both of those logs look 100% normal…clean bill of health 
I’m really grasping at straws here, but is this happening while connected to a WiFi network or while using the Maslow WiFi network that the machine creates?