Nested variable in tool change section causes error popup even though gcode generation works correctly

[Nuffe71]

Version

2.1.1+win64-201912101512

Operating system type + version

Microsoft Windows 10 Home 10.0.18363

3D printer brand / version + firmware version (if known)

Duet2 Wifi 2.05 (2019-12-13b1)

Behavior

Tool change G-code: The line M104 S[temperature_[next_extruder]] (even if commented out) causes "PrusaSlicer has encountered an error" popup to appear, saying that gcode.tmp file should be inspected and it should contain !!!! Failed to process the custom-Gcode template.

When the file is inspected, it does not contain any error sections, and also above tool change code has worked correctly. The gcode.tmp file is complete, containing all lines including the comment section listing parameters. The variables have parsed correctly: M104 S217 T1

The nested variable part caused the problem. If it is removed, problem disappears.

This is not a new feature request

Project File (.3MF) where problem occurs

error.zip

[bubnikv]

please try S{temperature[next_extruder]}

[Nuffe71]

It is not a conditional expression.18.2.2020 11.30 Vojtěch Bubník notifications@github.com kirjoitti:please try S{temperature[next_extruder]}

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[lukasmatena]

@Nuffe71 The curly brackets are not used only for conditional expressions. Just do what @bubnikv suggested.

I agree, though, that using the [temperature_[next_extruder]] syntax in this case produces very misleading error message. The temporary gcode indeed looks correct and does not contain the "!!!!!!! Failed to process... " block that the user is advised to look for.

[Nuffe71]

ok, thank you. I can use that. I also see no underscore there, so not nested variable any more, but some temperature-function I am calling there? With accidental underscore I was able to have real failed process text to tmp file.

In any case I wanted to report a bug, not a support ticket. In addition to @lukasmatena comment about failure in error reporting... the point is that there is no need for the error page at all. Clearly gcode generation can handle that, gcode was generated correctly. The UI is the part which fails (and tmp file is not finalized). Please see https://github.com/slic3r/Slic3r/wiki/FAQ#what-placeholders-can-i-use-in-custom-g-code - these should work in Slic3r so why not also in PrusaSlicer?

[bubnikv]

Please see https://github.com/slic3r/Slic3r/wiki/FAQ#what-placeholders-can-i-use-in-custom-g-code - these should work in Slic3r so why not also in PrusaSlicer?

It is a completely different code, and PrusaSlicer suppots different placeholder parser syntax (I hope a better one) than the upstream slic3r.

[bubnikv]

This issue is very unusual.

First the tool_change_gode failed not because of syntax error, but because the index variable got negative. Second, one did not get the error written into the G-code, because the result of the tool_change_gcode substititon got thrown away.

It all happens inside WipeTowerIntegration::append_tcr(), which first processes the G-code templates, and then it does one more round of substitution over the pre-generated wipe tower G-code, where some internal placeholders are replaced with pre-processed custom G-code blocks. In this step, the failing G-code template is not being inserted into the final G-code, thus one does not get further information about what and why it failed.

This is really a very special case and it requires more digging than it seems. The issue has nothing to do with the placeholder parser per se, but with how the results of the placeholder parser are processed.

[bubnikv]

Tested with PrusaSlicer 2.4.0-beta1. I get the following error:

Which to me is quite understandable. It explains, that next_extruder is negative. Indeed, this tool change G-code is called after the last filament was pulled out of the extruder, thus there is no active filament and the next_extruder identifier is set to -1.

Is it clear now? Do you object having the active extruder set to -1 after the filament was pulled out of the extruder at the end of the print?

[bubnikv]

By the way, you may use the

{if  next_extruder >= 0}
do your thing
{endif}

block to work around the extruder ID set to -1.