search

scmanjarrez / OctoPrint-SmartABL

Plugin designed to expedite your 3D printing process. It smartly reduces unnecessary Auto Bed Leveling (ABL) actions
https://plugins.octoprint.org/plugins/SmartABL/
GNU Affero General Public License v3.0
10 stars 1 forks source link

SamrtABL seems to be non functional on my system #22

Open ulfertg opened 1 year ago

ulfertg commented 1 year ago

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:

Warning: Prusa and Klipper require at least 1 ABL to track the state.

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

scmanjarrez commented 1 year ago

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?

ulfertg commented 1 year ago

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):

end: G81
Recv: Num X,Y: 7,7
Recv: Z search height: 5.00
Recv: Measured points:
Recv:   0.03550  0.20800  0.32300  0.38600  0.36250  0.28450  0.26450
Recv:   0.14950  0.27050  0.34300  0.34350  0.36150  0.35600  0.29000
Recv:   0.18150  0.32050  0.40300  0.37450  0.37750  0.35200  0.25350
Recv:   0.13950  0.29150  0.36400  0.37400  0.32113  0.26800  0.16500
Recv:   0.20200  0.28950  0.34150  0.30962  0.26500  0.20950  0.07100
Recv:   0.23000  0.27950  0.28850  0.25800  0.20600  0.12800  -0.03150
Recv:   0.12950  0.16050  0.17100  0.09750  0.04350  -0.05850  -0.21300
Recv: ok
scmanjarrez commented 1 year ago

Is ABL being triggered every print? Can you share your logs after completing 2 o 3 prints?

ulfertg commented 1 year ago

Yes, every print. The log I've attached to my first post was after two prints iirc.

Here are the logs after a couple of more prints:

octoprint-systeminfo-20230730121817.zip plugin_SmartABL-2.log

scmanjarrez commented 1 year ago

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)

ulfertg commented 1 year ago

This is the output:

Recv: echo:busy: processing
Recv: E-motor current scaling enabled
Recv: ok
Send: N18 G81*41
Recv: Mesh bed leveling not active.
Recv: ok
Send: N19 G80*41
Recv: T:214.9 /215.0 B:59.9 /60.0 T0:214.9 /215.0 @:28 B@:68 P:0.0 A:31.9
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: echo:busy: processing
scmanjarrez commented 1 year ago

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

ulfertg commented 1 year ago

