moggieuk / Happy-Hare

MMU software driver for Klipper (ERCF, Tradrack, Box Turtle, Night Owl, Angry Beaver, 3MS, ...)
GNU General Public License v3.0
503 stars 128 forks source link

Mainsail and Fluidd history #487

Open Spydyr opened 3 weeks ago

Spydyr commented 3 weeks ago

So I believe I found an issue with the history.

If you have [file_manager] enable_object_processing: False

And

[mmu_server] enable_file_preprocessor: True

Then print history works as normal. However larger gcode files may not have the thumbnail. That's not the issue. If both are set to True history records the gcode prints as not the here including the one the has is currently printing. With both set to True though thumbnails always work. This problem started with 2.7.2 as I back tracked to when it was working fine. I have cleared history and gcode files to see if it was "overloaded" and that didn't correct it.

ningpj commented 3 weeks ago

Missing thumbnails usually means the pre processor has failed to parse or has timed out parsing the gcode

Do you have

[file_manager] default_metadata_parser_timeout: 30

in moonraker.conf to increase the default timeout from 10sec? Issues parsing gcode files are also logged to the moonraker.log file and may provide additional insights

Spydyr commented 3 weeks ago

No I do not but that is a minor issue. The big issue is history not showing the files are missing even the one that is printing with both set to True. Could that timeout be part of it?

Spydyr commented 3 weeks ago

https://drive.google.com/file/d/1MtbN-Zlt5R4S6PCnAZKAnIK56_xqZsX5/view?usp=drivesdk

Here I the pic I took to show. The top one was printing when I took the photo.

ningpj commented 3 weeks ago

Highly likely as the preprocessor essentially rewrites the gcode file to expand HH tokens like !referenced_tools! !colors!, !temperatures!, etc. If it times out, it won’t replace the gcode file or expanding the tokens.

Recommend you quickly override the default moonraker timeout to 30sec and retest - upload a new, sizable gcode file you have been having issues with and confirm the thumbnail is visible (might take > 10sec depending on the size of the file and SD card performance). Export the parsed gcode and check the HH tokens have also been expanded and replaced with expected values.

ningpj commented 3 weeks ago

If you still have issues after setting this, please upload an extract from your moonraker.log and confirm your moonraker version. this is what you are looking for - Running MMU enhanced .... block

2024-10-30 18:15:46,855 [application.py:post()] - Processing Uploaded File: MM_Test_print_9_colors_ABS_0.4_1h12m.gcode
2024-10-30 18:15:47,191 [shell_command.py:pipe_data_received()] - INFO:metadata:mmu_server: Running MMU enhanced version of metadata

2024-10-30 18:15:47,198 [shell_command.py:pipe_data_received()] - INFO:metadata:Object Processing is enabled

2024-10-30 18:15:47,215 [shell_command.py:pipe_data_received()] - INFO:metadata:File 'MM_Test_print_9_colors_ABS_0.4_1h12m.gcode' currently supports cancellation, processing aborted

2024-10-30 18:15:47,302 [shell_command.py:pipe_data_received()] - INFO:metadata:mmu_server: Pre-processing file: /home/pi/printer_data/gcodes/MM_Test_print_9_colors_ABS_0.4_1h12m.gcode

2024-10-30 18:15:47,624 [shell_command.py:pipe_data_received()] - INFO:metadata:Reading placeholders took 0.32s. Detected gcode by slicer: OrcaSlicer

2024-10-30 18:15:47,868 [shell_command.py:pipe_data_received()] - INFO:metadata:mmu_server: Writing MMU placeholders,Inserting next position to tool changes took 0.24s

2024-10-30 18:15:47,921 [shell_command.py:_check_proc_success()] - Command (/home/pi/moonraker-env/bin/python /home/pi/moonraker/moonraker/components/mmu_server.py -m -n -p /home/pi/printer_data/gcodes -f "MM_Test_print_9_colors_ABS_0.4_1h12m.gcode" --check-objects) successfully finished
2024-10-30 18:15:47,927 [application.py:log_request()] - 201 POST /api/files/local (192.168.2.185) [_TRUSTED_USER_] 1193.44ms

Also a sliced and unprocessed gcode file that has this issue so we can verify what you are experiencing (slice and export directly to a file)

Spydyr commented 3 weeks ago

