[Bug] Markers off target

[KenLucke]

Running OP 1.6.0rc2/Cancel Objects 0.4.4

The markers for the objects are WAY off target for the actual location of the objects on the bed. When you have a lot of objects on the bed at one time, this can be very confusing as to which one you are actually canceling.

There are 5 models in this print (see image of model in Cura), the one large double ball (which also consists of the 5 little parts of a hinge in the center as well), and 4 little clips. The markers actually do show spatial relationships properly, but they are shifted way off to the right of the actual physical location. I also notice that, instead of being round, as they previously were, they are now oval.

System Info browser.user_agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:87.0) Gecko/20100101 Firefox/87.0 connectivity.connection_check: 1.1.1.1:53 connectivity.connection_ok: true connectivity.enabled: true connectivity.online: true connectivity.resolution_check: octoprint.org connectivity.resolution_ok: true env.hardware.cores: 4 env.hardware.freq: 1500 env.hardware.ram: 8138444800 env.os.bits: 64 env.os.id: linux env.os.platform: linux env.plugins.pi_support.model: Raspberry Pi 4 Model B Rev 1.4 env.plugins.pi_support.octopi_version: 0.18.0 env.plugins.pi_support.throttle_state: 0x0 env.python.pip: 21.0.1 env.python.version: 3.7.3 env.python.virtualenv: true octoprint.safe_mode: false octoprint.version: 1.6.0rc2 printer.firmware: Marlin 2.0.7.9_NIC (Mar 5 2021 17:53:11) systeminfo.generator: systemapi

Plugins installed: Access Anywhere - The Spaghetti Detective [disabled] Action Commands Action Trigger Active Filters Extended Arc-Welder Backup Scheduler Bed Visualizer BLTouch Plugin Cancel Objects Dashboard DisplayLayerProgress Plugin Dragon Order Exclude Region FileManager Firmware Updater Floating Navbar GcodeEditor InlineConfirm Macro Marlin EEPROM Editor MeatPack Multi Colors Multi Line Terminal OctoPod Plugin Octoprint-Display-ETA Preheat Button PrettyGCode [disabled] PrintTimeGenius Plugin Progress Title Restore Leveling After G28 Simple Emergency Stop Stateful Sidebar TemperatureLegendMover Terminal Commands Extended Themeify TimeToFilament Plugin Top Temp Translate Model Plugin UI Customizer WebDAV Backup [disabled] Z Probe Offset

[paukstelis]

Thanks for the notification. I will take a look.

[KenLucke]

Is there any way to get the markers to show up before the print actually starts (such as scanning the file prior to print as some other plugins do)? I often create gcode files with multiple copies of an object, then if one fails or gets canceled, I either have to reslice with the fewer models, or start the print and wait for the first layer to finish and cancel the ones I don't want. It would be nice if, once loaded, I could cancel unwanted ones before even starting.

[paukstelis]

I cannot reproduce directly. Everything looks normal to me with 1.6.0rc2 and 0.4.4.

It would be possible to determine object positions by pre-processing the gcode. I'm not a huge fan of that, but I can consider making that be something that is optional, but not automatic. SuperSlicer does provide object locations at slice time which I consider to be the better way to operate (maybe bug Cura devs?).

[KenLucke]

I cannot reproduce directly. Everything looks normal to me with 1.6.0rc2 and 0.4.4

Odd. I wonder if it has to do with UI Customizer. That's the only other change I've made.

[KenLucke]

It would be possible to determine object positions by pre-processing the gcode. I'm not a huge fan of that, but I can consider making that be something that is optional, but not automatic.

Optional would be perfectly fine with me :)

[paukstelis]

It would be possible to determine object positions by pre-processing the gcode. I'm not a huge fan of that, but I can consider making that be something that is optional, but not automatic.

Optional would be perfectly fine with me :)

Actually, now that I think about it, I am already pre-processing the gcode to find comments. It would make the whole process take just a bit longer, but I can probably track extrusions during that process to get positions. I'll see how straightforward that will be.

[KenLucke]

Restarting OP without UIC, and will try that same print (it came loose from the bed, and I had to restart it anyway)

[KenLucke]

Actually, now that I think about it, I am already pre-processing the gcode to find comments. It would make the whole process take just a bit longer, but I can probably track extrusions during that process to get positions. I'll see how straightforward that will be.

Cool.

[KenLucke]

It appears as if it is some sort of interaction with UI Customizer. Disabling it and restarting the same print yields a Layer 3 with placement much more accurate, at least so far, and the markers are round again:

[KenLucke]

It just occurred to me, looking at this current print with multiples of the above model (that was a test print before going into mass production mode :) --- the markers being oval AND the positioning are the same ratio as the gcode viewer entire area, even though the viewer window itself doesn't fill that whole area. Almost like when a 4:3 video overlay is displayed in 16:9, but left justified over the original 4:3 video. (not that that's what's happening here, but just as an analogy). Something is stretching the marker overlay out to the whole window, and I suspect it's UI Customizer.

[KenLucke]

Just had to cancel one set above. The CLICK location is correct, the marker location is not.

[LazeMSS]

@KenLucke and you have not enabled the full size gcode part of UI customizer?

[KenLucke]

Yes, it is enabled. I will try it toggled off.

[LazeMSS]

Try disabling that - it will only resize the canvas the gcode viewer so anything stuck "onto" that might not follow the changes - I might be able to do something.

[KenLucke]

Disabling full size did cure the issue. I'm not sure what that feature does, as I don't see any change in the gcode viewer size.