MMU2 and Octoprint  

Re: MMU2 and Octoprint

Been running perfectly for well over a month.

Peter

Re: MMU2 and Octoprint

via usb pie3? im guessing

Re: MMU2 and Octoprint

via usb pie3? im guessing

Using a Pi2+ - same Pi I have been using for a couple of years.

Peter

Re: MMU2 and Octoprint

Been running perfectly for well over a month.

Peter

Nice!

Anything special I need to do or is it exactly the same as before the MMU?

Re: MMU2 and Octoprint

Well, there's a few "tweaks" I made with comms timeouts, simulate [ok] and long-running commands, along with G-code script "After a job is cancelled".

Otherwise, just standard stuff (but I was running with MMU1 previously, so some changes for MMU required).

Peter

Re: MMU2 and Octoprint

My Octopi (USB RP3) always sticks to filament 2 when trying to print things directly in octoprint, color changing doesn't work. But its fine connecting and then printing off the SD via the printer.

Re: MMU2 and Octoprint

My Octopi (USB RP3) always sticks to filament 2 when trying to print things directly in octoprint, color changing doesn't work. But its fine connecting and then printing off the SD via the printer.

Is that because you slice with Slic3r and you have a T? to select the tool?

Peter

Re: MMU2 and Octoprint

Well, there's a few "tweaks" I made with comms timeouts, simulate [ok] and long-running commands, along with G-code script "After a job is cancelled".

Otherwise, just standard stuff (but I was running with MMU1 previously, so some changes for MMU required).

Peter

Peter,

Would you mind posting up your after job gcode script?

What do you mean by "long-running commands?"

Thanks

Re: MMU2 and Octoprint

My Octopi (USB RP3) always sticks to filament 2 when trying to print things directly in octoprint, color changing doesn't work. But its fine connecting and then printing off the SD via the printer.

Is that because you slice with Slic3r and you have a T? to select the tool?

Peter

Not sure what you mean by 'T? to select the tool?' I do slice in Slic3r and set the extruder numbers as expected and the gcode output works fine when printing off the SD card but not directly from Octoprint. Octoprint will automatically switch to filament 2 when starting the print and stay on that one. Chris W on Facebook said this is because octoprint does not recognize the extruder changing commands yet.

Re: MMU2 and Octoprint

Not sure what you mean by 'T? to select the tool?'

G-code Tool selection is carried out using the T command - T0, T1, T2 etc.

For single filament prints, Slic3r can include T? as a tool selection command and this is where the printer will ask you which extruder to use. I believe that this causes issues with OctoPrint, but works fine when printing via SD card.

You can see it in "Original Prusa i3 MK3 MMU2 Single" Printer Settings/Custom G-code/Start G-code section:

...
;go outside print area
G1 Y-3.0 F1000.0
G1 Z0.4 F1000.0
; select extruder
T?
; purge line
...

At one time, it was ignoring the extruder selection made in the Model/Settings window and in the Print Settings/Multiple Extruders/Extruders group - I don't know if that is still the case.

Peter

Re: MMU2 and Octoprint

Peter,

Would you mind posting up your after job gcode script?

What do you mean by "long-running commands?"

Thanks

After a Print Job is cancelled:

G91
G1 Z5 F300
G90
G1 X125 Y210 F4800 ; move bed for easy removal
G4 S1 ; pause 1 second
M107 ; turn off fan
M104 S0 ; turn off temperature
M140 S0 ; turn off heatbed
M84 ; disable motors


Note that this does not attempt to unload the filament. I find it easier to unload manually (turn on temp and press the "Unload" on printer menu), but my favoured option is to remove the next filament to load, wait for a failed load and then cancel.

If you wanted to include unloading then the G-code would be something like this:

G1 E5 F150
G1 E-15 F<UNLOAD_FEED_1> ; Initial retract to get filament out without stringing
G1 E-10 F<UNLOAD_FEED_2> ; retract filament in PTFE tube ( stages)
G1 E-10 F<UNLOAD_FEED_3>
G1 E-10 F<UNLOAD_FEED_4>
G1 E-10 F<UNLOAD_FEED_5>
G1 E-10 F2000
G1 E-30 F2000 ; Remove filament to above drive pulley
M702 C ; Unload filament


But in this case, the <UNLOAD_FEED_n> values would need to be mainly filament-dependant.

Long-running commands. The "Busy" protocol has now been implemented in the PR firmware so this many not be necessary.

OctoPrint Settings/Serial Connection/Firmware & protocol/Protocol fine tuning/Advanced options/Long running commands.

Mine are currently set to: G4, G28, G29, G30, G32, M400, M226, M600, G80

Peter

Re: MMU2 and Octoprint

Not sure what you mean by 'T? to select the tool?'

G-code Tool selection is carried out using the T command - T0, T1, T2 etc.
...trimmed...
You can see it in "Original Prusa i3 MK3 MMU2 Single" Printer Settings/Custom G-code/Start G-code section:

...
;go outside print area
G1 Y-3.0 F1000.0
G1 Z0.4 F1000.0
; select extruder
T?
; purge line
...

You can see it there, and you can also change it there. If you change the T? to T0 in the custom G-code of Slic3r you can send straight to octoprint and have filament 1 used or, presumably, any other filament by using the appropriate T number. I've only tried T0 so far.

Rocco

Re: MMU2 and Octoprint

If you change the T? to T0 in the custom G-code of Slic3r you can send straight to octoprint and have filament 1 used or, presumably, any other filament by using the appropriate T number.

That is correct. T0 through T4 equate to Filaments 1 through 5.

