Error in the Open Source code for Prusa Slicer  

RE: Error in the Open Source code for Prusa Slicer

The particular problem, with that sample:

G0 E-0.400000; RCG Filament Retract

is that Prusa Slicer does some checks on the created GCode file and incorrectly thinks that "Filament" is a Feedrate parameter (it only check the 'F', not the whole word, and shouldn't even by checking text in the comment!). It subsequently divides the Feedrate variable value by 60. But worse, since it can encounter similar comments on subsequent GCode commands it KEEPS DIVIDING BY 60 over and over again, until the Feedrate variable value hits zero and THAT causes an assert failure.

RE: Error in the Open Source code for Prusa Slicer

This is a user to user forum.  All bug reports need to be made at the Prusa Slicer github.  https://github.com/prusa3d/PrusaSlicer/issues   Please open a new issue there.

RE: Error in the Open Source code for Prusa Slicer

Posted by: @neophyl

This is a user to user forum.  All bug reports need to be made at the Prusa Slicer github.  https://github.com/prusa3d/PrusaSlicer/issues   Please open a new issue there

I have. But prior postings about other issues there never got responses. It's like no one at Prusa checks anything posted to their Prusa Slicer github page. I'm trying everywhere possible to get through to someone who can do something about it.

RE:

They look at the GitHub issues but most of processing is done in the team without notifying the users, I believe they should fix that. Also I would wait for few days prior posting on the forum, not everyone watches GitHub 24/7 🙂

For now I suggest changing filament to something else or prefixing it with some underscore or hash sign, because I don't believe this will get fixed anywhere soon, unfortunately.

I'd recommend to set more explicit title of the issue in the GitHub, now it sounds very vague.. maybe something like 'incorrect parsing gcode comments leads to errors in feedrate'

Btw, great finding 🙂

RE: Error in the Open Source code for Prusa Slicer

Thank you for the feedback. It does appear that you actually read the .pdf, so I appreciate that. I do have a workaround, which is basically putting the comments on a preceding line by itself, rather than at the end of the GCode command. But, man, it took me several days to finally isolate it down to that small section of code. 

I've known engineers who just love debugging other people's code, saying that it's like successfully getting down into the other person's brain. Me? Not so much. I find it very frustrating, especially when there's no documentation and practically no comments throughout the code. And when there's multiple methods each with variations of the same method, extrude(), _extrude(), extrude_(), Extrude(), it makes it particularly difficult to follow along with the logic.

RE:

At least you have a source code 🙂

And no, I have not seen pdf but I've been doing other stuff with gcode and coding to know how to mitigate such issues.

I'm surprised that Prusa was not doing full regexp search to detect feed rate, and the just choose to process first letter, probably easier to code and also less computationally complex from firmware perspective.

RE: Error in the Open Source code for Prusa Slicer

@_kaszpir_ , Actually, if I didn't have the source code I wouldn't be encountering this issue with Prusa Slicer. The Prusa Slicer program itself never generates GCode that includes inline comments. It's only because I'm making additions to the source code for my weird, super-secret project that do indeed generate those kinds of GCodes (with comments at the end) basically to help me in the ongoing debugging of it, that the problem arose and I was able to track down the source of the problem.

RE: Error in the Open Source code for Prusa Slicer

Well, this is interesting. I just got a response from someone at Prusa, responding to my posting on the Prusa Slicer GitHub page.

Here's what they said:

Hello @RogerInHawaii, we appreciate your effort. To me it seems to me, that you blame CoolingBuffer::parse_layer_gcode for invalidly parsing gcode comments. Yet parse_layer_gcode never claimed to take valid gcode as input. It is an internal function of PrusaSlic3r, that depends on some specific input. Did you manage to reproduce the error in some of the precompiled slic3r versions? If so, be so kind and provide a 3mf, where we can reproduce it. If the invalid parsing is caused by your changes in the prusa slic3r code than it might be an issue in your understanding of the code base.

Side note: We at PrusaSlic3r also find the comments useful, that is why you can turn on Verbose GCode in Print Settings -> Output options. Make sure to have binary gcode (Printer Settings -> General) disabled if you use the Verbose GCode option

I highlighted the critical part of their response, that "parse_layer_gcode never claimed to take valid gcode as input".  And it also says that the particular function "depends on some specific input". Well, the specific input it takes is GCode. So, don't they think it ought to conform to the protocols (language definition) of GCode? Apparently not.

They then ask if I "manage[d] to reproduce the error in some of the precompiled slic3r versions". I think I was pretty darn clear in the document I wrote up and included in my GitHub posting that the problem ONLY arises from GCode that results from ADDITIONS I have made to the Prusa Slicer Open Source source code.

I'm imagining a set of rules for their own Prusa Slicer developers:

1) Never, ever put a comment at the end of a GCode command, even though that's valid GCode.

2) If you do feel the need to include comments in the generated GCode, put each one on a line by itself.

3) Don't worry about there being extraneous characters after a GCode parameter (or even before the basic GCodes themselves). The Slicer will ignore them, will not flag them as errors or warning or throw exceptions. It will screw it up when the user attempts to provide the resultant GCode file to a printer, but that's their problem.

Thus commands like the following are perfectly fine:

G01 XCoordinate1.38 YThing72.4

GreatGoogly01 Eggbert0.38

And those are valid because in Prusa Slicer we only check the first letter of anything and ignore the rest. 

MY POINT is that the Prusa Slicer is made available, because of Open Source legalities, to anyone, everywhere, to make modifications and additions to. Those people should quite reasonably expect that the Prusa Slicer source code DOES INDEED conform to the language definition of GCode files.
 

RE:

I don't know what do you want to achieve keeping discussion in the wrong place (this forum), the proper place to explain it is in that github issue you created. https://github.com/prusa3d/PrusaSlicer/issues/12393

> I think I was pretty darn clear in the document I wrote up and included in my GitHub posting that the problem ONLY arises from GCode that results from ADDITIONS I have made to the Prusa Slicer Open Source source code.
Well, if the issue arises because your additions to the code, then without example code that you did it turns that they try to debug what you wrote 😉

BTW there is a check to detect semicolons in here https://github.com/prusa3d/PrusaSlicer/blob/4f035bceb75661719b23d13fceddc62ccab6c54e/src/libslic3r/GCode/CoolingBuffer.cpp#L401 if the command is // G0, G1, G2, G3 or G92...

I believe better feedback related to the commit version you have and the code you added would help to debug it better.

Still, I encourage to move it to the GitHub and provide reproducible code samples.