SamrtABL seems to be non functional on my system #22
Comments
|
Hi, with that excerpt I meant that the first print when you connect your printer is automatically ABL enforced due to how prusa/klipper works (doesn't "allow" mesh saving). So the first print when you connect your printer always do an ABL (automatically) to start tracking the state. Every time an ABL is triggered, the counter is reset, so the counter is set to 0. If you keep printing, the counter will be increased by one every time, and when you get to 5/5 (or the number you set), ABL is triggered again and the counter is reset. For some reason, the output received from G81 (to query the mesh state) is incorrect, so you're forced to ABL again. Can you give me the output from the gcode G81? |
|
Thank you for clarifying, I understand. This is the output of G81 (after powering on the printer, connecting it to OctoPrint and printing one object): |
|
Is ABL being triggered every print? Can you share your logs after completing 2 o 3 prints? |
|
Yes, every print. Here are the logs after a couple of more prints: octoprint-systeminfo-20230730121817.zip |
|
can you test this? Start a print and paste the output here (right before ABL starts), I need the exact output of the G81, because I don't understand why the plugin isn't recognizing the above output (it should match) |
|
This is the output: |
|
I see, can you share your starting gcode? I don't know why you're receiving the message "Mesh bed leveling not active", that's why the plugin forces ABL |
|
This is the output from the start (I hope that's what you meant? Or do you want the gcode of the printed file?): |
|
I meant the gcode you use in the slicer, that is put on every file at the start |
|
That should be this code (I use PrusaSlicer, the code it from the Start G-code section): |
|
Can you test these commands in your octoprint terminal? And paste the output here? |
|
Here it is: I'm wondering, have you ever successfully tested this plugin on a Prusa MK3? |
|
Some users have used SmartABL successfully in their prusa (all variants). I'm not loading the mesh from prusa because prusa doesn't have eeprom enabled in their firmware. I don't know why the output from G81 is different now and when I send it from the plugin... for some reason the mesh is disabled when you start a print. I don't know what could be the problem, to be honest. I'll ask in discord if some user has encountered the same problem |
|
As far as I understand it "G28 W" deletes the mesh data. |
|
No, G28 W just home your axes without doing ABL. G80 does the ABL, so it should return the mesh after G81 https://help.prusa3d.com/article/prusa-specific-g-codes_112173 |
|
This is what happens when I send After sending G28 W, G81 does not return the measurements anymore. |
|
Mmmm, ok, I'll investigate that. Thanks for your feedback |
|
I confirmed that this same behaviour of disabling the mesh bed levelling after a AnalysisMore specifically, from reading the relevant parts of the firmware, re-enabling the mesh bed levelling after homing only happens when:
This means that after running any Why G28 W does not solve this issueFor what it's worth, the documentation is a bit vague (misleading, even) on the actual meaning of the First, it skips queuing up a subsequent Option 1: Resetting the MBL flagIt turns out there actually is an undocumented(!) Prusa-specific G-CODE for setting the MBL flag manually. It's For example, the following sequence of commands does succeed: One caveat of this command is that the code has the following comment (closest thing to documentation we have): I am not sure, but I believe this means that the current Z position will be retained as-is, without actually adjusting for the bed levelling correction. While I do not have more time to dig into this today, it seems that the commit that introduced this command (for recovering in the event of a power failure) does a fair bit of additional logic to restore the actual Z position so that it's correct after you do reenable the MBL: prusa3d/Prusa-Firmware@eb2ca78 Of course, since we are not dealing with anything like a power-panic, this plugin would be free to read out and store both the logical and physical Z positions before we attempt to re-home that axis. This could simplify things greatly. Whether dealing with such highly firmware-specific logic and workarounds is within scope of this plugin is another question too. Option 2: Avoid Z-homingUntil we know what the above G-CODE command actually does and how it is intended to be used, here is a different workaround. It is functional but only safe if you do not power down the machine (or steppers) between prints. Just replace the Of course, this could cause big issues if the counter of SmartABL isn't reset to 0 as needed, say, after the printer powers off or the stepper motors are disabled. If the Z position shifts, you could end up printing the first layer too high (at best) or ramming the nozzle down in the print bed (at worst). I would be comfortable going with this option if I was sure that SmartABL doesn't save the counter between OctoPrint sessions (since I power off my OctoPi whenever I turn off the printer). I also can't figure out if there is a way to tell SmartABL to replace one G-CODE command with another in the "happy path" (when it determines that no ABL is needed), or if all you can do is filter it out. If so, you'd have to make an additional workaround in your slicer, as follows: and then configure SmartABL to trigger on Note that this assumes that the subsequent lines move Z to a sensible position instead of hovering in the air where it has remained since the previous print. I think slicers ought to set the Z value in the first move command, so it really shouldn't be a problem in practice. If in doubt, you could always add one more command after the ones above to move it to the origin (where a full re-homing would have left it): Final wordsFor what it's worth, I also struggle to see how this could ever have worked for others. The logic for MBL in Prior to that commit, it looks like But maybe something else changed in between the above two commits, where it briefly did work at some point. Or indeed elsewhere in the code: I only read through the function in question looking for the logic to restore the bed mesh after seeing it gets disabled early on and certainly don't have a good grasp of the entirety of the code base. I did some quick code searches to see if there are other parts of the program that would restore the In any case, I believe this ticket is still valid. As it stands, the documentation for SmartABL strongly implies that it works on Prusa printers, but it simply does not, and cannot given what the firmware says. At the very least this should be clarified, whether or not this has always been the case or if it is a regression. And if either of the two findings above sound reasonable and their kinks can be worked out, this could also point to a solution to bring it (back?) into functionality. |
|
Thanks jmickelin for your thorough analysis! I'll look into this issue again and see how can I fix it based on your solutions |
|
Actually, SmartABL always resets the counter when octoprint reconnects (shutdown, close and open serial, w/e)
So, on my side, I would just need to change the default ABL gcode to trigger on |
|
Oh, that's fantastic! Certainly beats the other hacky solution with the undocumented GCODE. Actually, the trigger would be just At least as of the current default printer profile for MK3S in PrusaSlicer (v2.7.4): Additionally, maybe it should also trigger on a lone For just The second one might not arise in practice, unless someone has tweaked their starting GCODE, likely indicating that they know what they are doing anyway. So maybe they would want to configure this case themselves if they do want it to trigger SmartABL. But it is the remaining corner case of this I can absolutely help you out with testing! I haven't installed any beta-plugins from outside the normal web-UI installer in the settings, but I assume it would be as simple as running a manual EDIT for the sake of clarification: The part where I mentioned EDIT 2: In a previous version of this comment I misremembered some of my previous findings about |
|
Hi, sorry for the late response. Isn't skipping Z-home a problem? What would happen in the case that you finished a print in Z-150? If motors are disabled (the most common case after a print), it's normal the Z axis loses some height (that's why you should always launch Z-homing after a print), which is the scenario you depict here (which I don't understand how the counter affects it, if you do multiple prints one after another without shutting down the printer, the scenario will happen 100%)
P.S1: Installing test version is just as easy as install using a url (same way as normal plugins, but scrolling at the end shows a box to input the url), I'll generate a pre-release version that can be installed. |
|
Good point about the motors turning off. That certainly seems to be the default in the printer profiles I've used. I guess this kind of kills the chance of Option 2 working reliably. And a Z-home being required in turn forces the printer to disable the MBL status, so we are left with a few options:
Sorry for being so slow to respond, by the way! I get easily distracted by things. I'll add you on Telegram, but I can probably not be available to discuss and try things actively until this weekend :) |
The problem
After reading the readme multiple times, uninstalling and reinstalling several times I still can't get the plugin to work.
It's totally possible that I'm doing something wrong, but as for now I have no idea what that could be.
The only thing in the readme which I'm not quite sure about is this sentence:
Is that something which I need to do manually?
Or does it mean that the first print has to be with ABL?
Other than that, I saw this in the side panel:
After installation of SmartABL the P/FP shows 0/5
After the first print (with ABL) finishes it shows: 1/5
Starting the second print ABL is performed again, after which the P/FP shows: 0/5
After the second print finishes P/FP shows 1/5 again
As said, it might be totally my mistake, but I still hope to find a pointer here.
Version of SmartABL
1.2.2
Version of OctoPrint
1.92
Operating system running OctoPrint
OctoPi 0.18.0
Printer model & used firmware incl. version
Prusa i3MK3S+ FW 3.13.0
Browser and version of browser, operating system running browser
No response
Checklist of files to include below
Additional information & file uploads
octoprint-systeminfo-20230729133341.zip
plugin_SmartABL.log
helper_disk_0.4n_0.2mm_PLA_MK3S_1m.gcode.zip
The text was updated successfully, but these errors were encountered: