Closed lettore closed 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.
Closing since this is just #128, and the actual problem is the bad object entry.
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
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).
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.
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
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...
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