Nothing getting analysed

[nachobacanful]

OctoPrint Version: OctoPrint 1.5.3 Python 2.7.16 OctoPi 0.17.0 PrintTimeGenius Version (if you know): 2.2.7 Cura: 4.8.0

What did you try: Checked my config (M503). Checked that the commands M201, 202 .... dont have S0 in them (in my gcodes). I also checked issues here in github for similar errors but didnt find one.

What happened: Everything was working perfectly. One random day it stopped analyzing, this did not occur after an update. None of my files are getting analyzed

What did you expect to happen: Analyze a file

Here are two logs. One is after a reboot if that makes a difference. plugin_PrintTimeGenius_engine (1).log plugin_PrintTimeGenius_engine.log

here are two sample gcodes that will not work: sample_gcode.zip

[nachobacanful]

@eyal0 any info on this? dont mean to rush you, I know you are probably busy. At this point, my only solution is to clean install my octoprint

[eyal0]

I do see errors in your logs that shouldn't happen:

recent call last): File "/home/pi/oprint/lib/python2.7/site-packages/octoprint_PrintTimeGenius/analyzers/analyze_progress.py", line 97, in main() File "/home/pi/oprint/lib/python2.7/site-packages/octoprint_PrintTimeGenius/analyzers/analyze_progress.py", line 65, in main result.update(json.loads(line)) File "/usr/lib/python2.7/json/init.py", line 339, in loads return _default_decoder.decode(s) File "/usr/lib/python2.7/json/decoder.py", line 364, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode raise ValueError("No JSON object could be decoded") ValueError: No JSON object could be decoded

That's surprising. It looks like the file was analyzed yet the output from that analysis wasn't valid and it couldn't understand it.

