[BFW-5832] [BUG] M73 G-Code status report not correct

[samdurnxn]

Printer model

Mini+

Firmware version

6.0.0, 6.0.3

Upgrades and modifications

None

Printing from...

Prusa Link

Describe the bug

In PrusaSlicer, the option to send progress("Printers -> general -> Supports remaining time") is correctly tick.

For my purpose, I create a python script which read serial data from the printer, every 60s I'd like to know the progress, the remain time and the time until the next change (break or color change). As it's explain in this article, you can get the progress by sending the M73 G-Code without any parameters.

The printer answer this code with :
M73 Progress: 5%
Time left: 0m
Change: 10m

But the values for time left and change are not updated.

How to reproduce

You can reproduce this issue like this :

• connect a device on Linux for example on the serial port of the mini
• open a terminal and run the command 'screen /dev/ttyACM0'
• start a printing on the mini
• on the terminal, type 'M73' then enter to send the command
• The printer will normally answer with progress informations

Expected behavior

Normally, the time left value and the time of next change have to be update like the progress value.

Files

No response

[danopernis]

Hi @samdurnxn thanks for the report. I confirm the issue is present, we will work on fixing it.

[samdurnxn]

just for my information, any news on the fix ?

[danopernis]

@samdurnxn the fix was merged into 6.1.0, which was just released for mk4s; release for other printers will follow "in near future" - probably in several weeks.

[samdurnxn]

My bad, I check the release summary not the comparaison with previous release.
I will wait for the MK4 version of it.
Thanks for your works!

[danopernis]

Nah, it is OK to ask. Nobody expects you to read 1000 commit messages. I would personally prefer smaller releases more often, but that's the way it is 🙂

[samdurnxn]

I fully understand as I'm an developer too ;)

[danopernis]

@samdurnxn new version of the firmware 6.1.2 should contain the fix, can you test that?

[samdurnxn]

Hello,
Response of M73 is OK for the time left now but not for the next change.

T:231.06/230.00 B:59.98/60.00 X:37.75/36.00 A:50.31/0.00 @:101 B@:67 HBR@:255
> echo: M73 Progress: 1%;
> Time left: 36m;
> Change: 0m;
> ok
> T:230.51/230.00 B:59.93/60.00 X:37.55/36.00 A:50.39/0.00 @:109 B@:64 HBR@:255
> T:230.25/230.00 B:60.06/60.00 X:37.08/36.00 A:50.39/0.00 @:104 B@:20 HBR@:249
> T:230.08/230.00 B:60.05/60.00 X:36.98/36.00 A:50.44/0.00 @:107 B@:40 HBR@:248
> T:229.85/230.00 B:60.06/60.00 X:36.93/36.00 A:50.50/0.00 @:113 B@:27 HBR@:245
.....
> T:229.85/230.00 B:60.00/60.00 X:36.95/36.00 A:50.69/0.00 @:111 B@:50 HBR@:255
> T:229.92/230.00 B:59.98/60.00 X:36.91/36.00 A:50.69/0.00 @:109 B@:53 HBR@:255
> X:122.03 Y:108.91 Z:0.20 E:0.00 Count X:12581 Y:10482 Z:45
> T:230.06/230.00 B:59.94/60.00 X:37.17/36.00 A:50.75/0.00 @:105 B@:57 HBR@:255
> echo:busy: processing
> T:229.68/220.00 B:59.89/55.00 X:37.40/36.00 A:50.80/0.00 @:0 B@:0 HBR@:255
> echo: M73 Progress: 4%;
> Time left: 35m;
> Change: 0m;

And on the printer screen, the next change value is "N/A". Strange because I add little box in PrusaSlicer with many colors changes with the MMU3.
Picture and bgcode attached
Shape-BoxTestM73.zip

[samdurnxn]

Update from my previous test with the 6.1.2 firmware.
With a new print, I have to insert break to put magnets during printing, and the remaining time works.
I have the remaining time both on serial link(M73) and on screen when I use M601 gcode.

@danopernis can you confirm that for the moment the remaing time is handle only with M6xx gcode ?
I think this because with the MMU3, the colors changes are done with a Tx gcode and not a M600.

If I'm right, can you add the Tx gcode support for the remaining time for a future version ?

[samdurnxn]

I just update the firmware to 6.2 alpha1.
Time left is still OK but the next time change is still at 0m.

Have you plan to handle this value for both M6xx and Tx gcode or not ?

I don't know if it's relevant to many people but for me I need this information to add it on a detached monitoring screen.

