I installed 0.86 today and tried to run a calibration since my last calibration was on 0.85. Everything runs good until shortly after the last point in the 3x3 grid is measured. The calibration values are saved, but the machine then does an emergency stop without even moving.
After reboot, the belts won’t extend until I put the old config back. It happened 3 times in a row before I just went back to 0.85.
From the log, I appears to be a 9 by 9 grid with dimensions of 2000mm by 1000mm. I would change the calibration grid size to something like 3x3 or 5x5 and run a calibration (the calibration grid dimensions will have to be reduced too). After running that calibration, the newly-calibrated dimensions will get saved into the yaml file. At that point, you can increase the grid dimensions and just run calibration again using numbers that it came up with in the calibration right before. The more points in the calibration grid the more finicky it can also be and the more accurate you need your inputted frame dimensions to be.
One thing I forgot to mention was that for 1 of those runs, I re-entered a measurement of my frame, but for the other two I used the values from the last calibration.
I just noticed that the new config file with 0.86 has a default of 7x7 and a smaller calibration area. So, I tried again with the new firmware and the config file provided in the release and got the same error.
Can you try tweaking the initial values for the frame a bit and see if that changes anything? There seems to be something about the initial guess for the frame size that it’s choking on.
Having the same issue. I think the 0 x 0 frame size is because the frame config settings are reset at the beginning of the calibration and it fails after the first 3x3 measurement. Going to try running the 3x3 first and see if that helps.
Well, I was able to find some time today to give it a shot and unfortunately, I had the same result
This is the config afterwards maslow-4.yaml (5.3 KB)
And the log from the calibration (default 7x7) Maslow-serial 2.log (5.6 KB)
and a screenshot showing that I do indeed have more space now,
I don’t know if it’s significant, but I noticed that in the serial log, right before the machine emergency stopped, it output X and Y coordinates for the TL, TR, BL, and BR. The values (x, y) are TL (-2.3, 2420), TR (2933.8, 2416.9), BL (-2.3, 2420), and BR (2933.8, 2416.9). The (i) TL and BL and (ii) TR and BR are identical points, respectively.
That for sure seems significant. I’m not replicating the exact same behavior, but I am seeing something going wrong with the way calibration messages are being sent and I’m digging into it.
@md8n Do you have any thoughts on this? It seems like the calibration data is not being relayed to the firmware successfully, but I’m having a hard time understand why. It seems to me like sendCalibrationEvent() is being called with valid data, but it’s throwing the error:
function sendCalibrationEvent(dataToSend, log = false)
The default for log if it is not supplied is false. However, if log is true then it will do this:
console.log(JSON.stringify(dataToSend, null, 2));
So if logging is on, but dataToSend is not valid JSON then you will definitely get a “parsing error”
JSON has specific requirements that are tighter than Javascript, for example JSON requires double quotes (") around strings and field names, not single quotes ('). There are JSON validators online to check things.