OllisGit / OctoPrint-SpoolManager

Plugin for managing Spools
169 stars 57 forks source link

Filament usage not calculated correctly when printing from other than tool0 #274

Closed Graylag-PD closed 2 years ago

Graylag-PD commented 2 years ago

I am not 100% sure this is SM's fault, but I consider it most likely culprit. TLDR version: When printing object with Tool1, SpoolManager gets confused as it measures consumed filament as if it were printed with T0. But as there is no spool assigned to T0, it states correctly consumed lenght, but then it says 0 g of filament was used and does not update spool database correctly. See following cutouts from Print Job History: image image

github-actions[bot] commented 2 years ago

This issue has been automatically marked for closing, because it has not had activity in 30 days. It will be closed if no further activity occurs in 10 days.

Graylag-PD commented 2 years ago

Still an issue (obviously). I do have an idea, that it might be related to fact, that I always close my gcodes with T0 command - this is related to automated filament swaps in firmware and is intended to restore printer to known default state. But this may confuse SpoolManager as gcode both starts and ends with T0. I will prepare modified GCode file without this and try if it persists.

Graylag-PD commented 2 years ago

I did some more investigation and it gets weirder.

First I tried to remove T0 from start and end of my T1 print - result was exactly same as before. Then I tried to run the bare minimum of code that still gets processed and that looks like this:

T0
G1 X10.0 Y10.0 E100.0 F1500.0
G92 E0
M104 S0

Result is weird. This is what T0 variant produces image

But this is what T1 variant produces image

This bare minimum code of course does nothing as any action is prevented due to cold extrusion, so here is modified code and its results

G28
M109 S180
T0
G1 X10.0 Y10.0 E100.0 F1500.0
G92 E0
M104 S0

image image

I don't get what is going on

Graylag-PD commented 2 years ago

Another test, here is modified minimum code:

T0
M104 S0
G1 X10.0 Y10.0 E100.0 F1500.0
G92 E0
M104 S0

This produces results that correspond to normal printing: image image

Obviously this code still does not do anything due to cold extrusion prevention, but it makes sense, that octoprint does not care about that. Instead it apparently cares abot that M104 at the begining. Not sure why.

Then I tried to shift that M104 in front of T0/1 and for T0 variant it obviously made no change. But this is what it did to T1 variant image This stayed even after I added T1 to M104

M104 S0 T1
T1
G1 X10.0 Y10.0 E100.0 F1500.0
G92 E0
M104 S0

So, it seems that something is overwritting which extruder is active based on M104, but ignores that M104 without T parameter is setting temperature to active hotend, not default (T0). Although better question should be why is it even looking at M104, when T0/1 is all it should care about

Graylag-PD commented 2 years ago

I have been experimenting some more and sometimes the results seem to be random or pseudo-random. Sometimes same code produces invalid result on first run but valid on following runs, sometimes its completely oposite. I have no idea what is going on.

github-actions[bot] commented 2 years ago

This issue has been automatically marked for closing, because it has not had activity in 30 days. It will be closed if no further activity occurs in 10 days.

github-actions[bot] commented 2 years ago

This issue was closed, because it has been already marked for 10 days with no activity.