MK3.5/3.9/4 Users - No Support Yet

[jukebox42]

This plugin does not currently support the MK3.5/3.9/4 with an MMU. You can follow the progress here #44.

[BlueFyre]

I noticed that the Tx/Tc seems to have a TODO in the firmware. I imagine Prusa might implement those eventually to be able to have the same single filament profile as the MK3S/MMU3. Aside from that, would your solution for the MK4 be able to leverage M863 - Tool remapping?

[jukebox42]

@BlueFyre oh that's a curious idea. I wonder if I could take advantage of that. I'll do some reading thanks for the tip!

[BlueFyre]

@jukebox42 might be good to support it since you could then recommend people just use the MK4 MMU profile and then do a remapping before the print starts. This seems to be the way Prusa is currently handling single mode since that profile doesn't actually exist yet (and well the commands don't even exist)

I was just chatting with someone who tested the behavior on the non-MMU profile and it seems to load the filament to the nozzle as part of the print select (code for reference) just before actually the execution of the gcode. It does let you do any tool remapping prior to printing too. Though I'm not sure how that would work with Octoprint since the execution might be part of selecting the file instead of execution of the gcode

[jukebox42]

Thinking out loud.

With multi-mode, this would be pretty easy to support. And I wouldn't actually need the M863. I could just pause on a M109 silence the following T# and then replace it with my own T#. That's more or less how it works now just instead of a T# I look for Tx. The problem there being it would always show/replace even when the user didn't want it. I could do some pre-processing of the gcode and check to see if there's more than one tool change and if only one then handle the replace. But I was hoping to avoid having to do any kind of scanning of files since I'd have to do them on load (like Slicer Thumbnails)

For a single print, I bet I could catch the print request from octoprint, silence the request before it hits the print and prompt there for the tool then pass an M863 ahead of the print start. Though the printer would still ask the user (unless that's a setting on the printer?). But that still gets me to the same problem of not knowing if this is a single or a multi print ahead of the print starting.

I might not be able to get around scanning the gcode files to work around this.

@BlueFyre when you do a single print and select the filament from the printer does Octoprint hear about it at all? Do you see any M708 commands?

I'm wondering if the call order is mixed during single print mode. My running plan was to see if injecting a tool change into a single print where it would normally show up in a multi print. Though I'm not sure how the printer would react to it.

[BlueFyre]

Based on what I saw, the firmware is currently parsing out the gcode comments to determine whether or not an extruder is used and then it will let you do the remapping. For example there's this: ; filament used [g] = 15.76, 15.97, 0.00, 0.00, 0.00 when I had 2 objects with extruder 1 and 2 used

As for your single print question, I take it you mean the non-MMU sliced gcode. There's no M708 in the start g-code for it. That's only in the MMU enabled profile. Though I'd expect those things to disappear eventually when Prusa gets around to cleaning it up. Seems to me it should be baked into the firmware

Also just thinking out loud. I think the M863 is a bit more robust than needing to remap commands on the fly. Instead all you need to do is to figure out which extruder(s) the user is allowed to remap and then let them map it to any other one. It decreases your complexity since I think you'd only need to figure out which extruders are allowed to be remapped before the print starts and then send the M863 over (and not worry about the timing of anything else). In this way, you'd also avoid needing to know the timing of when certain gcode is executed (or not). Needs testing though