Collect sample gcode

[eyal0]

I need gcode that has filament change instructions in it or other things that people want to know time until, like maybe time-until-next-layer or time-until-gcode-comment-that-says-Hooray.

A couple files would be apprecated. I will use the samples to set up the defaults.

[crkochan]

I created a gist for you, with some notes and sample gcode. It's a print with two manual filament swaps via M600 commands.

This is on a Prusa MK3 without an MMU, so the filament swaps are manual.

Here you go: https://gist.github.com/crkochan/1a7f40ad7ac535e944d7d3f09460e328

[eyal0]

Okay, I think that I've got something that works now. Want to test it?

You should install this: https://github.com/eyal0/OctoPrint-TimeToFilament/archive/master.zip

It requires PTG version 2.2.2 or later.

[eyal0]

It's configurable. If you don't like the display, you can go into options and modify it. It's a little tricky to do if you don't know any programming but if you make a suggestion to me, I can put it in.

[greendog99]

I love this idea and have been wishing for this for a while!

Would you be willing to look for M0 (pause) in addition to M600 (filament change)? I don't use M600 when changing filaments, as I don't like my printer firmware's implementation. I use a custom gcode post-processing script in PrusaSlicer to look for the M600 and replace it with M0 and a bunch of other gcode to move the head, print a wipe line, etc.

Here's a gist with sample gcode using M0: https://gist.github.com/greendog99/f65fde0ac3c9278b464b198ad46b307d

I'll test the version mentioned above in the meantime...

[eyal0]

Sure, it's easy to add new things to search for. In fact, you can do it yourself from the settings. Just open up the settings, open the "advanced" section, and change the search for ^M600 to ^M0.

Let me know how it works, thanks.

[greendog99]

Got it working, thanks! The first time, I edited the Regex field, but didn't edit the Format field, and it didn't work (it failed with Threw exception: this.progress.TimeToFilament['^M600'] is undefined). Once I realized the message needs to be updated as well to lookup the correct value, all is good. Thanks!

[eyal0]

Ah, cool! I'm glad that it works. Does the reported time look accurate? I never tested the accuracy.

Please let me know. Also, let me know if you have any suggested features.

[greendog99]

The reported time is not right for me, for the filament change OR for the total print time. In the screenshot below, 01:22:03 is the correct print time (top yellow arrow), 01:58:45 is wrong. The filament change time (01:01:43) is very wrong, it should be around 00:23:00. The total print time used to be spot-on for me until now. Each layer takes about two minutes, but the "Layer X in" message usually says around 30 minutes, and changes rapidly (e.g. after a minute of printing, halfway through the layer, it's down to 15 minutes remaining).

Edit: here's my TimeToFilament settings. I pasted my entire gcode into the sample section, but the times are wildly off, so I'm not sure if it's actually computing the time for the sample gcode:

I'm still on v2.2.2 of PrintTimeGenius and v0.1.0 of TimeToFilament. Thanks, and let me know if I can help track this down...

---

Update/Edit: Now that I've done the filament change, the "Print Time Left" is accurate, however, the "Layer X in" message is gone... no more layer times showing up. I wonder if all these problems are unique to using M0/Pause in my code? Maybe that's messing things up?

Here is while OctoPrint is paused and I'm changing the filament:

And here is shortly after clicking "Resume" in OctoPrint, after changing Filament:

[eyal0]

The layer messages and the time to filament only show up if that message exists in the rest of the file. So, for example, if you're on the last layer, there won't be a message to show.

As for why the estimates are so far off, I don't know. I had to modify PTG in order to make this new plugin work. So it could be the fault of either. Or something else entirely.

Could you send the PTG log file? Maybe there is a clue in there?

[greendog99]

As a test, I disabled all my other plugins, and TimeToFilament started working correctly. Re-enabling one at a time, this appears to be some kind of conflict with the OctoPrint-MQTT plugin. With that disabled, the print time and filament time works correctly (first screenshot below). When I re-enable the MQTT plugin, the times are way off again (second screenshot).

MQTT plugin DISABLED:

MQTT plugin ENABLED (incorrect print and filament times):

The plugin_PrintTimeGenius_engine.log contents are identical in both cases.

Not sure if you're familiar with MQTT, but that plugin just monitors OctoPrint events and publishes them over the network for monitoring purposes. It should be pretty much a read-only plugin, so I'm not sure why it would have this kind of interaction with TimeToFilament...

[eyal0]

Good job debugging. You feel confident that MQTT and TTF are the ones interacting poorly?

Okay. I read through the MQTT code and I, too, don't see why this would be the case. I do see that the MQTT plugin is interacting with the progress updates from TTF. So long as it doesn't modify them, it shouldn't have any effect and I don't see any modifications.

We can alert @foosel and @OctoPrint about this as a first step.

I have never used MQTT. If I want to test this in my own setup, is it enough that I just install MQTT? Do I need to configure anything? I have never heard of MQTT.

[greendog99]

I'm fairly confident, even though it doesn't make logical sense to me.

Just installing the MQTT plugin (without an MQTT server) is enough to make the problem surface for me. If you really wanted, you could configure the plugin to talk to test.mosquitto.org just for testing purposes.

MQTT is widely used for "Internet of Things" home automation, e.g. lights, thermostats, sensors, etc. publish status and metrics to the MQTT server, and other devices can monitor that data to send alarms, create charts, etc.

Here's an example of the MQTT messages from OctoPrint:

[eyal0]

We'll discuss the MQTT issue in #3 . It's better to keep each issue on github to handle just one topic.