Peter

Re: MMU2 and Octoprint

That is correct. T0 through T4 equate to Filaments 1 through 5.

Well...not all the time, I discussed this in the Octoprint Forum: here: https://discourse.octoprint.org/t/prusa-mmu-t-not-working-via-octoprint/4726/47

The behavior when printing through the serial bus shows intermittent faults in firmware 3.4.2 (V1.0.2). At first I thought this was due to T? and I modified the firmware of the MK3 to interpret T9 and act as-if T? was sent. Where this worked initially, the problem then reoccurred. It (sometimes) behaves after sending _the first_ T0 by changing filament 1>2. Subsequent T0 s then load filament 1, as intended.

I solved it for now by adding _an additional_ T0 before the actual T command you need (like T? or T0, T1, T2, T3 or T4). In addition to that load filament in both position 1 and position 2, as sometimes it will load one, sometimes the other but (without actually using it) the _next_ and intended T command will be processed OK.

See for more info the other forum, I also updated the PRusa firmware guys in the incident that I filed on the T? topic (in the slic3r incidents, as I though initially it was not OK to send T? where the printer did not know how to process it).

See for more info the link I mentioned, from which you also find a link towards the Prusa incident.

Re: MMU2 and Octoprint

That is correct. T0 through T4 equate to Filaments 1 through 5.

Well...not all the time, I discussed this in the Octoprint Forum: here: https://discourse.octoprint.org/t/prusa-mmu-t-not-working-via-octoprint/4726/47

The behavior when printing through the serial bus shows intermittent faults in firmware 3.4.2 (V1.0.2). At first I thought this was due to T? and I modified the firmware of the MK3 to interpret T9 and act as-if T? was sent. Where this worked initially, the problem then reoccurred. It (sometimes) behaves after sending _the first_ T0 by changing filament 1>2. Subsequent T0 s then load filament 1, as intended.

I solved it for now by adding _an additional_ T0 before the actual T command you need (like T? or T0, T1, T2, T3 or T4). In addition to that load filament in both position 1 and position 2, as sometimes it will load one, sometimes the other but (without actually using it) the _next_ and intended T command will be processed OK.

See for more info the other forum, I also updated the PRusa firmware guys in the incident that I filed on the T? topic (in the slic3r incidents, as I though initially it was not OK to send T? where the printer did not know how to process it).

See for more info the link I mentioned, from which you also find a link towards the Prusa incident.

Well, haveing been printing with MMU2 via Octoprint, I can honestly say that I have never seen this problem.

However, it has just reminded me of an old fault in the firmware whereby the code caused the pointer to be changed and it read the tool number from the wrong line of G-code.

This was resolved by placing a "G4 S0" immediately before the tool change line, which caused the buffers to flush before the tool change.

You may want to try this to see if it helps.

Peter

Re: MMU2 and Octoprint

This was resolved by placing a "G4 S0" immediately before the tool change line, which caused the buffers to flush before the tool change.

Hi Peter, possibly this is another work-around for the problematic behavior. I can see, when there is a problem in pointing to the correct T-whatever command, flushing the buffer is helpful. Note that neither my GCODE initial print statements, not the print statements posted by "zcubed" had the G4 S0 before the T?.This is because the default profile provided by Prusa, did not include it.

So, from our joint experience there are then two work-arounds, where G4 S0 is nicer, as you do not have to load filament that you do intend not use.

Ruud

Re: MMU2 and Octoprint

So, from our joint experience there are then two work-arounds, where G4 S0 is nicer, as you do not have to load filament that you do intend not use.

As long as the "G4" works. This is not something that I have had to use with the later firmware releases.

There is now an st_synchronize() at the start of a tool change which should clear the buffer:


...
else if(code_seen('T'))
{
int index;
st_synchronize();
for (index = 1; *(strchr_pointer + index) == ' ' || *(strchr_pointer + index) == '\t'; index++);
...


... 5 minutes later...

OK, so I just checked my fault report of 14th March last:

I believe that I may have just found a firmware fault which affects tool changes. Note that this is with the Mk2 + MMU via OctoPrint (OctoPi).

Background

I was trying to print a model using E2 and sliced with KISS. This sets T1 in the start G-Code and then issues a tool change (to T1) at the start of the main code.

What was happening

The printer was printing the priming line as expected and then changing to E1 (T0) to print the model. The filament from E2 remained loaded.

What I did

I inserted some diagnostic lines into marlin_main.cpp – about line 5835 – in the section starting:

else if(code_seen(‘T’))

Diagnostic results

The output demonstrated that the tool was being set to 92, but was then defaulting to T0. The CMDBUFFER_CURRENT_STRING contained line number 33 and the command T1 – both correct BUT strchr_pointer was pointing to a future command (in fact a G92 which was the next line).

Fault

The second line after code_seen(‘T’) is

st_synchronize()

which calls

manage_inactivity()

which calls

get_command()

which can change the value of

strchr_pointer

Possible Fix?

Store the value of strchr_pointer and restore it immediately after the call to st_synchronize()

When I queried this, I was told that the fix was st-synchronize(), however it may be that the fix was not properly implemented; my fix (above) worked perfectly for me.

Peter

Re: MMU2 and Octoprint

I'm running MMU2 and Octoprint. I'm trying to add "eject" commands to cancel at least.

It seems like when Octoprint connects, the MMU2 is reset. If it is and there's a filament in, it gets very sad (red blink). This seems to me a bug in the MK3 firmware... (And the MMU2 firmware. It should save state in the EEPROM on reset/power down, so it can handle a power loss.)