gestalt73 wrote:
The heated bed temp stabilization sounds like a great idea, but seems to get in the way more than it helps.
It looks like it will abort if your bed temp is +/- 0.5c, which I'm not sure that I'd be as concerned about. Maybe if we could pass a switch to ignore bed temp stabilization, or increase the allowable range a bit?
It's set to work like that because it's bad to have the temperature fluctuating when it probes. Due to the thermal mass in a heated bed system, it can take awhile for the PID algorithm to settle down and stop ringing up and down. If the bed temp changes, it WILL cause the measured depths to change, and that will throw noise into the system that you don't want to deal with. Maybe it's a pain, but so is calibrating the probe. It's better to endure that pain once than have a substandard calibration.
Twice today while working with through the G31 OPQRS step, the board has hard locked, and turned off heat to both the bed and hotend.
Both times it's occurred during probing of the third row.
After I pull power and reset it is successful on the next try.
This is with a build of the firmware pulled from git this morning.
UPDATE: I am able to get through all the steps if I reset the Smoothie after each step. I do have the GLCD enabled.
Whatever this glitch is, I didn't see in in the build I grabbed from 06/09.
Better leave the GLCD off, then. It won't help you during calibration anyway.
UPDATE 2: Ok, so here's something interesting, and I remember it happening on previous builds as well. I get to this point where it hardlocks or hardresets during the SA step, and the solution is to reformat the MicroSD card and copy the contents back onto it. After I did it for your most recent build, every step worked flawlessly. Very interesting.
It's a good idea to check the filesystem on the MicroSD card from time to time. The FS implementation on Smoothie is primitive and sometimes unreliable, especially if you mount it as a drive in your OS. The controller has no "resync" according to wolfmanjm, so if you write a file over USB and then tell Smoothie to do a write operation (e.g. run G31 A or M500),
it can corrupt files because Smoothie is not paying attention to what the host machine is writing to the card over USB. It thinks there's free space where there isn't.
wolfmanjm's advice is generally to avoid EVER mounting the SD card over USB. My procedure for doing so anyway is to never let Smoothie and the host machine OS write things to the SD card during the same session. If you have mounted the SD card to your computer over USB, do
not send M500 or G31 A until you've safely unmounted and
reset the Smoothie controller. Likewise, if you type G31 A or send M500 on a clean session, ensure that you reboot the controller BEFORE you mount the card over USB. NEVER, EVER do write operations via Smoothie and from your computer during the same session (without rebooting the controller) or you're going to chew up a file sooner or later. Maybe config, maybe your autolevel information from G31 A, maybe config-override. Whatever gets corrupted, it won't be any fun for you.
Another important thing to remember: if you mount the SD card and save a .gcode file to it, remember to unmount the card before you hit the start button on a print job. Otherwise, your OS may just randomly decide it wants to scan the SD card or check it for something. Even moderate read/write operations to the SD card will hang the Smoothie board until the operation is complete. If you're saving a .gcode file and you send G28, don't be surprised if your printer keeps trying to move the carriages up after they already hit the endstop switches (which, by the way, will fail to cause Smoothie to stop). It will grind your belts and make a horrendous noise.
It now takes under 10 seconds to anneal the variables. You still have to wait ages for it to probe the bed, but now you don't have to wait 1-2 minutes for it to do the calculations!!!
