Doesn't seem to be working with M0?

[vaderag]

I tweaked the code as I use M0 for my pause and the example in the plugin showed correctly I'm printing a gcode with an M0 but it shows time to change as zero. Double checked the Gcode definitely has the M0 - am I missing something?

[AlfaOmega777]

Exactly the same problem, and I've just made this github account just for report this. The problem is that, as you say, if we modify the config to M0 command, this doesn't seem to work, so I reset the defautl config of the plugin and modified the Gcode, i just replaced M0 with M600, but it doesn´t work either. So I'm doing something wrong or there is a bug

[vaderag]

Glad I'm not alone!

[eyal0]

It's working okay for me:

Are you able to send me a picture of what your settings look like? Maybe there is a problem in there?

[AlfaOmega777]

Hi, thanks for replying. This is the code I have, as you can see, in the example code it works, but not in real printing. One detail may help you. If I choose a Gcode wich doesn't contain M0, "Time to next filament change" doesn't appear on GUI, so th plugin is detecting correctly that there is no M0 in this Gcode, but if I choose a Gcode with M0 in it, Time to next filament change is always 00:00:00 and Time of next filamente Change is always the same that Print Time left.

[eyal0]

Other people have reported a problem like this, too. But I have never been able to reproduce it so I dunno how to fix it.

If someone with skill in programming that saw this error were able to reproduce it then maybe he or she could work on it. I have no idea how to work on it.

[vaderag]

I'm seeing exactly the same as @AlfaOmega777 I'm wondering if there may be a clash between plugins somehow. Honestly don't know, I don't frequently do multiple layer changes but will try disabling some others next time I do

@AlfaOmega777 out of interest can you list which other plugins you're using at the same time?

[AlfaOmega777]

I'm programmer, what information do you need?

[eyal0]

Okay, let's start with this:

https://github.com/eyal0/OctoPrint-TimeToFilament/archive/refs/heads/debug_TTF.zip

You can install that in octoprint using the normal menu but instead of picking TimeToFilament from a list, just copy and paste that URL. It will install on top of your existing plugin. it adds logging like this:

                self._logger.info(f"estimate for position {match_pos} out of {self._printer._comm._currentFile.getFilesize()} is {time_left}")

Then print again and look for that text in ~/.octoprint/logs/plugin_TimeToFilament_engine.log. For me, it looks like this:

2021-04-13 17:14:52,164 estimate for position 6067912 out of 8986869 is 31.640423710194952.  Total print time is (130.50370395405014, 'genius').  Remaining print time is (113.11616339145482, 'genius')

Which means that when the printer gets to byte position 6067912 in the file which is a total size of 8986869, when it gets there, there is 31.64 seconds of printing remaining to be done. So if the remaining print time is 113 seconds then it means M0 will be in 113-31=84 seconds, approximately.

I'm using emacs to open the file but you can use whatever you want. If I go to character 6067912 in my file which I printed, which is in ~/.octoprint/uploads, then I see M0. And the file length is truly 8986869.

So all that is working as expected. I want to see if you similar results. If the numbers look right, then something is wrong in TimeToFilament. If the numbers look wrong then something is wrong in PrintTimeGenius.

That's my idea so far. Also, I am importing true division from future now in python, just in case maybe you're on python2 instead of python3. I'm doing division in the code and maybe it's truncating the result.

Anyway, let's start with that. If you can think of other ways that we can debug this better, let me know. We'll start with this.

You'll be able to reinstall the original version of TimeToFilament easily when we're done with our testing and none of your settings will be modified by any of this.

Here is the code that I added, BTW:

diff --git a/octoprint_TimeToFilament/__init__.py b/octoprint_TimeToFilament/__init__.py
index db13fda..e8e5aca 100644
--- a/octoprint_TimeToFilament/__init__.py
+++ b/octoprint_TimeToFilament/__init__.py
@@ -1,5 +1,6 @@
 # coding=utf-8
 from __future__ import absolute_import
+from __future__ import division

 import copy
 import types