This is the output from the start (I hope that's what you meant? Or do you want the gcode of the printed file?):

Changing monitoring state from "Operational" to "Starting"
Send: N0 M110 N0*125
Recv: ok
Changing monitoring state from "Starting" to "Printing"
Send: N1 M73 P0 R1*21
Recv: NORMAL MODE: Percent done: 0; print time remaining in mins: 1; Change in mins: -1
Recv: SILENT MODE: Percent done: 100; print time remaining in mins: 0; Change in mins: -1
Recv: ok
Send: N2 M73 Q0 S1*22
Recv: T:214.8 /215.0 B:60.6 /60.0 T0:214.8 /215.0 @:30 B@:4 P:0.0 A:32.1
Recv: NORMAL MODE: Percent done: 0; print time remaining in mins: 1; Change in mins: -1
Recv: SILENT MODE: Percent done: 0; print time remaining in mins: 1; Change in mins: -1
Recv: ok
Send: N3 M201 X1000 Y1000 Z200 E5000*10
Recv: T:215.1 /215.0 B:60.5 /60.0 T0:215.1 /215.0 @:26 B@:26 P:0.0 A:32.1
Recv: ok
Send: N4 M203 X200 Y200 Z12 E120*8
Recv: ok
Send: N5 M204 S1250 T1250*39
Recv: ok
Send: N6 M205 X8.00 Y8.00 Z0.40 E4.50*57
Recv: ok
Send: N7 M205 S0 T0*36
Recv: ok
Send: N8 M862.3 P "MK3S"*12
Recv: ok
Send: N9 M862.1 P0.4*99
Recv: ok
Send: N10 M115 U3.11.0*97
Recv: ok
Send: N11 G90*32
Recv: ok
Send: N12 M83*43
Recv: ok
Send: N13 M104 S215*81
Recv: ok
Send: N14 M140 S60*102
Recv: ok
Send: N15 M190 S60*106
Recv: LCD status changed
Recv: LCD status changed
Recv: ok
Send: N16 M109 S215*89
Recv: LCD status changed
Recv: T:215.3 /215.0 B:60.5 /60.0 T0:215.3 /215.0 @:24 B@:20 P:0.0 A:31.8
Recv: T:215.1 E:0 W:1
Recv: echo:busy: processing
Recv: T:214.9 E:0 W:0
Recv: T:214.8 /215.0 B:60.4 /60.0 T0:214.8 /215.0 @:29 B@:38 P:0.0 A:32.0
Recv: LCD status changed
Recv: ok
Send: N17 G28 W*82
Recv: tmc2130_home_enter(axes_mask=0x01)
Recv:   0 step=45 mscnt= 735
Recv: tmc2130_goto_step 0 13 2 1000
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x01
Recv: tmc2130_home_enter(axes_mask=0x02)
Recv: T:215.1 /215.0 B:60.3 /60.0 T0:215.1 /215.0 @:26 B@:47 P:0.0 A:31.9
Recv: echo:busy: processing
Recv: T:215.0 /215.0 B:60.3 /60.0 T0:215.0 /215.0 @:27 B@:42 P:0.0 A:32.1
Recv: echo:busy: processing
Recv: T:215.1 /215.0 B:60.2 /60.0 T0:215.1 /215.0 @:26 B@:62 P:0.0 A:32.1
Recv:   0 step=33 mscnt= 543
Recv: tmc2130_goto_step 1 33 2 1000
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x02
Recv: echo:busy: processing
Recv: E-motor current scaling enabled
Recv: T:215.2 /215.0 B:60.2 /60.0 T0:215.2 /215.0 @:25 B@:49 P:0.0 A:31.9
Recv: echo:busy: processing
Recv: T:214.9 /215.0 B:60.0 /60.0 T0:214.9 /215.0 @:28 B@:66 P:0.0 A:32.0
Recv: echo:busy: processing
Recv: E-motor current scaling enabled
Recv: ok
Send: N18 G81*41
Recv: Mesh bed leveling not active.
Recv: ok
Send: N19 G80*41
Recv: T:214.9 /215.0 B:59.9 /60.0 T0:214.9 /215.0 @:28 B@:68 P:0.0 A:31.9
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: echo:busy: processing
scmanjarrez commented 1 year ago

I meant the gcode you use in the slicer, that is put on every file at the start

ulfertg commented 1 year ago

That should be this code (I use PrusaSlicer, the code it from the Start G-code section):

M862.3 P "[printer_model]" ; printer model check
M862.1 P[nozzle_diameter] ; nozzle diameter check
M115 U3.11.0 ; tell printer latest fw version
G90 ; use absolute coordinates
M83 ; extruder relative mode
M104 S[first_layer_temperature] ; set extruder temp
M140 S[first_layer_bed_temperature] ; set bed temp
M190 S[first_layer_bed_temperature] ; wait for bed temp
M109 S[first_layer_temperature] ; wait for extruder temp
G28 W ; home all without mesh bed level
G80 ; mesh bed leveling
{if filament_settings_id[initial_tool]=~/.*Prusament PA11.*/}
G1 Z0.3 F720
G1 Y-3 F1000 ; go outside print area
G92 E0
G1 X60 E9 F1000 ; intro line
G1 X200 E27 F500 ; intro line
{else}
G1 Z0.2 F720
G1 Y-3 F1000 ; go outside print area
G92 E0
G1 X60 E9 F1000 ; intro line
G1 X200 E30.5 F500 ; intro line
{endif}
G92 E0
M221 S{if layer_height<0.075}100{else}95{endif}
scmanjarrez commented 1 year ago

Can you test these commands in your octoprint terminal?

G28 W
G80
G81

And paste the output here?

ulfertg commented 1 year ago

Here it is: 

[...]
Send: G28 W
Recv: tmc2130_home_enter(axes_mask=0x04)
[...]
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x04
Recv: tmc2130_home_enter(axes_mask=0x01)
Recv:   0 step=13 mscnt= 223
Recv: tmc2130_goto_step 0 13 2 1000
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x01
Recv: tmc2130_home_enter(axes_mask=0x02)
[...]
Recv:   0 step= 1 mscnt=  30
Recv: tmc2130_goto_step 1 33 2 1000
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x02
[...]
Recv: ok
[...]
Send: G80
[...]
Recv: LCD status changed
Recv: ok
[...]
Send: G81
Recv: Num X,Y: 7,7
Recv: Z search height: 5.00
Recv: Measured points:
Recv:   0.07550  0.20750  0.29750  0.36200  0.34550  0.29300  0.37700
Recv:   0.16300  0.24300  0.28750  0.27700  0.31450  0.33900  0.32000
Recv:   0.16750  0.26000  0.32500  0.29900  0.31350  0.31850  0.25350
Recv:   0.12050  0.22550  0.27500  0.28050  0.24750  0.20350  0.14100
Recv:   0.20200  0.24050  0.27400  0.23375  0.19250  0.16800  0.05900
Recv:   0.24400  0.24050  0.22800  0.18800  0.14750  0.09400  -0.01800
Recv:   0.17250  0.14600  0.12600  0.04450  0.01200  -0.05800  -0.15050
Recv: ok
[...]

I'm wondering, have you ever successfully tested this plugin on a Prusa MK3? I'm beginning to wonder if it's even possible to store and reload an ABL mesh on a Prusa?

scmanjarrez commented 1 year ago

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

ulfertg commented 1 year ago

As far as I understand it "G28 W" deletes the mesh data. Hence "G81" after "G28 W" returns "Mesh bed leveling not active." But I could be wrong.

scmanjarrez commented 1 year ago

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

ulfertg commented 1 year ago

This is what happens when I send G81 G80 G28 W G81

After sending G28 W, G81 does not return the measurements anymore. That was the reason I assumed that G28 W deletes the mesh data.

Recv: ok
[...]
Send: G81
Recv: Mesh bed leveling not active.
Recv: ok
[...]
Send: G80 N3 R3
Recv: echo:Enqueing to the front: "G28 W"
Recv: tmc2130_home_enter(axes_mask=0x04)
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x04
Recv: tmc2130_home_enter(axes_mask=0x01)
Recv:   0 step=14 mscnt= 225
Recv: tmc2130_goto_step 0 13 2 1000
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x01
Recv: tmc2130_home_enter(axes_mask=0x02)
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
Recv:   0 step= 2 mscnt=  35
Recv: tmc2130_goto_step 1 33 2 1000
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x02
Recv: E-motor current scaling enabled
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
Recv: E-motor current scaling enabled
[...]
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: echo:busy: processing
[...]
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: echo:busy: processing
[...]
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: echo:busy: processing
[...]
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: echo:busy: processing
[...]
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: echo:busy: processing
[...]
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: echo:busy: processing
[...]
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: echo:busy: processing
[...]
Recv: E-motor current scaling enabled
Recv: echo:busy: processing
[...]
Recv: LCD status changed
Recv: ok
[...]
Send: G81
Recv: Num X,Y: 7,7
Recv: Z search height: 5.00
Recv: Measured points:
Recv:   0.06000  0.17744  0.26878  0.33400  0.37311  0.38611  0.37300
Recv:   0.06722  0.18349  0.26841  0.32196  0.34416  0.33500  0.29448
Recv:   0.07833  0.18331  0.25517  0.29391  0.29953  0.27204  0.21143
Recv:   0.09333  0.17689  0.22906  0.24983  0.23922  0.19722  0.12383
Recv:   0.11222  0.16423  0.19007  0.18974  0.16323  0.11056  0.03170
Recv:   0.13500  0.14535  0.13822  0.11363  0.07157  0.01204  -0.06496
Recv:   0.16167  0.12022  0.07350  0.02150  -0.03578  -0.09833  -0.16617
Recv: ok
[...]
Send: G28 W
[...]
Recv: tmc2130_home_enter(axes_mask=0x01)
Recv:   0 step=45 mscnt= 733
Recv: tmc2130_goto_step 0 13 2 1000
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x01
Recv: tmc2130_home_enter(axes_mask=0x02)
Recv: echo:busy: processing
[...]
Recv:   0 step=34 mscnt= 545
Recv: tmc2130_goto_step 1 33 2 1000
Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x02
Recv: E-motor current scaling enabled
Recv: E-motor current scaling enabled
Recv: ok
[...]
Send: G81
[...]
Recv: Mesh bed leveling not active.
Recv: ok
scmanjarrez commented 1 year ago

Mmmm, ok, I'll investigate that. Thanks for your feedback

jmickelin commented 4 months ago

I confirmed that this same behaviour of disabling the mesh bed levelling after a G28 W happens on my MK3S+ too.

Analysis

More 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 G28 command that implies the Z axis is homed, it will not be re-enabled until you do a full G80 probe. The values are still there, and even get reloaded from the EEPROM, but they are not used, and the variable that is checked by G81 is stuck at false.

Why G28 W does not solve this issue

For what it's worth, the documentation is a bit vague (misleading, even) on the actual meaning of the W argument. It says it "[homes] all axes (no mesh bed leveling)" and that it "[suppresses] mesh bed leveling if X, Y or Z are not provided". What it actually does is the following: G28 changes its behaviour slightly if you explicitly tell it one or more axes to home.

First, it skips queuing up a subsequent G80 command that runs after completing the G28. Secondly, it tries to restore the MBL flag (with the caveats mentioned above). The only thing W does is to force this behaviour even when you do not supply one of the axes as an argument. That is: G28 W is more or less equivalent to G28 X Y Z, whereas G28 is equivalent to G28, G80.

Option 1: Resetting the MBL flag

It turns out there actually is an undocumented(!) Prusa-specific G-CODE for setting the MBL flag manually.

It's PRUSA MBL V, where V can be set to either 0 (disable) or 1 (enable).

For example, the following sequence of commands does succeed:

G80
G81
G28 W
PRUSA MBL V1
G81

One caveat of this command is that the code has the following comment (closest thing to documentation we have): Change the MBL status without changing the logical Z position.

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: https://github.com/prusa3d/Prusa-Firmware/commit/eb2ca78167fbec4ded3731a00f9cad921adbea39

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-homing

Until 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 G28 W with G28 X Y, and simply do not re-home the Z-axis between prints.

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:

G28 X Y
G28 Z
G80

and then configure SmartABL to trigger on G28 Z, G80. This way, the first line will always be passed through, and the Z-homing and mesh probing only happen when needed.

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):

