Aborting a print causes excessive retraction

[illuminarti]

Under 13.12 firmware for UM2... several forum users have reported that when aborting an Ultigcode print, the filament gets rewound to the original E=0 position from the start of the print.

I have tested it myself (with both Mac and Windows format gcode files) and can confirm the behavior.

It seems that for some reason the G92 E%i line in the abort routine is having no effect, although having looked at it quite a bit, I couldn't see why it wouldn't.

[illuminarti]

I think I figured it out... it's a timing bug. (and another reason to maybe go with the separate 'system commands' buffer I mentioned in the other thread.)

The main process_commands routine blocks if a command either calls st_synchronize (because it needs to flush the move buffer out first) or if the planner buffer is full when processing a G0/G1 command.

During that blocking, lcd_update() gets called, to keep the UI ticking along. If during either of those 'pseudo' update cycles the abort command gets triggered, then the command buffer gets wiped from underneath the process_commands code. When the process_commands eventually finishes up, the first thing it does is pop the first command out of the command buffer. Normally this would discard the command that just got processed.

But, IF the command buffer got wiped during the blocking period, then what gets discarded instead is the first command that got written after the buffer was wiped - in the case of the abort, it's the G92 command. That G92 never happens, so the move to E0 rewinds the filament all the way to the start of the print.

Not sure the best way to fix it. Perhaps LCD update needs a 'read-only' mode so that it redraws the display, but doesn't process user input if it isn't being called directly from the main loop(). As previously mentioned, a separate system command buffer might be a good idea... make it big enough so that it filling up is never a likely scenario. I previously suggested that it could operate in various modes - but that may be overkill: have it simply always preempt the USB/SD queue. More generally I think the queue system needs to be re-architected to keep each queue strictly linear, with little or no cross talk between the LCD interface, command queue, and move queue. Things like resetting the coordinates should probably become special types of 'instant' moves, rather than happening outside of the move queue. One oddity I noticed and couldn't immediately explain - a G92 that doesn't feature an E component waits for the move buffer to empty, whereas one that does include an E component takes immediate effect, rather than waiting. Not sure what the implications of that are, but it seems like it has the potential to cause problems...

[daid]

Yeah, the queues are a mess. A quick workaround would be to keep 1 "dummy" command in the buffer on clearing. This would limit the amount of commands to BUFSIZE-1 which would be 3 right now. So I'm increasing the BUFSIZE to 8 for SecretMarlin, as the abort code wants 4 commands.

Something else that is bugging me is the large amount of memory the queue uses. 96 bytes for each line. Sure, some lines could be that long, but they usually are not.