Weekly updates aren’t nearly fast enough so we are ending up with different version in different forums threads which is going to lead to confusion.
I’m starting this thread as a place to store all of the versions which aren’t full releases so that we can give them all numbers and keep them organized.
Starting out this is 0.64.2 which adds separate current thresholds for when retracting the belts after clicking “Retract All” and for taking measurements during the calibration process. Both of these can be set from within the maslow.yaml file using the parameters:
Increasing Maslow_Retract_Current_Threshold will cause the machine to pull harder when retracting the belts and increasing Maslow_Calibration_Current_Threshold will cause the machine to pull harder when taking measurements during the calibration process.
are all of these in git? on github? do they show up as releases? can we
configure the firmware to try and check with github on startup to flag that
there is a new version (if not having the maslow reach out to github, have a box
on the UI that says ‘currently running versionX, latest release is versionY’ by
embedding a link to github to have the browser fetch the versionY info)
They are on github, but they will not show up as full releases. These are more of intermediate builds for testing things and as a way to get quick fixes out for specific issues. Full releases will still happen on Wednesdays.
I agree that an automatic reminder to update is a great idea. It’s on my todo list.
You can now set the offset for the calibration grid corners in both the X and Y directions (on a long narrow frame having them be the same doesn’t make sense) and also set the number of points in the calibration pattern.
This is particularly useful for testing when you don’t want to wait for the whole pattern to run. A setup like
Will give you a nice little 4x4 grid right in the middle of the frame which won’t take very long to run. index.html.gz (153.7 KB) maslow.yaml (2.0 KB) firmware.bin (1.6 MB)
Here is 0.64.4 which makes the communication protocol between the calibration process more robust.
The way it used to work was that after the calibration process is complete the machine would send the measurements to the computer to be computed and wait for the results.
The problem with that is that if there is an issue with the communication (computer has gone to sleep, browser window closed…etc) the computation would never happen.
Now the way it works is that the machine asks for confirmation from the computer that it has received the measurements. If it doesn’t get confirmation it will keep trying to send the data until it does. This means that if the browser is closed or the computer falls asleep etc the computation will happen when the connection is re-established.
Communication doesn’t seem to be broken as I went back to the browser and issued
$$
$10=1
ok
EDIT:
So I clicked the self test button and it spit out some points, but the last message that was sent seemed of interest. [MSG:INFO: Grid size: 10x9] So is the maximum calibration 10 not 11 like specified in the maslow.yaml and there is some sort of out of index array happening?
EDIT 2:
Confirmed Maslow_calibration_size_X: 10 still brings it all the way to the left and stops after the first point.
Right now we’re allocating enough memory for 100 points so I don’t think it is a memory out of bounds thing.
I’m pretty stumped on why it’s stopping. I don’t think that it’s crashing it’s just entering some state where it decided that it doesn’t want to move anymore.
If you give the belts a bit of a push and pull does anything change?
What happens if you click the calibration button again after it’s stopped?
What do you see if you run a really small test grid (4x4 or something like that) right in the center of the sheet?
This is going to sound crazy, but what happens if you close the browser tab right after starting the calibration process?
I will try flashing and running the 0.64.4 again if I have time today. I did try 3 different times on that nightly version with slightly different offsets and dropping the count down to 10 on the x. All three resulted in the same results, though slightly different stuck positions in Y.
Push or pulling the belts didn’t seem to do anything. I didn’t click calibrate again and did not try a smaller test grid. I also had the browser tab open then entire time.
Is it getting stuck in the move state (two belts slack) or the taking a measurement state (all belts tight)?
It’s not printing out any warnings, right? I know that it takes each measurement five times and then checks that they are all the same (to make sure that nothing has gone wrong). If they aren’t all the same it will try again in the same spot, but if it keeps failing it will eventually give up. That should print out a warning though which we aren’t seeing
Be sure to do both the firmware and index.html files because the changes are in both…100% sure that’s not the issue we’re seeing though because the changes are only to the calculations at the end.
I am also getting motor current errors - these can be cleared by resetting the alarm and then restarting calibration but I don’t understand why as I have set a lower figure in the yaml file…?
Correctly calculates a 16 point grid but goes no further than the first point
@bar something odd when I issue the $all at command line as despite all belts being slack, unless I issue a $stop, it ignores the command despite getting an OK in the console. It may be the calc routine is stuck in a loop moving in a smaller array of waypoints…??
So it always gets stuck on the very first point? That’s good, I think, at least it happens consistently. Better that than something which happens every once in a while.
It looks like it’s successfully taking a measurement at the first point and then not moving on to the second point. Does that match up with what you are seeing in practice…IE moves to the first point, pulls the belts tight, then stops?
I think that you are spot on. This feels like what’s happening to me. I think that it thinks that its moving to the next point, but because of some math issue it isn’t. I found (and I think fixed) a very similar issue last week where if it was commanded for some reason to move from some coordinates back to the same coordinates it would get stuck forever in an infinite loop.
That one was easier to catch because I was able to make it happen so I could debug.
Let me make a version which will print out more information and maybe it will tell us what is going on
I have the changes made, but for some reason I have to reinstall the ESP-IDF to build the firmware.bin file and the ESP-IDF is huge so it’s taking a long time to download
