Extend all causes one belt to push belt out (resolved)

Troubleshooting
1

Bar sent me a bit of new hardware to try to figure out what my issues have been with my original kit. I put it together, updated firmware and index.html.gz and maslow.yaml. Then I did retract all, and only one belt moved… had to up the current setting to 2100 to get them all to retract. This is not much different than I experienced before, and similar to what I encountered after re-assembling the arms after the grounding of the encoder pin. Last time I was able to go back to 1500 after the initial retract sequence.

I then did extend all, and to my surprise one of the arms started moving immediately (video below). I knew from my work on the ui that if I hit retract all it should stop that motion, so I did, and it retracted out the slack.

So, I flipped the cables on that side and tried again to see if it was the encoder or not, and it happened on the other arm i.e. the same port (bottom right) even when hooked up to the top right arm. So I don’t think its the arm or the encoder there.

Anyone seen this or have similar things happening?

When I reset the machine, reloaded the current firmware again, along with maslow.yaml and index.html.gz all seems fine now.

1 Like
2

The post shows resolved but its still a mystery without a root cause. Maybe there was some issue with updating the files on the SD card on your first attempt?

1 Like
3

Yea, that is my guess too. Whatever it was it stopped doing that now.

1 Like
4

Is there a way to check bytes or timestamps on the files on the SD card through the browser? In other words, is the metadata visual in parts of Fluid where you access and update files?

5

maslow.yaml, index.html.gz, some other settings files are actually on the flash file system and not the SD, but no

If you go to http://maslow.local/files?action=list&filename=all&path=/ you will see something like this: (datetime is always empty)

{"files":[{"name":"favicon.ico","shortname":"favicon.ico","size":"1150","datetime":""},
{"name":"index.html.gz","shortname":"index.html.gz","size":"161467","datetime":""},
{"name":"maslow.yaml","shortname":"maslow.yaml","size":"5328","datetime":""},
{"name":"preferences.json","shortname":"preferences.json","size":"1025","datetime":""}
],"path":"","total":"192.00 KB","used":"184.00 KB","occupation":"95","status":"Ok"}

And for SD, http://maslow.local/upload?path=/ ( I just have one file on mine right now ):

{"files":[{"name":"l3.nc","shortname":"l3.nc","size":"146920","datetime":""}],"path":"","total":"119.00 MB","used":"145.00 KB","occupation":"0","status":"Ok"}
6

This to me looks like their might be something funny going on with the encoders. If it is extending out like that it thinks that that encoder is moving when it isn’t

7

Thats what I thought, but I swapped the ethernets and it did it on the other one too.

But as I say, it stopped after a full reset/reload of software/firmware.

Now I’m having issues with bottom left not retracting when it starts calibration, even though retract/extend works well on all 4 belts. I’m going to have an hour or two here in a little bit to try some more.

1 Like
8

I got through successful calibration. All seems normal now. I did forget I had my office computer hooked up to it, and when I got out there it started in on “ring 2” of the calibration before my tablet was done with the calculation, so I quickly disconnected from both, then connected my office computer to it again.

I think I’ll enter an issue for this as I forgot about it. it seems like we can fix this issue by just keeping track of the UI that acked the calibration data (with a uuid or something), and not reacting to any other ui after that during the calibration.

Maslow-serial-05-22.log (20.5 KB)

On to testing movement! :partying_face:

1 Like
9

@bar - Latest Maslow-main: So it now does not pull the bottom left belt on apply tension. I did it a few times. I watched carefully on the last one, and when I hit apply tension the bottom-right motor spun up and tightened, then the bottom left motor spun up and moved about 2-5mm and stopped. Then I get the panic because its not jiving with the coordinate system. I have your new setting at .5 and I have my retraction settings set to 2000. (also, it did go through a calibration fine) Thoughts on what might be going on there? Test output shows all the encoders ok. when I restart the machine and clear the alarm and send a $BLI it does respond by retracting a bit. At a loss here

10

This step is only dependent on the retraction setting so there must be something funky going on there with the pulling force

11

I upped the calibration retraction and it worked, then I put it back to 2000 and it still works. I’m not sure what was happening there, but I wonder if that current detection is not consistent maybe? I’ll try leaving it here for a bit while I jog around (which is going well).

Wouldn’t you know it though, I went to throw a bit in and LOL, I put the bottom plate on backward :man_facepalming: Luckily I think I can just raise to top, disconnect the z’s and just redo that one part again.

1 Like
12

more likely, the force needed varies on a lot of stuff (lubricaton of the spool,
how tight the belt is wrapped, etc)

also note that retraction force and calibration force are two different
variables, make sur ethat if you increase retraction for you also increase
calibration force

David Lang

1 Like