Arksine / moonraker

Web API Server for Klipper
https://moonraker.readthedocs.io
GNU General Public License v3.0
1.08k stars 414 forks source link

Exclude object not working #561

Closed simpat1zq closed 1 year ago

simpat1zq commented 1 year ago

What happened

I suspect there might be something wrong with the preprocessing of the file. I updated moonraker and Klipper to the latest versions and still have the issue. This is running on Ubuntu 22.04 LTS. All the latest patches are applied.

Anyways, on my other printers, all running on Pi's, this works just fine. It's not a gcode issue because I uploaded the same gcode file to my other printers, and it processes it just fine. I've attached the log file.

Here's the relevant section from that log file:


2022-11-30 17:05:09,025 [data_store.py:_init_sensors()] - Configuring available sensors: ['heater_bed', 'extruder'] 2022-11-30 17:05:25,211 [shell_command.py:run_with_response()] - /home/voron/moonraker-env/bin/python: Object Processing is enabled INFO:prepropress_cancellation:Shapely not found, complex hulls disabled Performing Object Processing on file: CatanResourceCardTrayPinV2.gcode, sliced by SuperSlicer

2022-11-30 17:05:25,211 [shell_command.py:_check_proc_success()] - Command (/home/voron/moonraker-env/bin/python /home/voron/moonraker/moonraker/components/file_manager/metadata.py -p /home/voron/printer_data/gcodes -f "CatanResourceCardTrayPinV2.gcode" --check-objects) successfully finished 2022-11-30 17:05:25,219 [app.py:log_request()] - 201 POST /api/files/local (192.168.45.186) [_TRUSTEDUSER] 1712.98ms


And here's the same thing from the printers that are working:


INFO:prepropress_cancellation:Shapely not found, complex hulls disabled Performing Object Processing on file: CatanResourceCardTrayPinV2.gcode INFO:prepropress_cancellation:GCode already supports cancellation

2022-11-30 12:07:28,231 [shell_command.py:_check_proc_success()] - Command (/home/pi/moonraker-env/bin/python /home/pi/moonraker/moonraker/components/file_manager/metadata.py -p /home/pi/gcode_files/gcode -f "Test/CatanResourceCardTrayPinV2.gcode" --check-objects) successfully finished 2022-11-30 12:07:28,246 [app.py:log_request()] - 201 POST /server/files/upload (192.168.45.186) [_TRUSTEDUSER] 769.56ms


As you can see, in the working printer, it sees that the cancellation info is already there, but in the non-working system, it doesn't say the same thing.

Is there anything that I need to change to get this working? Fluidd, moonraker, klipper are all at the latest version. I've tried reinstalling moonraker, both manually and using kiauh, and I get the same problem. I've also tried installing shapely into the virtualenv, and that didn't help either.

moonraker(5).log

Client

Fluidd

Browser

Firefox

How to reproduce

Upload a file, and start a print. The cancellation options aren't there.

Additional information

No response

Arksine commented 1 year ago

Thanks. This is a regression introduced when object processing support was added for PrusaSlicer forks. It should be fixed in commit 1cb46a8f8fcb0a7970ba93cc73cbaa23fd724c24.

simpat1zq commented 1 year ago

I just updated to that commit, and it still doesn't have the cancel functionality. And the logs still show the same thing.

Arksine commented 1 year ago

Can you provide the new log on that commit? Thanks.

Edit: It also might be helpful if you can upload a sliced gcode file with the log.

simpat1zq commented 1 year ago

I updated to the commit after that one as well. I attached the log file. Here's the snippet that shows the upload from SS:

2022-12-01 01:44:56,074 [shell_command.py:run_with_response()] - /home/voron/moonraker-env/bin/python: Object Processing is enabled INFO:prepropress_cancellation:Shapely not found, complex hulls disabled Performing Object Processing on file: TTRTray4.gcode, sliced by SuperSlicer