[danopernis]

@samdurnxn I was looking into this, but then got distracted by something more important. I am still hoping to fix this at least by final v6.2.0

Thanks for the suggestion about MMU and Tx gcodes, that helped a lot and seems like you are on the right track.

[samdurnxn]

No problem, I understand.
Great if you can add the support for TX gcode!
Good luck finding the solution. Last week, I cloned the repo on my PC to see if I could find where it could be modified, but I didn't manage to. I'm better with PHP code than C++ ;)

[danopernis]

@samdurnxn I looked into it some more and the only G-code that sets up time to pause is M73 Cx Dy. I tried generating some G-code for MMU with the pause and indeed I don't see any M73 Cx Dy in generated file. This looks like a bug on the Slicer side if I understand it correctly. Can you please open an issue at https://github.com/prusa3d/PrusaSlicer ?

Technical detour, we need to have those M73 in the instruction stream because it is not possible to put entire G-code to MCU memory and compute actual time. For serial printing that is also impossible, because actual lines of G-code arrive some time in the future. The solution to this problem is for slicer to essentially simulate the printer and insert those M73 G-codes to instruct the printer what to display on the screen.

[samdurnxn]

@danopernis ah I understand.

An issue have been already opened on this bug -> prusa3d/PrusaSlicer#13031 (comment)

I had a comment on it.

[Prusa-Support]

I seem to understand that part of the remaining issue had to be corrected in Prusa Slicer. Also, I seem to understand that the correction was already made in Prusa Slicer so it may be included with the new PrusaSlicer 2.9.0-alpha1 Pre-release.
Please give it a try and consider closing the issue if the fix is confirmed in your tests.

Michele Moramarco
Prusa Research

[samdurnxn]

Hello, I download this version and test with only a shape box and some multipainting. If I open the generate GCODE, there is no M73 Cxx line. So for me the bug is not solve yet. I will add a comment in the ticket prusa3d/Prusa-Firmware#4734 too

[Prusa-Support]

Thanks for your feedback. The slicer team seems to confirm that the problem continues as long as ramping is enabled.
They are already working on it on the slicer side while the problem should be solved on the firmware side.
For the time being, you may be able to test the feature while having "use ramping lift" disabled in Prusa Slicer settings to confirm whether this issue may closed as solved at least on the firmware side.

Michele Moramarco
Prusa Research

[samdurnxn]

Thanks for the tips.
I done it but any M73 Cxx line are present in gcode. Maybe I missed something ?

My new config :

I attached the 3mf too like this you can check if there is anything wrong in my setup.
TestRamping.zip

[Prusa-Support]

@samdurnxn Your file has no user interaction.

Try to add a simple manual color change.

Michele Moramarco
Prusa Research

[samdurnxn]

I made 4 tests;

• A color change with ramping : M600 and M73 Cx / M73 Dx are present
• A color change without ramping : M600 and M73 Cx / M73 Dx are present
• With Multimaterial paint and with ramping: Tx are present but not M73 Cx /Dx
• With Multimaterial paint and without ramping: Tx are present but not M73 Cx /Dx

I already know that with a manual color change at a specific layer M73 Cx / M73 Dx works but my question is as I have an MMU3, I'd like to know when the next color change will be for my monitoring system. I would like to take advantage to color only some parts of a layer with the MMU3.

Actually, tell me if for you, it's normal that the M73 C/D can only be available with M600/M601 code and not with multimaterial painting. If it's normal maybe you can add it in the next feature list of PrusaSlicer ?

[Prusa-Support]

Actually, tell me if for you, it's normal that the M73 C/D can only be available with M600/M601 code and not with multimaterial painting.

I may be just confused but I think the answer is 'yes'.

Please note that MMU is meant for automatic change without user interaction.
This also means thousands of automatic color changes may occur on a simple multi material print, potentially even every few seconds in certain even rather common print scenarios.
We don't plan to provide indications for thousands of automatic filament changes so if this is the ultimate request, I assume the issue may be closed as "not planned"; or it may stay open for some time to collect more requests and other realistic use cases.

Users may plan their manual user interaction in advance, whereas Prusa Slicer will inject M73 codes to help the user schedule their active interactions, supposedly only when manual user interaction is needed and not for automated long sequences of filament changes.

Last but not least, given that this issue is based on Prusa MINI, it would surely be great to see community projects about it but MMU functionality should virtually be identified as not directly supported.

Michele Moramarco
Prusa Research

[samdurnxn]

Hello, thanks for your explanation. I understand.