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?