Feature: fine grained error messages available to printer display

[rdpeake]

I'm not sure if this is a MMU issue alone, but most of the time when i run into issues the MMU will signal that there was an error during load, or it will load it to the printer, and then it will unload it a few seconds later with no obvious reason as to why not.

It would be nice if the MMU would store a fine grained error 'push to printer failed, timeout', or that sort of thing which can then be fed to the printers 'MMU needs attention' and displayed to the user - and updated as the user attempts to manually resolve issues. If the MMU board has a flash chip, it may be worth adding in language packs to the MMU and a set language option to make this even easier to use for the end user.

The more information available to the end user when a fault occurs means the more they can do to correct the issue to not have to solve it again (especially when things look like they are working only to unload moments later)

[chriswal]

the mmu2 has only a small set of error detection.
1 the driver got reset / power failure / overheating
2 after pushing forward there is no change in the finda (i dont even know if that is detected as an error)
all other errors are coming from the printer.

these unloads happens on my printer when it tries to detect if the loading to the nozzle works (the filament gets grabbed and pushed forward by the printer gears a defined length / if there are skipped steps it unloads and repeats the process) on my printer sometimes it happens also that it thinks it got loaded because the detection worked, but then it got stuck and doesnt extrude.

I think the best place to ask for this is the issues page for the printer firmware.

[rdpeake]

One of my more recent errors was it would push very short into the ptfe tube, and then unload, and repeat that a few times before signalling an error - that certainly is not an error on the printer, nor is it 1 of 'reset, power failure, or overheating' though there was a reason i indicated that 'more fine grained' errors should be added such that it can indicate that it was a certain set of unload errors - as if the printer doesn't signal that the filament entered, the printer also cannot know that this is why the mmu failed to load unless it tells it.

[chriswal]

in this case the error is on the mmu2 (but not detected on the mmu2) but the error you see on the mmu2 (led blinking) is sent from the printer (wait for button). as in this case the printer knows that it started a load but couldnt see its own sensor changing before timeout.

[chriswal]

sorry i know that it should not matter if you put it into the MMU2 issues. There is such a lot of MMU2 error handling missing in the Printer firmware. i tried to send something from octoprint and the printer tried to load the filament to the nozzle even if it wasnt heated ...and it dindnt stop.. it was grinding all throug the filament ..if you reset the printer it resumed loading.. i had to turn off the printer to stop this behaviour.

[rdpeake]

Looking at the code - the errors of the filament loading are not sent by the printer, though the printer also has the option of sending a 'wait' command. When the filament is not loaded however the mmu is in a do while loop for the user to push the right button to continue and nothing is sent to the printer at all (nor is the state changed so the printer can't even get this information)

As it stands the only way that the printer can get information from the MMU is via an s3, for driver error count, or for it to read the pinda. otherwise i believe it makes assumptions based on not getting OK's in a timely manor and the interface offers no other ways to get what the error state of the mmu is in - outside of the flashing lights we can see.

Also your issue with the filament loading on reset i believe is a 'feature' i assume it is to aid with loss of power to ensure the printer is back in the intended state - but it should work more in conjunction with the printer to prevent such issues.

[chriswal]

yes you are right its a feature ..but this feature repeats the not handled error ;-)
yes if you look at the code the mmu doesnt send anything to the printer because it doesnt detect an error ..when the printer detects the error it sends a wait ... the you have to press the middle button for a check on the mmu ..this checks if the filament is not loaded/loaded ....finda is off (if not it pulls back) --moves filament to finda /finda on ... pulls filament back to loaded position....
then press the right button to change the state to idle and send the ok to the printer for ending the wait.

[rdpeake]

If you look at mmctl and the load filament functions - there are busy wait loops in there signaling the filament errors waiting for the user to press enter, or the right button to proceed which happens without the printer sending any waits to the mmu. SO this is a different state to the printer sending a wait error to the mmu and setting the wait state.

[chriswal]

the mmu2 has only a small set of error detection.
1 the driver got reset / power failure / overheating
2 after pushing forward there is no change in the finda (i dont even know if that is detected as an error)
all other errors are coming from the printer.

