jschuh / klipper-macros

A collection of useful macros for the Klipper 3D printer firmware
GNU General Public License v3.0
921 stars 167 forks source link

[BUG] Random position printing is printing always at the original position #129

Closed lettore closed 1 year ago

lettore commented 1 year ago

When the print is starting it seems that the random position logic works as it says Relocating print origin from (98.944,85.944) to (19.000,53.000) and the mesh bed probe is working in that area, but when it prints it prints exactly as no Gcode offset is applied. This is the print log

14:12:18
Active bed surface: smooth_pei; offset: 0.000
14:12:02
Bed Mesh state has been saved to profile [default]
for the current session. The SAVE_CONFIG command will
update the printer config file and restart the printer.
14:12:02
Mesh Bed Leveling Complete
14:12:02
probe at 83.100,151.100 is z=2.232500
14:12:00
probe at 64.550,151.100 is z=2.217500
14:11:58
probe at 46.000,151.100 is z=2.245000
14:11:56
probe at 46.000,119.550 is z=2.272500
14:11:55
probe at 64.550,119.550 is z=2.237500
14:11:53
probe at 83.100,119.550 is z=2.260000
14:11:51
probe at 83.100,88.000 is z=2.247500
14:11:50
probe at 64.550,88.000 is z=2.250000
14:11:48
probe at 46.000,88.000 is z=2.267500
14:11:43
8 | (83.1, 151.1) | (51.1, 111.1)
14:11:43
7 | (64.5, 151.1) | (32.5, 111.1)
14:11:43
6 | (46.0, 151.1) | (14.0, 111.1)
14:11:43
5 | (46.0, 119.5) | (14.0, 79.5)
14:11:43
4 | (64.5, 119.5) | (32.5, 79.5)
14:11:43
3 | (83.1, 119.5) | (51.1, 79.5)
14:11:43
2 | (83.1, 88.0) | (51.1, 48.0)
14:11:43
1 | (64.5, 88.0) | (32.5, 48.0)
14:11:43
0 | (46.0, 88.0) | (14.0, 48.0)
14:11:43
bed_mesh: generated points
Index | Tool Adjusted | Probe
14:11:43
Generating new points...
14:11:28
echo: g28.6245197
14:11:28
Relocating print origin from (98.944,85.944) to (19.000,53.000)
14:11:28
listvars SEARCH=exclude
14:08:49
echo: g28.6245197
14:08:49
File selected
lettore commented 1 year ago

It seems to me that this happens when you have objects without the polygon section. Correctly preprocessed files with moonraker enable_object_processing: True does not have this bug.

jschuh commented 1 year ago

Closing since this is just #128, and the actual problem is the bad object entry.

lettore commented 1 year ago

Not sure if it should be closed, I made 3 prints and all are printing on the right-center side of the platform, nearly on the same spot but logs says that position should be different. Relocating print origin from (98.944,85.944) to (19.000,53.000) Relocating print origin from (98.944,85.944) to (166.000,132.000) Relocating print origin from (98.944,85.944) to (132.000,71.000) I'm trying to diagnose what's happening but it's quite difficult to understand what's going on in the code, it should be really simple as it's just a GCODE OFFSET

jschuh commented 1 year ago

The randomization offsets are calculated right before the offset mesh is run in _PRINT_START_PHASE_PROBING. The gcode offset doesn't get applied until _KM_APPLY_PRINT_OFFSET runs at the end of _PRINT_START_PHASE_EXTRUDER, to reduce the odds of conflict with anything else that may be override offsets (e.g. probe docking). _KM_APPLY_PRINT_OFFSET wraps SET_GCODE_OFFSET because it has to account for other things that may have manipulated the offsets, and then reset to the proper state at the end of the print. So, the complexity is to account for the many potential variations in configs.

At this point I have the randomized print offset on most of my printers, and it works without any issue. However, it is possible you have something in your setup that's conflicting with the offsets. I can't really say, since I don't know your config or slicer settings. And since you seem to have forked the macros, it's also possible that your changes introduced an incompatibility (which is why one of the first steps in the troubleshooting guide calls out testing against the most current, stock macros).

lettore commented 1 year ago

I didn't made any changes to the macro, I printed dozens of items today without issues, but all are single objects. Yesterday randomizer was not working properly on print with multiple objects. Anyway you will agree that randomizer was proposed by me and I was using it for a year at least and I had zero problems in hundreds of prints. And of course I already found some bugs in the code so it's not impossible that something else is wrong here. What I'm saying is that the whole thing is getting really over complicated without any reason. It's a Gcode offset for this and another for bed plate. I'm not a coder, it's just my opinion but simple is better.

hardmax commented 1 year ago

Hi, In my prints always say the same place:

Relocating print origin from (115.900,106.550) to (115.900,106.550)

I use PrusaSlicer 2.6 beta with Label Objets, I config moonraker to support cancel objets and Put 👍 variable_start_random_placement_max : 20.0

in print.cfg but I dont know why Dont change origin.

Can you help about this?

Regards

pa0los commented 6 months ago

I also have issue with this randomizer, same as @lettore It properly chooses new origin, probing is done at shifted coordinates, but prints are always in the center. Have you found the root cause? I have also noticed that the last probing (right after mesh probe) is done at the center of the bed. Not sure if it was there before the randomizer stopped working...