gcode viewer unhandled exception loading PS-generated gcode

[tg73]

Version

2.3.0-win64

Behavior

Drag attached gcode file onto PS, it launches gcode viewer, which then pops up a warning "Unhandled unknown exception; terminating the application.":

Click OK, then you get a PrusaSlicer Error pop up: "Internal error: Suspiciously low number of configuration values extracted from...":

The attached gcode was generated by PS 2.3.0 and has not been modified in any way. 3mf also attached.

• Expected Results

The gcode viewer should launch and show the gcode.

Files (1).zip

[rtyr]

The attached gcode was generated by PS 2.3.0 and has not been modified in any way.

That's not entirely true. The issue seems to be triggered by the comments added by displaylayerprogress Octoprint plugin.

; BEGIN DISPLAYLAYERPROGRESS SETTINGS
; DisplayLayerProgress_layerIndicatorProcessed = true
; END   DISPLAYLAYERPROGRESS SETTINGS

[tg73]

Ah - yes, unusually I'd downloaded that gcode from octo so I was certain it was what generated a particular print (a potential FW issue that's under investigation). I'd forgotten about that, and also I had no idea that octo plugins can modify stored files. Well spotted. But I assume that ideally those additional comments shouldn't choke the gcode viewer?

[bubnikv]

If we detect that the code was generated by Slic3r or PrusaSlicer, we are reading the configs from the end of the file. Thus your additional block confuses our poor slicer. We need to think a bit about a solution to your problem, we don't see a straightforward fix. We may ignore the config block, but then we may not show the print bed size correctly for example. út 20. 7. 2021 v 18:18 odesílatel Tom Glastonbury ***@***.***> napsal:

…

Ah - yes, unusually I'd downloaded that gcode from octo so I was certain it was what generated a particular print (a potential FW issue that's under investigation). I'd forgotten about that, and also I had no idea that octo plugins can modify stored files. Well spotted. But I assume that ideally those additional comments shouldn't choke the gcode viewer? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6730 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMPSI5SAM4QNMSRSKDQ6W3TYWOWJANCNFSM5AVU3IXA> .

[tg73]

How about PS emits specific start and end marker comments for its block of config comments? Then when reading, comments outside this block could be ignored. If the start and end markers are absent, then fallback to the current behaviour, thus giving backwards compatibility with "well-formed" gcode generated by earlier versions of PS/Slic3r. The start and end markers could be in standard config format so that they are simply ignored by older versions of PS. I tried surrounding the config block with:

; dummy_start_of_config = 0

and

; dummy_end_of_config = 0

and this is loaded fine by the current version of the gcode viewer - this is without the original offending comment block of course, but it demonstrates backwards compatibility for this approach.

[bubnikv]

Improved with e947a29

1) Starting with this commit, configuration block exported into G-code
   is delimited by "; prusaslicer_config = begin" and "; prusaslicer_config = end".
   These delimiters look like any other key / value configuration pairs
   on purpose to be compatible with older PrusaSlicer config parsing from G-code.
2) Config parser from G-code newly searches for "; generated by ..."
   comment over the complete G-code, thus it is compatible with various
   post processing scripts extending the G-code at the start.
3) Config parser from G-code parses PrusaSlicer version from
   the "; generated by PrusaSlicer ...." header and if the G-code was
   generated by PrusaSlicer 2.4.0-alpha0 and newer, it expects that
   the G-code already contains the "; prusaslicer_config = begin / end"
   tags and it relies on these tags to extract configuration.
4) A new simple and robust parser was written for reading project configuration
   from 3MF / AMF, while a heuristic parser to read config from G-code located
   at the end of the G-code file was used before.

If you have generated G-codes with PrusaSlicer 2.4.0-alpha0 before this commit, the delimiters are missing and you will get an error message. That's the risk of using pre-alphas.

[bubnikv]

Implemented with PrusaSlicer 2.4.0-alpha1.
Closing.