There has been a lot of cleanup and handling of corner cases on the auto-grid-size (in the green) PR, so it needs some testing. I especially need someone with a good large frame to set the spacing between points small so that it generates a very large number of points (this is a setting in manlow.yaml, defaulting to 400mm betwen points)
I’ve been going through the code manually to trace the workflow and I caught a few problems, including
deciding on the grid size before we take the first measurements, so we don’t really know the frame size
allocate the array to hold the list of points before we calculated how many points we were going to have
and some others that came from those.
Not good. Powered down the Maslow, powered it back up. Started fluidterm on USB port.
All looked good, then I clicked on one of the arrow keys and all 4 belts started unwinding, so I hit the power. It pushed out about 6 inches of belt before power went off from all belts. Serial port disconnected is where I powered down, then restarted Maslow
did you do the retract/extend and jogging before what is logged? or was this still setup from the last failed run with the same numbers?
I’m going to dig into things tomorrow afternoon (az time) and find what $ commands are there that will let me get position and status reports so that you can run them after jogging (before shutting down) and after startup (before you start jogging)
it did load the belt lengths and it set the state to ready-to-cut
[MSG:DBG: Belt positions loaded from NVS: TL=2061.511 TR=1814.033 BL=1967.473 BR=1895.724 newState=7]
I’m busy for the next hour or so. will get back to you later. No I this run i just loaded powered down and restarted the Maslow.
Started again this AM
Hooked up the usb connection, powered up the Maslow and connected by usb.
logged in and did the retract extend dance. jogged the Maslow a few times.
Powered down and back up, set the XY to 10mm and then tried to jog. Maslow released a small amount of belt on all motors similar to release tension then tried apply tension got message Cannot take slack until belts have been extended
If you can get me the logs before the shutdown showing the belt lengths that are
being saved, we can then compare them to the belt lengths found and loaded.
my guess at this point is some other internal variables aren’t getting
re-initialized.
I did ask for a fix for the spools slowly running out, and it found a corner
case that could account for it.
Logs 93 and 94 above are the before and after which I ran this morning, the SerialDump is corresponding to 93 & 94. for some reason it saves as 92-93 but that is incorrect
Logs 93 and 94 above are the before and after which I ran this morning, the
SerialDump is corresponding to 93 & 94. for some reason it saves as 92-93 but
that is incorrect
Thanks, I think it found the problem (extended* variables not being set) but
instead of just setting them, it added a whole new set of functions to save and
restore the belt positions (without removing the first set)…
I need to go unload a trailer in my driveway, if it fails again, I may just
hand-peck those changes into the restore function and have you test that.
I may have panicked the 1st time it started feeding out belts, it looks more like it was going to Release tension, although the status doesn’t match. State is Ready to cut, but the belts are slack
before (only partial recorded in dump file)
L=1886.233 BR=1975.107 state=7]
After restart
[MSG:DBG: Belt positions loaded from NVS: TL=1979.111 TR=1896.422 BL=1886.233 BR]
if you jog, and pause, you should see in the log that it saves the belt positon
if you fully retract and pause, you should see in the log that it saves the belt
position.
when you do anything else after this, you should see it say that it’s marking
the belt positon stale
if you restart with the belt position stale, you should have to do the full
retract/extend/apply tension dance.
if you restart with the belt position not stale, you should be able to jog, cut,
etc without having to do more (except possibly disable the alarm, I’m not sure
what it does, and I’m not sure what the right behavior is, I can see arguments
either way)
System thinks I have posted too much, and I should give others a share!!
What happened:
loaded the new version (somehow my Maslow.yaml got corrupted so I had to restore it)
powered down, did the dance, moved the Maslow a few times. I didn’t turn on debug in the yaml file so didn’t get all the current readings now, much cleaner.
Powered off again and restarted, comes up in ready to cut. Tried a jog and all 4 motors ran out some belt. tried again and a about 50 mm rolled out on all belts.
System thinks I have posted too much, and I should give others a share!!
What happened:
loaded the new version (somehow my Maslow.yaml got corrupted so I had to restore it)
powered down, did the dance, moved the Maslow a few times. I didn¢t turn on debug in the yaml file so didn¢t get all the current readings now, much cleaner.
Powered off again and restarted, comes up in ready to cut. Tried a jog and all 4 motors ran out some belt. tried again and a about 50 mm rolled out on all belts.
you restarted, then did a jog and it relaxed the belts (and saved the new belt lengths)
from the serial logs, we see the belt lengths get loaded
[MSG:INFO: loadBeltPositions() called]
[MSG:INFO: Validity check: ret=0 validityMarker=1]
[MSG:INFO: Belt position load: Set currentState directly to READY_TO_CUT]
[MSG:DBG: Set Calibration extended* variables to true (belts are extended)]
[MSG:DBG: Belt positions loaded from NVS: TL=1996.106 TR=1885.514 BL=1896.078 BR=1958.]
[MSG:INFO: Starting Maslow Version 1.12]
then in the UI we see you jog and it save the belt lengths
JogTo: '$J=G91F2500X10
’
[MSG:DBG: Belt positions saved to NVS: TL=9.931 TR=16.061 BL=14.633 BR=11.198 state=7]
and in the serial logs, we see the belt positions saved
[MSG:DBG: Belt positions saved to NVS: TL=9.931 TR=16.061 BL=14.633 BR=11.198 state=7]
(same length, good).
then you tried to apply tension, but couldn’t, so you tried relaxing tension and then applying tension, but by then the belt lengths are bad
It may have found it. the belt positions loaded were:
TL=1996.106 TR=1885.514 BL=1896.078 BR=1958
you tried to do a small jog and it then saved the belt positions as:
TL=9.931 TR=16.061 BL=14.633 BR=11.198
this is a massive difference. It found that it was setting their length in mm, but not setting the encoder positions. It claims to have done that now.
it also misunderstood the problem and made it possible to apply tension when it’s ready-to-cut. Given the problem that people have with slack belts, I’m not sure that’s a bad change. @bar ??? it should not be needed, but I think that after applying slack it figures out where it is, so I don’t think it will hurt anything.
so here is a version that sets the encoders correctly, let’s see what happens here.