Are you able to connect to your device that is running OctoPrint (maybe it's a Raspberry Pi) and try running the command yourself? Just type in:

"/home/pi/oprint/bin/python2" "/home/pi/oprint/lib/python2.7/site-packages/octoprint_PrintTimeGenius/analyzers/analyze_progress.py" marlin-calc "/home/pi/.octoprint/uploads/CE3PRO_Alexa_R2D2_Rasor_-_Main_Body.gcode" "M221 T0 S0
M200 S0 D1.75
M92 X80.00 Y80.00 Z400.00 E93.00
M203 X500.00 Y500.00 Z5.00 E25.00
M201 X500.00 Y500.00 Z100.00 E5000.00
M204 P500.00 R500.00 T500.00
M205 B20000.00 S0.00 T0.00 J0.08
M900 K0.00"

And see what happens. Thanks.

[nachobacanful]

I get the following error:

Running: "/home/pi/oprint/lib/python2.7/site-packages/octoprint_PrintTimeGenius/analyzers/marlin-calc.armv7l" "/home/pi/.octoprint/uploads/CE3PRO_Alexa_R2D2_Rasor_-_Main_Body.gcode" "M221 T0 S0
M200 S0 D1.75
M92 X80.00 Y80.00 Z400.00 E93.00
M203 X500.00 Y500.00 Z5.00 E25.00
M201 X500.00 Y500.00 Z100.00 E5000.00
M204 P500.00 R500.00 T500.00
M205 B20000.00 S0.00 T0.00 J0.08
M900 K0.00"
Junction deviation enabled
............Read up all remaining commands
Processed 1353066 Gcodes and 1477 Mcodes. 1295719 blocks
Total time: 144989.221020
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python2.7/site-packages/octoprint_PrintTimeGenius/analyzers/analyze_progress.py", line 97, in <module>
    main()
  File "/home/pi/oprint/lib/python2.7/site-packages/octoprint_PrintTimeGenius/analyzers/analyze_progress.py", line 65, in main
    result.update(json.loads(line))
  File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
    raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

[nachobacanful]

The input to the above json.loads evaluates to the following:

line = ' {"estimatedPrintTime": 144989.22102009310037829, "printingArea": {"maxX": -inf, "maxY": -inf, "maxZ": -inf, "minX": inf, "minY": inf, "minZ": inf}, "dimensions": {"width": -inf, "depth": -inf, "height": -inf}, "filament": {}}\n'

I tested exactly where it breaks and json.loads breaks with the inf.

Also based on the above output I can see that there is an estimate (idk what unit that is), not sure if it somewhat matches wth the actual print time I had on that piece, it took 42:18:05 to print. I personally don't know the codebase for this project but I assume that those shouldn't be infs ? perhaps there is a problem with my files, resulting in these being infs?

[eyal0]

Okay, the infs are bad, yes, that means infinity!

The time is in seconds. 144989.22102009310037829 seconds is about 40 hours, which is similar to what you experienced, yes? So not bad.

The cause for the infinities is usually due to some problem with the processing. I will give you a new command to try:

"/home/pi/oprint/lib/python2.7/site-packages/octoprint_PrintTimeGenius/analyzers/marlin-calc.armv7l" "/home/pi/.octoprint/uploads/CE3PRO_Alexa_R2D2_Rasor_-_Main_Body.gcode" "M221 T0 S0
M200 S0 D1.75
M92 X80.00 Y80.00 Z400.00 E93.00
M203 X500.00 Y500.00 Z5.00 E25.00
M201 X500.00 Y500.00 Z100.00 E5000.00
M204 P500.00 R500.00 T500.00
M205 B20000.00 S0.00 T0.00 J0.08
M900 K0.00"

The python command that you ran before is running this marlin-calc command and then the output of that command is processed. Maybe the output is not valid. Please run this command and look at the output, thank you.

Notice that the command is multiple lines! This is expected and good. Each of those M code commands should be on a different line so that it is processed correctly.

Please try and let me know what the output is, thank you! I will show you what my output looks like, so that you can see an example:

└──> scons ./out/x86_64/marlin-calc.x86_64 && ./out/x86_64/marlin-calc.x86_64 ~/Downloads/CE3PRO_Alexa_R2D2_Rasor_-_Main_Body.gcode "M220 S100
M221 T0 S100
M200 S0 D1.75
M92 X80.00 Y80.00 Z4000.00 E102.86
M203 X250.00 Y250.00 Z2.00 E22.00
M201 X1000.00 Y1000.00 Z5.00 E1000.00
M204 P3000.00 R3000.00 T3000.00
M205 B20000.00 S0.00 T0.00 J0.01"
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
scons: `out/x86_64/marlin-calc.x86_64' is up to date.
scons: done building targets.
Junction deviation enabled
Progress: 0.00002443590956211, 0.00000000000000000, 15.48003601694915154
Progress: 0.00002837875552732, 0.00000000000000000, 19.78971811469703823
Progress: 0.00002954700618367, 0.00000000000000000, 20.96902155632401588
Progress: 0.00003081261106139, 0.00000000000000000, 28.18235440964686589
Progress: 0.00003207821593911, 15.00000000000000000, 28.20852671062832684
Progress: 0.00003334382081683, 15.00000000000000000, 35.42394881484119651
Progress: 0.00003568032212954, 30.00000000000000000, 36.55273802900313029
Progress: 0.00003723798967135, 30.00000000000000000, 37.82255080697217409
Progress: 0.00003957449098406, 29.79999999701976776, 38.99648821825809364
Progress: 0.00004028030908894, 29.79999999701976776, 39.29867255802508197
Progress: 0.00004181363807541, 23.29999999701976776, 40.55074248341209397
Progress: 0.00004268982606768, 23.29999999701976776, 40.85141047448205143
Progress: 0.00004349299839392, 29.79999999701976776, 41.41391611917061510
Progress: 0.00004415013938812, 30.47066001594066620, 41.42292512817962091
...
Progress: 0.99995898953425089, 95175.59736313857138157, 148424.87969118115142919
Progress: 0.99995979270657709, 95175.76435532607138157, 148425.13162417084095068
Progress: 0.99996057154034801, 95175.93207993544638157, 148425.38304552269983105
Progress: 0.99996137471267421, 95176.09931626357138157, 148425.64087936622672714
Read up all remaining commands
Progress: 0.99996203185366839, 95176.26704087294638157, 148425.67407584664761089
Progress: 0.99996373555254225, 95176.26704087294638157, 148425.97597025777213275
Progress: 0.99996575565263557, 95169.76704087294638157, 148426.06996391562279314
Progress: 0.99996670485629380, 95167.76704087294638157, 148426.19345882144989446
Progress: 0.99996731332017741, 95165.76704087294638157, 148426.36699864582624286
Progress: 0.99996782442983956, 95165.76704087294638157, 148431.62939516195910983
Progress: 0.99996984452993276, 95165.76704087294638157, 148433.96029642104986124
Processed 1353065 Gcodes and 30 Mcodes. 1318682 blocks
Total time: 148433.960296
Analysis: {"estimatedPrintTime": 148433.96029642104986124, "printingArea": {"maxX": 190.92999267578125000, "maxY": 200.00000000000000000, "maxZ": 146.09500122070312500, "minX": 5.00000000000000000, "minY": 20.00000000000000000, "minZ": 0.20000000298023224}, "dimensions": {"width": 185.92999267578125000, "depth": 180.00000000000000000, "height": 145.89500121772289276}, "filament": {"tool0": {"length": 95165.76704087294638157, "volume": 228.90049462239628042}}}

I have removed some of the lines that are in the middle. My estimate was 148433 seconds. Notice, no inf anywhere in there.

Please try and send the output. You can remove some of the lines in the middle, like I did, so that it is not too long.

[nachobacanful]

The output was really long so I did command > output 2>&1 and then cat output | grep -v 'Progress: ' I made sure that it executed with the multiline arguments.

here is the output

Junction deviation enabled
Processed 1353066 Gcodes and 1477 Mcodes. 1295719 blocks
Total time: 144989.221020
3246526907820, 0.00000000000000000, 144975.22549419826827943
Analysis: {"estimatedPrintTime": 144989.22102009310037829, "printingArea": {"maxX": -inf, "maxY": -inf, "maxZ": -inf, "minX": inf, "minY": inf, "minZ": inf}, "dimensions": {"width": -inf, "depth": -inf, "height": -inf}, "filament": {}}

here is the original output if you need that out.tar.gz

yeah seems like the output of marlin-calc is no good. Does this binary have a more verbose mode?

I was thinking if this works for you and not for me it could be different input. So I went ahead and downloaded what I uploaded when I opened the issue (btw i just downloaded taht from the octoprin interface). I also got the one I have been using for all the test (the one that in the uploads folder in the pi, the one that fails) and compared the MD5 sum hashes and they don't match. So I scped the file over to the pi and retried that commands on that file, same output with the infinities. I later also did a diff for both files and they are the same :/ , so that's not it.

[eyal0]

The binary does not have a more verbose option, no.

I've never seen this kind of failure. It's surprising to me that it should fail like this. I would expect that it either fails entirely or provides the correct answer. Somehow for you it is computing the total time correctly but all the rest is wrong. Very odd.

There are many versions of marlin-calc in the same directory, each one is for a different platform. Can you see if one of the others is working better for you? PTG was supposed to guess the correct one but maybe that didn't work?

By the way, what is the hardware for your OctoPrint? It's a regular Raspberry Pi?

If you know how to compile code, the source code for marlin-calc is on GitHub and it's eyal0/Marlin. You need to find the SConstruct directory in there and run scons in order to compile it.

I really can't think what might be causing the issue that you are seeing. Maybe it is the floating point math? In the code we are trying to find the maximum value for each coordinate x y z. The maximum of negative infinity and some number should be the number so the infinity should disappear.

Perhaps also trying running marlin calc without any of the M codes. You can provide an empty string or you can just leave it out and process the file with defaults. See if that is different.

Also, my time estimate is not the same as yours. That's unexpected. It should be identical. You're using the latest version of PTG?

[nachobacanful]

Its up to date with the lastest from the octoprint repo. that is 2.2.7 for PTG.

yeah I am running octoprint from my pi. so arm yes. Also uname confirms it its armv7l.

I tried with the gcode file path argument for the same file and with an empty mcode argument and got the following:

Total time: 138632.760240
Analysis: {"estimatedPrintTime": 138632.76023977083968930, "printingArea": {"maxX": 190.92999267578125000, "maxY": 200.00000000000000000, "maxZ": 146.09500122070312500, "minX": 5.00000000000000000, "minY": 20.00000000000000000, "minZ": 0.20000000298023224}, "dimensions": {"width": 185.92999267578125000, "depth": 180.00000000000000000, "height": 145.89500121772289276}, "filament": {"tool0": {"length": 95165.76704087294638157, "volume": 228.90049462239628042}}}

Ill compile that when I free up so I can mess around with the source. Can you roughly point me to the source file that you think may be causing the issue? if not ill figure out once I compile it.

[eyal0]

Ah this one looks better! No infinity!

[eyal0]

Try to use just some of the M codes and determine which one is causing the infinity.

[nachobacanful]

I tried the same file with each M code separately. here is a list of the ones that passed or failed:

M221 T0 S0 -> fail
M200 S0 D1.75 -> good
M92 X80.00 Y80.00 Z400.00 E93.00 -> good
M203 X500.00 Y500.00 Z5.00 E25.00 -> good
M201 X500.00 Y500.00 Z100.00 E5000.00 -> good
M204 P500.00 R500.00 T500.00 -> good
M205 B20000.00 S0.00 T0.00 J0.08 -> good
M900 K0.00 -> good

one very interesting output that may help you narrow down the bug, here is the head of the output (eg M92) for one that works

Progress: 0.00002443590956211, 0.00000000000000000, 12.14387443178280002
Progress: 0.00002837875552732, 0.00000000000000000, 13.78304804470848843
Progress: 0.00002954700618367, 0.00000000000000000, 14.16424839882031961
Progress: 0.00003081261106139, 0.00000000000000000, 21.36386098416233992
Progress: 0.00003207821593911, 15.00000000000000000, 21.37840489302275770
Progress: 0.00003334382081683, 15.00000000000000000, 28.58006490862321769
Progress: 0.00003568032212954, 30.00000000000000000, 28.95687772014973760
Progress: 0.00003723798967135, 30.00000000000000000, 29.36075210714412265
Progress: 0.00003957449098406, 29.79999999701976776, 29.74290007904416910
Progress: 0.00004028030908894, 29.79999999701976776, 30.00765714561916653

here is the head of the output for one that fails (eg M221):

Progress: 0.00002443590956211, 0.00000000000000000, 12.14387443178280002
Progress: 0.00002837875552732, 0.00000000000000000, 13.78304804470848843
Progress: 0.00002954700618367, 0.00000000000000000, 14.16424839882031961
Progress: 0.00003081261106139, 0.00000000000000000, 21.36386098416233992
Progress: 0.00003207821593911, 0.00000000000000000, 21.37840489302275770
Progress: 0.00003334382081683, 0.00000000000000000, 28.58006490862321769
Progress: 0.00003568032212954, 0.00000000000000000, 28.95687772014973760
Progress: 0.00003723798967135, 0.00000000000000000, 29.36075210714412265
Progress: 0.00003957449098406, 0.00000000000000000, 29.74290007904416910
Progress: 0.00004181363807541, 0.00000000000000000, 30.13783574796635634

and tail of the one that fails:

Progress: 0.99995898953425089, 0.00000000000000000, 132097.46248483576346189
Progress: 0.99995979270657709, 0.00000000000000000, 132097.71441782545298338
Progress: 0.99996057154034801, 0.00000000000000000, 132097.96583917731186375
Progress: 0.99996137471267421, 0.00000000000000000, 132098.21849656713311560
Progress: 0.99996203185366839, 0.00000000000000000, 132098.23922572328592651
Progress: 0.99996670485629380, 0.00000000000000000, 132098.30137369519798085
Progress: 0.99996731332017741, 0.00000000000000000, 132098.45457985275425017
Progress: 0.99996782442983956, 0.00000000000000000, 132100.47672742465510964
Progress: 0.99996984452993276, 0.00000000000000000, 132102.77951265691081062
Analysis: {"estimatedPrintTime": 132102.77951265691081062, "printingArea": {"maxX": -inf, "maxY": -inf, "maxZ": -inf, "minX": inf, "minY": inf, "minZ": inf}, "dimensions": {"width": -inf, "depth": -inf, "height": -inf}, "filament": {}}

note the middle value, in the event that it works then it is not zero very early on the processing. if contains one of the failing Mcodes ( listed above) then it is zeroed out for the whole analysis. I assume this is related to the math behind the program, once it fails it fails and just keeps being zero.

Just curious, is my assumption that the extra mcode argument is prepended to the file before analysis?

I have also further tested the failing code M221 T0 S0, it is the S0 that makes it fail. so:

M221 S0 -> fail
M221 -> pass, I assume it gets skipped over because not a valid command see below
M221 T0 -> pass, I assume it gets skipped over also not valid command
M221 T0 S0 -> fail as we knew
M221 S0 T0 -> also fail

the syntax for M221 is M221 S<percent> [T<index>], where S is feed rate and T is target extruder (optional, default to currently active).

[eyal0]

Good analysis. Yes, it's true that the M codes are prepending. It's the same as if the M codes were at the top of the file except that putting them into the file would affect the line numbers and file size so they are ignored for that.

S0 means to print with a rate of 0% so that will definitely affect the print!

I added something about this in the wiki. Click on wiki above and read the page of common problems. It mentions how you can type M503 into your printer and see what the correct values are. You can also find them in the directory .octoprint... I forget the name of the file and I am not next to the computer but it will have the m codes in there. When you type M503 on your printer, PTG will learn the latest values.

[nachobacanful]

Will give that a try once a print finished and I can connect the octopi once again. Probably tonight. If I recall correctly that was one of my first troubleshooting moves, but Ill give it a try again. Ill post again once I execute that.

As a side note: Would it be smart to programmatically trigger an M503 when infinity is detected on the output of marlin-calc by analyzers/analyze_progress.py, at the very least one retry after issuing M503? was there any reasoning as to why PTG does not have that implemented?

Also thanks for the help, really appreciate it :)

[eyal0]

I had that thought once but somehow I thought that it would be difficult to do. Not sure why.

Common problem, though. I should think of a solution.

[nachobacanful]

Just very curious, why does PTG have to prepend code? my assumption is that it need to know the printer values to accurately predit the time estimates. So the analy_proress.py supplements that to marling-calc, but in this case it doesn't know them so it sends a 0 value?

[nachobacanful]

So I issued teh M503 command and waited around a minute or so, then checked ~/.octoprint/data/PrintTimeGenius/printer_config.yaml. It seemed like the issue may be related to the script that grabs the config from eh output of the M503 command because it does not seem to change in the printer_config file. here is that file:

printer_config:
- M221 T0 S0
- M200 S0 D1.75
- M92 X80.00 Y80.00 Z400.00 E95.20
- M203 X500.00 Y500.00 Z5.00 E25.00
- M201 X500.00 Y500.00 Z100.00 E5000.00
- M204 P500.00 R500.00 T500.00
- M205 B20000.00 S0.00 T0.00 J0.08
- M900 K0.56
version: 2.2.7

Here is the output from the terminal for the 503 command:

Send: M503
Recv: echo:  G21    ; Units in mm (mm)
Recv: echo:  M149 C ; Units in Celsius
Recv: 
Recv: echo:; Filament settings: Disabled
Recv: echo:  M200 S0 D1.75
Recv: echo:; Steps per unit:
Recv: echo: M92 X80.00 Y80.00 Z400.00 E95.20
Recv: echo:; Maximum feedrates (units/s):
Recv: echo:  M203 X500.00 Y500.00 Z5.00 E25.00
Recv: echo:; Maximum Acceleration (units/s2):
Recv: echo:  M201 X500.00 Y500.00 Z100.00 E5000.00
Recv: echo:; Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
Recv: echo:  M204 P500.00 R500.00 T500.00
Recv: echo:; Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>
Recv: echo:  M205 B20000.00 S0.00 T0.00 J0.08
Recv: echo:; Home offset:
Recv: echo:  M206 X-5.00 Y-10.00 Z0.00
Recv: echo:; Auto Bed Leveling:
Recv: echo:  M420 S1 Z2.00
Recv: echo:  G29 W I0 J0 Z-0.17500
Recv: echo:  G29 W I1 J0 Z-0.14000
....
Recv: echo:  G29 W I3 J4 Z0.09500
Recv: echo:  G29 W I4 J4 Z-0.12750
Recv: echo:; Material heatup parameters:
Recv: echo:  M145 S0 H185 B45 F255
Recv: echo:  M145 S1 H240 B110 F255
Recv: echo:; PID settings:
Recv: echo:  M301 P21.73 I1.54 D76.55
Recv: ; Controller Fan
Recv: echo:  M710 S255 I0 A1 D60 ; (100% 0%)
Recv: echo:; Power-Loss Recovery:
Recv: echo:  M413 S1
Recv: echo:; Z-Probe Offset (mm):
Recv: echo:  M851 X-40.00 Y-10.00 Z-3.73
Recv: echo:; Stepper driver current:
Recv: echo:  M906 X580 Y580 Z580
Recv: echo:  M906 T0 E650
Recv: 
Recv: echo:; Driver stepping mode:
Recv: echo:  M569 S1 X Y Z
Recv: echo:  M569 S1 T0 E
Recv: echo:; Linear Advance:
Recv: echo:  M900 K0.56
Recv: echo:; Filament load/unload lengths:
Recv: echo:  M603 L350.00 U400.00
Recv: ok

After comparing the config with the printer_config file I realized that there is no M221 or flow rate on the M503 output. Therefore PTG cant grab it. I have also looked into the marlin gcode/mcodes and apparently, you can't get that? Should the M503 include the output for M221 by default?

As a temporary solution I went ahead and changed printer_config.conf to reflect 100% flow rate M221 T0 S100. Restarted and it worked.

Perhaps my issues started to happened way earlier and did not manifest until later. I originally had the original ender 3 motherboards. then changed that for the SKR Mini E3 V2.0. I installed the manufacturers Marling firmware in it. So far no issues here as everything was still configured the same(no config change yet). Then sometime later I got a BLtouch. At this point I issued the M503 command to configure it, as well as linear advance, only that this time I assume this firmware does not have the M221 in the output for M503. I assume that when PTG does not detect the flowrate it automatically sets it to 0 in printer_config file. This could be a bug? as it should leave the lines of the config alone if it cant find information realting that line? (again I am assuming that it modifies all the config upon receiving a M503)

Anyways, we can see here
https://github.com/eyal0/OctoPrint-PrintTimeGenius/blob/7eded78888f61213496ef49f1162724a31cad018/octoprint_PrintTimeGenius/__init__.py#L665
that the exact lines that the code searches for are not in any output(as this is a hook for any output), therefore its never going to get it.

A more new user-friendly solution would be to default the config to a flowrate of 100%. I don't know what piece of code initializes that but that would be a quick fix if you feel like that would be a smart change. Let me know, if I have time I may open a PR.

As for me, I am satisfied with the solution I have. I have learned a lot about this codebase troubleshooting this problem, Once again thanks for the help.

If you have no more comments you can close it.

[eyal0]

The default for the flow rate is 100%. Not sure how the zero flow rate got into your saved config.

There is a file printer_config.py which gets a copy of every Mcode that is either typed in by the user or appears in the output of M503. If it's the output of M503 then sometimes it has some processing done, like the removal of the "echo: " at the beginning. And as you noticed, recognizing the word "Flow:". All this is done to deal with the various ways that printers show the M503 output because that is, sadly, not standard.

The printer_config.py has no defaults. It only stores a specific list of M codes, not all of them. If a new Mcode is seen that matches the list of Mcodea that we care about then the old one is replaced by the new one.

The list of Mcodes is never cleared. Only when a new one arrives, sometimes an old one is replaced. The default is no Mcodes at all in which case the defaults come from marlin-calc, which has the same defaults as the Marlin software itself (because they are the same code).

So either PTG screwed up and thinks that it saw a flow rate of zero when it didn't, or at some point there was a flow rate of zero and then it disappeared.

Because your M503 didn't include a flow rate, the bad flow rate was never removed.

Maybe it would be good if PTG could recognize the M503 command and clear out all the saved printer_config.py before interpreting all the following "echo:" lines that are about to refresh the config?

[nachobacanful]

Here is a quick fix:

# in the PTG class add the following
#class PrintTimeGeniusPlugin:
  def clear_printer_config(self):
    self._old_printer_config = self._current_config.as_list()

    # the new item never touches the file, taht is done by the on_startup hook
    self._current_config =  PrinterConfig() # so this is empty config

    self.write_printer_config()

  # cahnge hook
  def command_sent_hook(self, comm_instance, phase, cmd, cmd_type, gcode, subcode=None, tags=None, *args, **kwargs):
    if self._printer.is_printing():
      return

    strip_cmd = cmd
    strip_cmd = strip_cmd.strip()

    # not sure if this is what this hook does, octoprint has no documentation on the sent hook
   # I assume this is right?
    if "M503" in strip_cmd.upper():
      self.clear_printer_config()

    self.update_printer_config(strip_cmd)

If you like it I can put a PR

[eyal0]

That looks pretty good. I don't have a way to test it because I don't own a printer. If you make the PR, can you test it? You could open up the file ~/.octoprint/data/PrintTimeGenius/printer_config.yaml and put that flow rate command in there. Then run M503 and see that the file is rewritten with the flow rate command removed.

Also, some people like to have flow rate so you might test with setting flow rate to, say, 90%, and then see that it is correctly in the printer config after you type M503.

If you write that PR, I will review it and release a new version, yes.

[nachobacanful]

Cool yeah, I can test it. I am currently traveling I won't get this done till Monday, Tuesday.

correct me if I am wrong

when you say You could open up the file ~/.octoprint/data/PrintTimeGenius/printer_config.yaml and put that flow rate command in there you mean:

1. modify the config file manually to some known value
2. run a M503 via the terminal
3. verify that the config is empty essentially that it is working as intended?

can you elaborate more on this some people like to have flow rate so you might test with setting flow rate to, say, 90%, and then see that it is correctly in the printer config after you type M503. I interpret that as:

1. use the M221 to set a flowrate via terminal
2. verify that the new flowrate is in the config file as intended

[eyal0]

Right, all of that. So like this: Patch the code, then do this:

1. Stop OctoPrint
2. Open ~/.octoprint/data/PrintTimeGenius/printer_config.yaml and add a line like - M221 T0 S0 to the printer_config section.
3. Start OctoPrint.
4. In the console of the printer, type M503.
5. Stop OctoPrint.
6. Confirm that M221 has been removed from the printer_config.

Then do this:

1. Type M221 T0 S90 into the console.
2. Stop OctoPrint.
3. Confirm that - M221 T0 S90 is in ~/.octoprint/data/PrintTimeGenius/printer_config.yaml
4. Start OctoPrint.
5. Type M503 into the printer's console.
6. Stop OctoPrint.
7. Again confirm that - M221 T0 S90 is in ~/.octoprint/data/PrintTimeGenius/printer_config.yaml is in the config.
8. Start OctoPrint.
9. Type M221 T0 S100 to the printer.
10. Stop OctoPrint.
11. Confirm that - M221 T0 S100 is in ~/.octoprint/data/PrintTimeGenius/printer_config.yaml is in the config. (or maybe no M221 line at all, either is fine.).
12. Start OctoPrint.
13. Type M503 to the printer.
14. Stop OctoPrint.
15. Confirm that - M221 T0 S100 is in ~/.octoprint/data/PrintTimeGenius/printer_config.yaml is in the config. (or maybe no M221 line at all, either is fine).

That would be the most thorough way to do it. I suggested stopping OctoPrint before checking the file because I think that the file is only written after OctoPrint is closed, not during operation. This is needed so that we don't write to the file over and over again, which really slows things down.

That would be the most thorough test. I would test it myself but for that, I would need a printer with Marlin installed that can respond to M503 and I don't have a printer at all. I haven't had access to a 3d printer since my previous workplace 3 years ago and since then I've just been supporting this plugin for fun. I don't even get to use it!

Thanks for helping! No hurry, whenever you're able is great!

[nachobacanful]

As a side note to your printer problem.

octoprint has a virtual printer, not sure how useful this could be to you. https://docs.octoprint.org/en/master/development/virtual_printer.html

[eyal0]

Yes, I've used it! One of the limitations is that it doesn't do M503 accurately. It prints with a steady pace going through lines of gcode and it has some pre-programmed retries and CRC errors in communication to test that. It doesn't at all try to estimate the print times so it gives weird numbers for PTG.

Hmm, I wonder if OctoPrint would want a more accurate simulation there. I could make a Marlin virtual printer that works off real Marlin code... Interesting. Would be a cute project.