G28 X Y
G28 Z
G80
G0

Final words

For what it's worth, I also struggle to see how this could ever have worked for others.

The logic for MBL in G28 seems to have been the same since it was introduced in September 2017: https://github.com/prusa3d/Prusa-Firmware/blob/480838a0a1e65942bc1815a870510fa909f6b6bb/Firmware/Marlin_main.cpp#L2355

Prior to that commit, it looks like mbl.active just was never restored at all (again, until you ran a G80).

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 mbl.active variable automatically, but couldn't find anything noteworthy. It could also be the case that other people's slicer profiles ran some other code for the re-homing step than the out-of-the-box profiles.

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.

scmanjarrez commented 4 months ago

Thanks jmickelin for your thorough analysis! I'll look into this issue again and see how can I fix it based on your solutions

scmanjarrez commented 4 months ago

Actually, SmartABL always resets the counter when octoprint reconnects (shutdown, close and open serial, w/e)

Well, it doesn't reset the counter, but forces a probing on prusa/klipper which in the end resets the counter

So, on my side, I would just need to change the default ABL gcode to trigger on G28 W, G28, G80 and then send to the printer the gcodes G28 X Y, G28 Z, G80? P.S.: Do you mind helping me with some test versions to check that everything works as expected? I don't have prusa printer, so it's very difficult for me to gather logs and inspect the behavior.

