Internal Server Error 3008 when slicing almost every time

[NuclearManD]

Describe the bug With both KISSlicer and Slic3r, I get Internal Server Error 3008 when I slice most things. The slicer clearly runs, reaches 80% on the progress bar, then the error comes up for "Internal Server Error 3008", and the sliced model is not available. It is as if the server error happens right after slicing is completed.

To Reproduce It is not entirely clear. I have uploaded a zip (since GitHub does not allow .stl uploads...) of the models I've tried so far - which is only two of them: models.zip

Notably, the light insert model did not slice with certain settings, but did slice with others. The other model I have in there used to slice with the settings I'm using, but doesn't anymore. I change a lot of slicer settings, but it is currently not clear to me what settings (if any) are causing the problem. I would give proper reproduction steps, but the best I can say is that I try to slice these models and they won't slice.

The models I'm printing are all made with OpenSCAD. I am using version 2021.01.

Expected behavior The slicer finishes without an internal server error, and I see the sliced model. Then I would download the gcode and print it.

Screenshots If applicable, add screenshots to help explain your problem.

Operating System (please complete the following information):

• OS: Linux mint. Output of uname -a: Linux nuclaer-machine 5.15.0-86-generic #96-Ubuntu SMP Wed Sep 20 08:23:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
• Browser: Brave
• Version: This is a problem with the website and online slicing - I don't know how to check the version, but it's whatever is currently in production, I would assume

Additional context None.

[NuclearManD]

With different settings on the nanogrid hub model, I get internal server error 3007. It would be nice if the error messages were a bit more descriptive. Further attempts have made the slicer not progress past 0% on the progress bar for KISSlicer.

I've been trying to find the offending setting, if any, but the light insert slices every time now with Slic3r. With the other model on Slic3r, just to confirm, I do get the Internal Server Error 3008. It does not seem to be isolated to either slicer.

[brandonbloch]

Hi @NuclearManD,

Thanks for reporting the issue! Unfortunately I'm unable to reproduce the error with just the models you provided, so it seems to be related to a particular combination of the models and the specific print settings you're using. Would you mind sharing the entire project (please check all enabled checkboxes) and either including the share link in this issue or via email to brandon@mosaicmfg.com so we can investigate further?

You can share a project via the button in the top-right of the page:

Cheers, Brandon

[NuclearManD]

Yea sure, here is a link: https://share.canvas3d.io/projects/1aeffa0a70f9e29e81dc44b891666654

[brandonbloch]

@NuclearManD thanks for sending that – from some investigation, it looks like the 3008 error is occurring during print preview generation due to the printer profile's start sequence heating the extruder using M109 R<TEMP>. This is a bug within Canvas that we'll look to resolve ASAP, but in the meantime as a workaround, changing line 53 of your printer profile's start sequence to include the S parameter either in addition to or instead of the R parameter avoids the issue:

M109 S<TEMP> R<TEMP> ; wait for extruder to reach printing temp
(or)
M109 S<TEMP> ; wait for extruder to reach printing temp

I'll update this thread once the issue is resolved in production and the workaround can be reverted.

Do you have an example project that results in the 3007 error? That error code relates to preparing model files in advance of actually slicing, and so would most likely stem from a different root cause. Unfortunately I haven't been able to reproduce it with the project you shared, but I'd like to keep digging and get all of these issues resolved for you.

Thanks, Brandon

[brandonbloch]

Hi @NuclearManD,

We've updated the slicing servers to properly handle temperature commands that use the R parameter but not the S parameter, so this should now be working correctly and you should be able to undo the start sequence workaround I posted above.

As for error messages, we now expose a number of additional user-facing errors when using Slic3r (i.e. errors that arise from incompatible combinations of settings) which should help reduce the number of opaque server errors by replacing them with specific messages explaining which settings need to be changed. I'm not sure which error you were running into specifically, but hopefully this change helps alleviate the issue.

If you're still running into any issues slicing, please feel free to reply on this thread or re-open the issue.

Cheers, Brandon