[BUG] MK4 GCode Compatibility Check not working consistently

[bryn51]

Please, before you create a new bug report, please make sure you searched in open and closed issues and couldn't find anything that matches. Yep, did that: Not found

Printer type -MK4

Printer firmware version - All versions dating back to July 2023. I never install anything other than official release firmware versions.(No alpha, beta versions). I have zero experience with 6.0.0 to say if this issue remains, but the release notes say nothing about it.

Original or Custom firmware - Original

Optional upgrades - Silicone Sock, Enclosure

USB drive or USB/Octoprint Prusalink sourced from PrusaSlicer

Describe the bug When a file is sliced by Prusa Slicer for Mk4 printer with IS, when transfer is complete, the printer scans the file and checks compatibility. I find that "sometimes" the printer tells me via a screen message that the file was sliced for a different printer, but mostly it does not.

• I have 3 MK4 printers purchased in July 2023, December 2023 and March 2024, and all 3 of them have incurred this issue. All 3 of these printers are maintained to have the same firmware version at all times.
• When the same PrusaSlicer project is sliced for a physical printer and published, it might incur this issue, but when sliced for another identically equipped (same of the same type (Model, Nozzle, IS etc) printer, it does not incur this issue. Either the file has a problem or it does not, I expect consistency, or give me a good reason why it should vary.

The problem it causes: When I publish a file sometimes it takes a while to be transferred. I go away and do something else, expecting the printer to make a start without further intervention. Some time later I come back expecting the print to be under way or even finished, but instead the Message remains on the screen, awaiting my response. So, time is wasted. At the very least, this could be fixed by itself, even if the core of the issue cannot be identified and therefore fixed

How to reproduce The problem does not appear according to a consistent pattern that I have picked. I have tried setting the Printer Type in firmware, which is set to "MK4" by default, but its unclear if this fixes the issue or not. It comes back later anyway.

Expected behavior When I slice a file using Prusa Slicer for the MK4 printer, when it arrives at the printer I expect it to be recognised as compatible consistently 100% of the time, or give up an error message that is helpful to diagnose what action I might take other than ignoring the problem and proceeding with the print. Under current circumstances I know of no actions I could take, and simply repeating the prior actions without making any change, expecting a different result is the definition of stupid. Even if the printer compatibility check is negative, I expect that the message will time out and the print to proceed. The printer might well assume that the user knows what they are doing.

G-code I am aware that a gcide would make identification of this issue much easier. But I am unable to identify a gcode file that exhibits the problem, as its inconsistent and intermittent. I will try to do so going forward, and will update this issue if I find one.

Crash dump file I do not have a crash dump file. The firmware does not appear to crash when this occurs.

Video The particular screen depicting this issue is well known, not requiring a photo or video.

[antimix]

• Did you tried to resend the file to the printer ? There is a known bug on the file transmission that sometime corrupts the file. Check:

1. Try to just resend the file with PrusaSlicer: if the printer accept it, then the first sent was corrupted in the way.
2. For some time, export on the local PC the gcode before sending it to the printer. If you get the error message from the MK4, remove the USB key and compare the file with the copy on the PC. If they are different the bug is related to the transmission error.

[bryn51]

Ok, since posting this report I believe I have identified the source of this error. I have 3 MK4 printers, and have set up a matrix of Physical printer definitions for each possible nozzle size and Input shaping. Some of these date back to before Input shaping was around. I worked with Prusa Support, and was able to find a pattern to appearance of the error messages, and it was identified to be the Custom GCode at the Start of a print, defined in the Printer definition. A random smattering of the different Physical Printer profiles had captured an old version of he Start GCode. When the Physical printer was redefined to have the correct Base profile, and the start gcode reset to default (including Input Shaping), the Error message issue went away.

The real issue here is the the Printer definitions are not deployed a normalised data set, but denormalized, with the number required increasing exponentially with each combination of Nozzle Size, Input shaping (or not). Addition of an MMU3 on one printer adds to this complexity. The implementation of Input shaping in prusa slicer in the start gcode instead of a UI element (checkbox on or off) is at the heart of this issue. It looks like a quick and dirty solution, and given its nature, more effort should have been expended to program the thing in a proper manner. One might hope that upcoming developments will see this improve.

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[bryn51]

What could be done to address this issue:(?) Have Prusa Slicer check the start and end Custom GCode and alert the user if an older version is currently set. This would assist particularly users who work PS using "simple" mode of which custom gcode isn't an available setting. (and they do not have the skills to cope with it anyway.)

[danopernis]

@bryn51 This doesn't seem like a firmware bug. Perhaps this is a feature request for the PrusaSlicer?

[bryn51]

The distinction between bug report and feature request is an artificial construction put forward by developers in split teams wanting to push work onto another team. just a way to kick the can along the road. I was a software developer for over 20 years and I am aware of tricks of this nature. It often happens when new features are released they are defective from the users perspective.

A good case in point is the recent release of "PrusaConnect" integration. Full of bugs, not properly tested but likely never going to get fixed because of such artificial distinctions.

The programmer/team that developed the feature should own any issues found after release. Prusa management of the development process is to blame for the poor quality software we see in this product. It suits the interests of developers not those of users/customers.

[danopernis]

Well, according to your original report this was supposed to be a bug in firmware, without any reproducer nor concrete G-code to investigate. Since then, you have been able to pinpoint that this is actually caused by custom G-code misconfiguration, which is definitely not a firmware bug (MK4 G-code compatibility check is indeed working consistently). Stale bot was about to close the issue, but you commented on it to prevent the automatic closing, demanding ways to address this issue, which I presented. Therefore, I am closing this issue as there is nothing more to be done here.

I understand that you want to prevent such misconfiguration in future and agree with that. Feel free to open feature request in PrusaSlicer describing how you would like this feature to behave.

I am not interested in discussing software methodologies and organization of work with you, especially not in bug reports on github.

[bryn51]

Actually this is NOT a custom gcode issue at all.(Because) I made no changes to the default custom gcode and never do. Just because the label in PS says the gcode block is "custom" that does not mean the user made changes to it. Prusa themselves utilize the custom gcode to implement features such as IS.

The source of the issue appears to have arisen from opening and using an old project file, but the custom gcode inbuilt was different than the current version custom gcode. This would possibly arise because likely I changed the previous printer profile (for a mk3S+) to my current printers (mk4).(I upgraded the printer)

Somehow Prusa Slicer assumed I wanted to keep the custom mk3 gcode, and just flagged it as altered (non default). Since I do not look at custom gcode very often I did not spot this. I found it only because I wondered how IS profile was working without a screen control element to turn it on or off.

So it's still a bug, just different than what I initially reported. Expected behaviour: On loading an existing project file: On selection of a different printer: If a different printer is selected than stored in the 3mf file then PS should prompt the user to ask if the custom code for the old printer should be updated. It does not do that, therefore this qualifies as a bug.