@@ -127,6 +128,7 @@ class TimeToFilamentPlugin(octoprint.plugin.SettingsPlugin,
                 time_left, _ = self._printer._estimator.estimate(
                     float(match_pos) / self._printer._comm._currentFile.getFilesize(),
                     None, None, None, None)
+                self._logger.info(f"estimate for position {match_pos} out of {self._printer._comm._currentFile.getFilesize()} is {time_left}.  Total print time is {self._printer._estimator.estimate(0, None, None, None, None)}.  Remaining print time is {self._printer._estimator.estimate(self._printer._comm._currentFile.getFilepos()/ self._printer._comm._currentFile.getFilesize(), None, None, None, None)}")
                 self._cached_results[regex] = {
                     "timeLeft": time_left,
                     "groups": m.groups(),

[eyal0]

:crossed_fingers:

[AlfaOmega777]

Ok, great, in Argentina is late and I wake up very early to work so I have to sleep jaja, but I'll doit as fast as I can!

[AlfaOmega777]

Good morning! Here look at that:

2021-04-14 08:22:55,999 estimate for position 312414 out of 1620014 is 7919.700246152457. Total print time is (7919.700246152457, 'genius'). Remaining print time is (7919.700246152457, 'genius')

There is the problem. FYI: In the GCODE The position 312414 is M0; after the semicolon. Total print time and remaining print time is the same!

[eyal0]

That seems bad! Is the estimate for the total print time that shows on your computer, is that one okay?

When you print, the print time in that screen, it's okay?

[AlfaOmega777]

According to Octoprint the estimated printing time is 7:18:10 so th difference is close if you take the print time left and the print time in the picture I've just taken.

[eyal0]

Okay, now try to install both of these and print again please.

https://github.com/eyal0/OctoPrint-TimeToFilament/archive/refs/heads/debug_TTF.zip https://github.com/eyal0/OctoPrint-PrintTimeGenius/archive/refs/heads/debug_TTF.zip

And then examine the logs, both ~/.octoprint/logs/plugin_PrintTimeGenius_engine.log and ~/.octoprint/logs/plugin_TimeToFilament_engine.log

I added some more logging and hopefully it will tell us something interesting! Thanks!

[AlfaOmega777]

Sorry but I couldn't test this yet. I had so much work yesterday and today, plus I'm rebuilding the printer. But I'll try to test it tomorrow!

[eyal0]

Sure, no problem, whenever you're available. I hope that we can solve this problem which affects so many people.

[AlfaOmega777]

Hi, how are you? I'm really sorry I couldnt continue with this early, but I had too much work to do. Even now I coudnt debugg what you asked to me, but, Here I have a surprise... This time it's working and I made no change to anything, the only difference is that this time I used Simplify 3D as slicer, and previuously I always used Prusa Slicer, so, it shouldn't make the difference but I'ts the only change I made and it's working. After finishing this printing, I'll slice the same stl but with prusa slicer and I'll try if time to filament still works.

[eyal0]

Cool, I'll be interested to know if the different slicer is making a difference. Also, please send me both of those files, with prusa slicer and with simplify 3d. Maybe I will see something inside of the file that will make the difference.

Hmmm, now that I think about it, maybe there is an issue with the line endings? CRLF versus just LF. If you send me the files, I will be able to see this. Just zip them and attach to this issue please.

[AlfaOmega777]

BAd news, It started working with prusa slicer too, but sometimes It doesnt work with simplify 3D either...

[eyal0]

If you can send me some files and let me know which one worked and which one didn't, I can look at them. You can zip them before you put them here on GitHub.

[AlfaOmega777]

The problem is that the same file works some times and others don't. No specific file error. It's very random really!

[Sekisback]

No clue, after playing around with older versions, and changing the language in octorprint to english it works with M600 and M0. It looks like that the Time to next Layer Regex had something to do with it??? For Cura it must be ^;LAYER:(\d+) without spaces. I can reproduce it, with broken Time to next Layer Regex, the time displays only zeros. Maybe this is an explanation, why it works with Slic3r

[eyal0]

So... It's okay now or what?

[Sekisback]

Yes seems so. In my case (working with Cura) I changed the Time to Next Layer Regex to

^;LAYER:(\d+)

and both M0 and M600 are working now