Closed Kevman323 closed 9 months ago
BTW, some of the codes I added use the same pulley/selector/idler bitmasks, mainly the Homing Failed and Move Failed errors, like E8087, but it looks like these errors always output with exactly the one bit changed, so you can hardcode those errors.
Hey @Kevman323, sorry I haven't had a chance to look at this pr yet. Was planning to this weekend. Any reason you closed it other than my lack of reply? If not I can duplicate your work ina branch I've been working on and hopefully get that released soon since this one was closed
Sorry, I was going to message here and explain. I'm currently preparing a different, rather large PR that adds progress messages to the navbar, and adds missing MMU states like Cutting, Ejecting, and Preloading. It contains the same changes as here, so this won't be needed.
Also I was misunderstanding how Sourcetree created PRs, and accidentally shoved the changes into my main branch. Deleting and recreating it auto-closed this request before I had a chance to do it myself!
I added some of the missing error codes.
I was going to add the TMC error codes, but it's a bit more complicated than I thought, and I'm not sure the best way to implement them. The best way to think about them is to convert them from hex to bits.
Each TMC value listed in https://github.com/prusa3d/Prusa-Firmware/blob/4c531630686b4918ae442a27dce67c01f351c757/Firmware/mmu2/error_codes.h is actually a bitmask used in conjunction with the Pulley, Selector, and Idler bitmasks. For example:
0xA000 = 1010000000000000 = Over Temperature Warn bitmask
0x0080 = 0000000010000000 = Selector bitmask
And so0xA080 = 1010000010000000 = Selector TMC Driver Over Temperature Warn, AKA Prusa error code 04211
An actual TMC driver error I have a log of is:0x8500 = 1000010100000000 = Idler TMC Driver Reset, AKA Prusa error code 04322
It gets complicated though, since I guess multiple TMC errors can happen at the same time, so theoretically you could get:
0x8D80 = 1000110110000000 = The selector and Idler TMC Drivers had an issue, where one was a Reset Error, and one was a Undervoltage on Charge Pump Error
, I think, it's pretty much impossible to test this stuff The actual firmware as shown in https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/mmu2_error_converter.cpp actually just reports whichever case it finds first, in order of decreasing severity.I'm not sure the best way to track this, maybe when a Exxxx error is found, convert the hex numbers to an int, then use the same bitmask method the firmware uses? In any case, the base errors like EA000 shouldn't ever show up in the serial log, since there would be a bit for selector/pulley/idler along with it.