Cura: G-code comments stripped from Start and End Code

[cinderblock]

Cura does not save G-code comment lines when restarted.

Steps to reproduce

1. Open: Preferences, Printers. Select a printer profile, click Machine Settings
2. Add a line like: ; This is a test
3. Close Machine Settings and Cura Preferences
4. Optional Open Machine Settings and see that the comment line is still there
5. Close Cura completely
6. Relaunch Cura
7. Open Machine Settings again

Expected Results

Comment line ; This is a test is still in Start or End G-code

Actual Results

Comment line has been entirely removed from Start/End G-code.

Other Observations

Comments that come after regular G-code commands on the same line are preserved.

[Ghostkeeper]

Not only comments. It seems to not save it properly.
Reproduced with Cura 2.3.0.

We (or rather @fieldOfView, a contributor who almost sorta still belongs to "we") did change a few things around with this for Cura 2.4, to standardise how these settings are saved. I suspect it'll be fixed for 2.4 but we'll have to test that.

[fieldOfView]

Lines starting with a semicolon are stripped out by the ini file writer, because they would be considered a comment in the ini file instead of a part of the multiline string.

This is somewhat tricky to solve, because if we would somehow escape the leading semi-colon, we would also need to unescape it when reading the ini file. This has not been changed in my recent work.

[cinderblock]

Why is the ini file writer being used to write gcode files? Sounds like we should copy the ini file writer and update it to be a gcode file writer.

[cinderblock]

Using a space in front of the ; seems to work as a stop-gap solution.

The space seems to be removed before saving the machine profile but on subsequent loads, the comment lines are still there. It might go away on subsequent updates but I have not seen this happen yet.

[Ghostkeeper]

Because the start and end g-code are settings (though they are excluded from the normal view in the Advanced tab). These settings are stored in profiles. And the format we use for profiles is ini, so that it is easy to modify with a text editor.

[cinderblock]

Making it easily editable with any text editor is a laudable goal.

However now we're using the ini "standard" (if you can call it that) to store things it was never meant to store. In particular, storing multi-line data is not well defined.

I see that in the saved machine settings ini file, cura uses an interesting trick to allow multi-line values: a tab \t character at the start of a line means continue the previous value. This is documented in the python docs for configparser

Moving forward, if people really want to keep the ini format, I don't see why the encoder could not be fixed to not strip G-code comments.

According to wikipedia, ; only start comments in ini files when it's the first character on the line. This explains why other G-code comments are not stripped.

So, it looks like the code that puts G-code into the ini file format should not strip the comments at the start of any lines in values. Then, when it stores the multi-line value to the ini file, the G-code comment lines would be prefixed with a tab and everyone should be happy.

I'm not super familiar with Python so I'm not sure where to look in the code for this issue. One thing that might be being used is Python's RawConfigParser.write().

[Ghostkeeper]

Good research :wink:
We have an issue in our tracker to get to the bottom of this. I don't expect it'll get solved before the release of 2.4 though.

[fieldOfView]

I had a quick look at the issue. It turns out that Cura/python writes the comment-only lines just fine (they are prefixed with a tab), but they are being ignored when the ini file is read back in. I'll see what can be done about the latter.

[fieldOfView]

Looks like it can (only?) be fixed by disabling all comments in the ini parse, like so (note that this is in Uranium):
```
--- a/UM/Settings/InstanceContainer.py
+++ b/UM/Settings/InstanceContainer.py
@@ -325,7 +325,7 @@ class InstanceContainer(ContainerInterface.ContainerInterface, PluginObject):
#
# Reimplemented from ContainerInterface
def deserialize(self, serialized):
- parser = configparser.ConfigParser(interpolation = None)
+ parser = configparser.ConfigParser(interpolation = None, comment_prefixes = None)
parser.read_string(serialized)

     has_general = "general" in parser

````
With this change, comment lines are read as expected (they were already being written as expected). However, this also makes it illegal to put any comments in the ini file. I'm not sure if that is a bit too draconian of a measure. We could still allow # as a comment prefix (which is allowed by default, TIL), but noone will know about that and it could turn into a similar problem if someone wants to store a string that contains a # as the first character of a line

[cinderblock]

@fieldOfView Good catch. I can confirm the ini files are saved correctly. I agree that it looks like the configparser.ConfigParser reader is stripping inline comments.

I noticed this little bit from the docs. Could this be causing this under-defined behavior?

comment_prefixes, default value: ('#', ';')
inline_comment_prefixes, default value: None

Changed in version 3.2: In previous versions of configparser behaviour matched comment_prefixes=('#',';') and inline_comment_prefixes=(';',).

Maybe inline_comment_prefixes = None would do the trick?

[fieldOfView]

@cinderblock: No, that does not fix the issue because inline_comment_prefixes deals with comments halfway through a line (which are already correctly handled), and it already defaults to None

[filipgoc]

As Ghostkeeper referenced above, I have tested that this is still an issue in Cura 3
(which probably is not a surprise to all of you who knew this was an issue, but in case.)

[filipgoc]

Sorry to re-ignite the issue, I really appreciate all the work and attention that already went toward this.

But is there any workaround for this?

• I have tried adding whitespace around the ; to no avail ;-(
• I have tried # as the comment prefix, to no avail

Or do we just accept that Cura does not support comments in gcode start/end scripts (IF they are not defined as a default in the printer definition json)?

Finally, (related to previoues questions) has this been dropped as something worth fixing or is it on some internal tracker?

[fieldOfView]

I have created a PR that solves this. It comes with the aforementioned caveat, but that has not been an issue for the past two years in Cura.

[filipgoc]

Thanks @fieldOfView! The caveat seems a reasonable deal with the devil.