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