invalid literal for int() with base 10:

[GordonW-Printer]

I'm using Octoprint 1.4, DisplayLayerProgress 1.8.1, Python 2.7, PrusaSlicer 2.2.0-alpha2 and my Octoprint Upload folder is actually an SMB (cifs) share from a NAS, so I don't go through the Octoprint "Upload" process, I simply write directly to the NAS from the system hosting the slicer S/W.

Because I never go through you Upload Gcode processor, I have added Custom Gcodes to the slicer to insert the M117 layer codes:

Before Layer Change G-code:
;Original - BEFORE_LAYER_CHANGE
G92 E0.0
;[layer_z]
; Following Setting used by Octoprint DisplayLayerProgress Plugin.
M117 INDICATOR-Layer{layer_num+1}

End G-code:
; Following Setting used by Octoprint DisplayLayerProgress Plugin.
;MAXZ:[layer_z]

All seems to be working, with the exception of the following error message:

octoprint.plugins.DisplayLayerProgress - ERROR - ERROR! File: '/mnt/HomeNAS/3D_Projects/OctoPrint/GWtest1.gcode' Line: 13572 Message: 'invalid literal for int() with base 10: '''

Looking at the Gcode file, line #13575 is a comment inserted at the end of the file by the slicer, I don't find any way to suppress the addition of the comments by the slicer.

13572 ; before_layer_gcode = ;Original - BEFORE_LAYER_CHANGE\nG92 E0.0\n;[layer_z]\n; Following Setting used by Octoprint DisplayLayerProgress Plugin.\nM117 INDICATOR -Layer{layer_num+1}

While I'm a python novice (experience in several other coding languages), looking at the code I suspect that the DisplayLayerProgress code "LAYER_COUNT_EXPRESSION" is matching the M117 part of the comment and reporting it as an error.

So my question is can you suggest a way to restrict the detection of "M117" to the leading byte of the lines?

[OllisGit]

Hi @GordonW-Printer ,

please attach the affected gcode-file, so it is easier for my to reproduce the issue.

Thx, in advance
Olli

[GordonW-Printer]

This file reports the error at line #14346.

Hose_Repair_Threaded_0.2mm_PLA_MK3S_13m.gcode.gz

[OllisGit]

Hi @GordonW-Printer ,
currently I used this pattern to detect M117 Indicators:

M117 INDICATOR-Layer([0-9]*)

I thought it only detects the M117 with numbers at the end, but that was wrong!

Now I switch to:

M117 INDICATOR-Layer([0-9]+)

So, now the first char behind ...Layer needs to be a number. Your pattern will not be detected as an error, because there is a {.

Will be fixed in the next release!

[GordonW-Printer]

Olli,
Thanks for the fast response, I modified my local instance of the code and ran a test, I no longer see the error message.

Regards,
Gordon...

[GordonW-Printer]

Hi,
I ran a quick test to evaluate the impact of modifying the search to ONLY look for M117 commands that start in byte 1 of the gcode string, I included data results from the python profiler and the debugger to verify required results from match as comments within the attached test code file.
I ran 3 tests on a test platform (Intel platform) to evaluate relative performance
1 - Your recent search change
LAYER_COUNT_EXPRESSION = ".*\n?" +LAYER_MESSAGE_PREFIX + "([0-9]+)"
2 - Using only the M117 code (failed to return layer number, I kinda expected that)
LAYER_MESSAGE_PREFIX = "M117 INDICATOR-Layer"
3- Modified M117 code
LAYER_MESSAGE_PREFIX2 = "M117 INDICATOR-Layer([0-9]+)"

Looking at the profiler O/P, I see that the match dropped from 0.017 seconds to 0.007 on my test system and from 0.425 seconds to 0.273 seconds on the R-Pi-Zero that runs my Octoprint instance.
This could provide some improvements, particularly on files with lare numbers of gcode records.

My_test.py.gz

[OllisGit]

Hi @GordonW-Printer,

thanks I appreciate that a lot!!!
I never used a profiler in python before, so I will take a deeper look into your findings.
Which profiler do you use ? (cProfile)

[GordonW-Printer]

Hi, I used to following command "python3 -m cProfile test.py".

[OllisGit]

Hi @GordonW-Printer ,

as mentioned the new Version 1.19.0 now includes the changed pattern, but not totally changed as you suggested.
Because there was an issue in the past and so I added ".*\n?" this part (needs to find the related issue).
I created a ticket to analyse the behaviour a little bit deeper.

Maybe you can test the new version and give me feedback.

Thx, in advance
Olli

[GordonW-Printer]

Updated to 1.19.1 (latest version) and the error message is no longer being reported.
Thank,
Gordon...