thats what i meant with point 2 ... i was not sure if they use it ...so yes they use it ....so your finda could be wrong

[chriswal]

so on point 1 all Leds are blinking
only point 2 and the wait from the printer show the same status (perhaps they should show the wait from the printer with a different led?)

[rdpeake]

There is only so much clarity blinking leds give - the printer has a screen they should use it in conjunction with the LED's so that the leds work if the printer is not able to.

That way they could give more concise errors on top of the 'error loading filament' blinking, or 'wait for ok' blinking etc.
at the moment through - the code only knows the error, because it is in a loop, and the printer has no way of asking for the error, even if it did have a means tracking it. plus the error is currently happening in the main loop, so the printer wouldn't even respond to requests anyway as it stands, which is why the printer shows N/A when you are doing filament loads

[chriswal]

thats some easy fixes on the mmu side but not so easy on the printer.
on the mmu you can send after a reset if and which filament is loaded. its already stored in the eeprom (but not deleted after unload)
and in the loop where they check for an error you send an error code to the printer , and ok when the error is resolved.
on the printer you have to handle all failure possibilities.

[chriswal]

but you are right there should be more information on the printer display....
i only know it because i did some code bugfixing in my mmu

[rdpeake]

sure you can send an 'error' response to the printer but the fact that the MMU is basically non responsive (to serial) due to it hanging in a loop and not using any interupt routines, or timeshare like systems to allow it to service commands doesn't really allow for much better usability (like those that want realtime sensor updates of the mmu whilst doing loads)

More information is key to better usability. most people complain because 'it just isn't working and i don't know why' or 'it always needs user interaction to do loads it's so bad'

[chriswal]

what is the benefit of real time sensor updates in a error condition ? ..
you already have a led on your sensor.
i would prefer fixes on the hardware ...like the problems with the mainboard (5V) and the latches for the LEDs Motors.
the best improvement would be some tip forming hardware.. you could do that in the selector.
because with the hotend you get troubles ..it has to fit into a non elastic heatbreak with the same size (not anymore because the heatbreak is a little bit larger now) as the nozzle.. and the tip tends to change the width when it cools ..and then also over time..
so it woudld be great to make the tip smaller and also remove the strings in a seperate hardware ...then the most problems would go away ..
except software errors on the printer
so for now it works that way ...you have a smaller teflon pipe (1.9mm)in the heatbreak... and the heatbreak is a little bit wider (2.1-2.2mm) i dont remember and a 2mm nozzle. its formed in the nozzle and the pulled out through the smaller teflon pipe.
when loaded you can hear sometimes how its crushed through the heatbreak. mostly it work but sometimes it gets stuck. but this leads to other errors..some people returned to the previous configuration where the heatbreak and the pipe has the same size.
yeah and then an endswitch to the idler.

[rdpeake]

The live update is another suggestion here.

I'm guessing you're implying the existing filament cutting isn't sufficient for tip forming?

And the idler is using the same stepper drivers as the main board - why does it need an end switch when it can detect motor stall of the idler not spinning? Or have you had issues of the idler getting caught when not at the end?

[rdpeake]

Also, so far as I understand - if the printer were to reset whilst the menu was performing an operation, or waiting for user to correct load - it wouldn't get a response on uart and would go into MMU not present mode

[chriswal]

The filament cutter is good but then you have to cut it every time you change ..and 5mm 300x or more (only guessing) is 1,5m filament x5 = 7,5 m if you say thats ok ...but i dont think it will fit to the waste tray. so we need something more resource friendlier.
the driver can only detect a motor stall with a higher speed ..this is not possible with the idler ..where you think this loud homing is coming from. only rattling against the wall.
i tried this with the error in the menu .... the mmu2 got reset when reset the printer.
but when trying to provoke an error ...i found some problems ;-)

[chriswal]

https://youtu.be/pV_1MMs1W3E
here you can see the homing sequence with an endstop on the idler ..and the fixed selector homing