I will try it out after the current print finishes in about 8 hours.

Spydyr commented 3 weeks ago

moonraker (3).log

This is the latest log 4 attempts with the same file that shows the thumbnail regardless. History show the file does not exist when printing the file. And now it doesn't matter whether enable_object_processing is True or False.

ningpj commented 3 weeks ago

OK, it looks like you have spoolman integration enabled which maybe the issue here given recent updates to the preprocessor to support this. Can you upload the unprocessed B_1_Yellow_PLA_5h19m.gcode file (export from slicer) as well as the processed gcode from fluidd/mainsail?

Spydyr commented 3 weeks ago

https://drive.google.com/file/d/1U8eLYl4KQYVXj6BDns9_oJv5N6jtyqNc/view?usp=drive_link

Here is the link to it. It is like 25mb.

Spydyr commented 3 weeks ago

Now if I rescan metadata after the upload then history works as it should. Also I've only been running spoolman for 2 weeks and this issue by timeline started well before that.

ningpj commented 3 weeks ago

I rarely use history and had a look on my other printer (v0.2) which doesn't have HH installed and can see same issue with missing icons for some jobs although others are fine (all sliced with the same 2.1.1 version of orcaslicer). Maybe a moonraker issue or orca related and a problem with the small embedded icon. Unsure what the cause is at this stage.

Your gcode file parsed fine on my HH system with tokens correctly expanded and icon visible in the jobs queue. However after submitting and cancelling the job its icon isnt visible in the History queue. Snap from my v0.2 showing the same issue in fluidd:

image
Spydyr commented 3 weeks ago

I use the history for seeing my most popular prints and for tweaking slicers so the times are close. And keep track of actual Total Print Time. I tried in Fluidd too and like you I got the same thing. I'm just not sure if it is a moonraker issue or a HH. I have thought about downgrading back to 2.7.1 because it was working with it.

ningpj commented 3 weeks ago

As mentioned i see this issue on my v0.2 which doesnt have HH installed so definitely not caused by HH

Spydyr commented 3 weeks ago

My Sapphire doesn't have the issue and it doesn't have hh this is why I'm confused. But I do think it's more moonraker metadata issue than anything. There is something different and I just can't find it

moggieuk commented 3 weeks ago

I'm not sure I understand the problem completely but I do know that if the moonraker pre-processor times out then lots of problems can ensue.. no icon, TTC when KlipperScreen is running on same rpi (because of the MASSIVE amount of error logging klipperscreen will emit), etc. So make sure that:

[file_manager]
default_metadata_parser_timeout: 30

Where the timeout is plenty big enough to cope with the pre-processing time. Also check moonraker logs to see if there are pre-processing failures..

Spydyr commented 3 weeks ago

I added the timeout and it is at 600. There are no errors that we have been able to find. In the history it shows files that have printed as being no longer there when they haven't been moved or deleted. It also shows the current file printing as not being there as well. This doesn't matter if it is uploaded through the slicer or uploaded through mainsail/fluidd. I have confirmed it is both. HOWEVER, if you right click and select scan metadata after upload it loads into history just fine. My Voron has this issue where my Sapphire does not. The only difference is HH. Now @ningpj has it on both one with HH and one without. Which is the confusing part. I can't rule out HH but it seems to be a combination of things. Trying to narrow it down. HH, Moonraker, OrcaSlicer.

moggieuk commented 2 weeks ago

When HH will do a metadata scan whenever the file is created or changed. It piggybacks on the very same metadata scan that moonraker would have ran anyway. However if parsing does result in modification of the file then it would appear as "new" (not in print history). Not sure what might be happening without research but I can't do that ATM because I'm deep into Happy Hare v3.0. I'll keep this issue open to track. In the mean time if you or @ningpj have any more insights I'm all ears...

One thing that you can pay close attention to is the datestamp on the gcode files. Are they changing after a print?

Spydyr commented 2 weeks ago

I just checked and no dates are not changing after printing. Also my Sapphire does not have spoolman installed on it. I just finished a print with it. I will test installing spoolman and loading a print. I will also be install long HH on it as I have to remove my ERCF from my Voron because I will be printing PPS-CF for the next week and can run it through there. That will give another test point. If it is strictly related to my Voron I will wipe it completely out and start over.

I will keep you informed of my findings over the next week.