2022-12-01 01:44:56,074 [shell_command.py:_check_proc_success()] - Command (/home/voron/moonraker-env/bin/python /home/voron/moonraker/moonraker/components/file_manager/metadata.py -p /home/voron/printer_data/gcodes -f "TTRTray4.gcode" --check-objects) successfully finished 2022-12-01 01:44:56,082 [app.py:log_request()] - 201 POST /api/files/local (192.168.45.186) [_TRUSTEDUSER] 5979.35ms 2022-12-01 01:44:56,083 [websockets.py:build_error()] - JSON-RPC Request Error: -32601 Metadata not available for <.thumbs/TTRTray4-64x64.png> Traceback (most recent call last): File "/home/voron/moonraker/moonraker/websockets.py", line 253, in execute_method result = await callback(params) File "/home/voron/moonraker/moonraker/websockets.py", line 362, in func result = await callback( File "/home/voron/moonraker/moonraker/components/file_manager/file_manager.py", line 353, in _handle_metadata_request raise self.server.error( utils.ServerError: Metadata not available for <.thumbs/TTRTray4-64x64.png> 2022-12-01 01:44:56,083 [websockets.py:build_error()] - JSON-RPC Request Error: -32601 Metadata not available for <.thumbs/TTRTray4-400x300.png> Traceback (most recent call last): File "/home/voron/moonraker/moonraker/websockets.py", line 253, in execute_method result = await callback(params) File "/home/voron/moonraker/moonraker/websockets.py", line 362, in func result = await callback( File "/home/voron/moonraker/moonraker/components/file_manager/file_manager.py", line 353, in _handle_metadata_request raise self.server.error( utils.ServerError: Metadata not available for <.thumbs/TTRTray4-400x300.png> 2022-12-01 01:44:56,084 [websockets.py:build_error()] - JSON-RPC Request Error: -32601 Metadata not available for <.thumbs/TTRTray4-32x32.png> Traceback (most recent call last): File "/home/voron/moonraker/moonraker/websockets.py", line 253, in execute_method result = await callback(params) File "/home/voron/moonraker/moonraker/websockets.py", line 362, in func result = await callback( File "/home/voron/moonraker/moonraker/components/file_manager/file_manager.py", line 353, in _handle_metadata_request raise self.server.error( utils.ServerError: Metadata not available for <.thumbs/TTRTray4-32x32.png>

moonraker(7).log

simpat1zq commented 1 year ago

Here's the gcode as well. FYI, it's a gcode file, and not a txt file in case that matters. I think my phone added the .txt when I downloaded it just now from Fluidd.

TTRTray4.gcode.txt

Arksine commented 1 year ago

Thanks. When I upload that file the metadata processor reports the following:

Dec 01 10:48:50 pi-debugger python[841432]: [shell_command.py:run_with_response()] - /home/pi/moonraker-env/bin/python: Object Processing is enabled
Dec 01 10:48:50 pi-debugger python[841432]: File 'TTRTray4.gcode' currently supports cancellation, processing aborted
Dec 01 10:48:50 pi-debugger python[841432]: [shell_command.py:_check_proc_success()] - Command (/home/pi/moonraker-env/bin/python /home/pi/moonraker/moonraker/components/file_manager/metadata.py -p /home/pi/printer_data/gcodes -f "TTRTray4.gcode" --check-objects) successfully finished

Are you sure that the gcode file is processed by the slicer?

simpat1zq commented 1 year ago

Yes. It's processed by the slicer. That's why your logs are saying that it already supports cancellation. It almost seems like my installation isn't seeing that the file supports cancellation for some reason. Do you think it might have to do with me running Ubuntu x86? Or maybe something with my python version?

Edit. Also, mine shows the message that shapely wasnt found. But yours doesn't. However, my working instances have the same message, but they don't have any issues.

Arksine commented 1 year ago

The gcode file you attached was downloaded through Fluidd, and according to your logs it was processed by Moonraker. If it had been processed by the slicer your logs should show that it already supports cancellation. Try uploading the file you attached through Fluidd and see if your instance of Moonraker aborts processing.

The shapely error is not shown in my log because Moonraker detected that the file was already processed did not import preprocess_cancellation. Previously Moonraker failed to detect this condition due to a change in the gcode commands from the alpha version, however the preprocess-cancellation module itself detected it.

simpat1zq commented 1 year ago

Oh ok. I had assumed the slicer was putting that in there. I uploaded that same file, and I do indeed get the message saying that it's already processed and I don't get the shapely message. However, it still doesn't let me cancel objects.

Arksine commented 1 year ago

SuperSlicer can be configured to perform the postprocess, I presume it is for your other printers. With regard to the objects not being there, that is likely not an issue with Moonraker. As far as I can tell the post process is performed successfully. However I when looking at the gcode I can tell that the objects are defined after print_start, so they wont show up as cancellable until that macro has completed at the earliest.

EricZimmerman commented 1 year ago

on the voron discord, someone mentioned putting in a throw away gcode command at the top of the print start section in the slicer, BEFORE print_start.

since the commands get inserted after the first gcode, the object stuff gets inserted between the throwaway code and print_start

worth a try

Arksine commented 1 year ago

Yes, that should work. The preprocess-cancellation library intentionally inserts the object definitions after the first uncommented line. I believe it does this so the file size calculation isn't thrown off.

simpat1zq commented 1 year ago

Looks like it's mystery solved then. I can indeed cancel after the macro completes. I am able to cancel immediately on my printers running a slightly older version of moonraker. That said, I think there must have been some change between moonraker versions v0.7.1-747-g779997c -> v0.7.1-775 that did that.

One of my other printers were at that older version, and I was able to cancel immediately after starting the print. I updated it to the latest version, and when I sent the same print, using the exact same slicer settings, I now have to wait until the macro completes.

Looks like I'll be throwing an M117 command into my slicer now. Thanks for the help with this Arksine.

Arksine commented 1 year ago

There was a change, however it shouldn't have affected the actual processing as that is handed off to the preprocess-cancellation library. I'll look into it to see if I can reproduce it though.

simpat1zq commented 1 year ago

And just for the sake of documenting, I can confirm that adding an M117 command at the top of the start gcode in my slicer allows me to cancel instantly after starting the print.

Arksine commented 1 year ago

Thanks. If you still have an installation that has yet to be updated do you think you could upload a gcode file that allows immediate cancellation without the M117 addition? It would be helpful to see what is different.

After an in depth look I can't see how Moonraker would have changed it.

simpat1zq commented 1 year ago

Yes, I do have 3 other printers that are at an older version of Moonraker. However, I don't have SS setup to upload directly to them. It actually uploads to just one of them(the one that is updated to latest), and then SyncThings to sync the files to the other 3 printers, which are at the older version.

So what I will do, is save the gcode from SuperSlicer, and upload that same gcode, through Fluidd, to the updated printer, and also to the older version printers. Then I will download both of those gcodes, and post them here along with the SS gcode.

And looking at the gcode, I'm even more confused. They both add the code right after the M73 command that superslicer inserts. I'm wondering if I may have enabled that in SS at some point, which may have fixed this instead of it being a version of moonraker.

Gcodes.zip

weekendclimber commented 1 year ago

The M117 command addition before the PRINT_START macro in Cura 5.2.1 fixed this issue for me as well. Using fully updated Klipper, Moonraker, etc.:

klipper v0.11.0-41-g9b60daf6 KlipperScreen v0.3.1-9-gb96adf5 crowsnest v3.0.6-15-g5e95c0d led_effect v0.0.9-0-g5d16b1c moonraker v0.7.1-780-gdde9bcc sonar v0.0.2-25-g0ce6c6f mainsail v2.4.1 System OS-Packages

Arksine commented 1 year ago

I'm going to close this as resolved. The requirement to insert a gcode command before the start macro could likely be resolved by a modification to preprocess-cancellation library. Currently it looks for the first command and inserts the object definitions after it finds one. It should be possible to insert the definitions before that command.