jmickelin commented 4 months ago

Oh, that's fantastic! Certainly beats the other hacky solution with the undocumented GCODE.

Actually, the trigger would be just G28 W, G80 with no extra G28 in the middle. The thing to send to the printer should depend on whether the plugin determines whether to suppress MBL or not: If suppressing MBL: Just send G28 X Y. No G80 or G28 Z, as those would either trigger MBL or throw away the MBL data. If MBL should be done: Pass it through verbatim: G28 W, G80. (For what it's worth, this is equivalent to both G28 X Y, G28 Z, G80 and a lone G28.)

At least as of the current default printer profile for MK3S in PrusaSlicer (v2.7.4):

M862.3 P "[printer_model]" ; printer model check
M862.1 P[nozzle_diameter] ; nozzle diameter check
M115 U3.13.1 ; tell printer latest fw version
G90 ; use absolute coordinates
M83 ; extruder relative mode
M104 S[first_layer_temperature] ; set extruder temp
M140 S[first_layer_bed_temperature] ; set bed temp
M190 S[first_layer_bed_temperature] ; wait for bed temp
M109 S[first_layer_temperature] ; wait for extruder temp
G28 W ; home all without mesh bed level
G80 ; mesh bed leveling
{if filament_settings_id[initial_tool]=~/.*Prusament PA11.*/}
G1 Z0.3 F720
G1 Y-3 F1000 ; go outside print area
G92 E0
G1 X60 E9 F1000 ; intro line
G1 X100 E9 F1000 ; intro line
{else}
G1 Z0.2 F720
G1 Y-3 F1000 ; go outside print area
G92 E0
G1 X60 E9 F1000 ; intro line
G1 X100 E12.5 F1000 ; intro line
{endif}
G92 E0
M221 S95

Additionally, maybe it should also trigger on a lone G28 and a G28 with Z as one of its arguments (G28 .*Z.*).

For just G28, I think that the supposition is that this is how other slicers, treating it as a generic printer, would generate the starting GCODE. I read somewhere that this is why they originally tacked the mesh bed levelling onto an existing instruction, to make it work with slicers who weren't aware of the MBL functionality. PrusaSlicer just makes it explicit by splitting it into two instructions.

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 G28-implies-G80 logic, and has the result of forcing the user to do a manual G80 after running. So it could be filtered, if you want to cover all bases.

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 pip install in the command line or similar?

EDIT for the sake of clarification: The part where I mentioned G28 X Y, G28 Z, G80 in my original comment was to propose a change that the user could make in their slicer. That is, to split the current G28 W, G80 commands into a format that could be more easily filtered by the current version of SmartABL. But if it is possible to make changes to the plugin to accommodate this weirdness, replacing the G28 W, G80 with the appropriate instructions directly within the plugin, I think that would be preferable.

EDIT 2: In a previous version of this comment I misremembered some of my previous findings about G28 Z, and what I wrote implied that this command also triggers a G80 automatically. It doesn't. It just disables the MBL status, forcing the user to do G80 manually if they want to re-enable it. (The alternative being printing without MBL, likely with poor results.)

scmanjarrez commented 4 months ago

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%)

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).

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. P.S2: Do you have discord (this is mine)? Or telegram (this is mine)? It'd be very helpful to discuss this in a more real time and also test it that writing here.

jmickelin commented 3 months ago

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:

1) User has to tweak their profiles in the slicer to remove the code that turns off the motors from the ending G-code. Then they might as well manually disable the MBL from the start G-code. 2) SmartABL, when enabled, filters out both the G-code for Z-homing and MBL at the beginning of the print, and the G-code for disabling the motors. 3) Going the hard route of using that undocumented PRUSA MBL G-code after a Z-home. I am still unsure how the translation between "logical" and "physical" coordinates is done in practice, and even moreso if we need to take into account possible Z-drift+rehoming due to the motors turning off in between.

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 :)