Feature Request: UI Print Timeline Rewind/Advance feature

[raspeitia]

In case of print issues, it would be nice to have an option on the printer menu screen after you PAUSE a print, to scroll back (and forward) through the print head movements ONLY, until you reached the point you want, then accept and the print resumes ALL GCode from that point on.

The thought is, that menu allows you to enter a "timeline" mode that lets you use the scroll wheel to dial back and forward through the gcode, using only the X, Y, and Z operations for visual reference, till your nozzle is where you want it.

Then you have the choice to accept the timeline position as the new current position or you can revert.

Upon resuming the print, if you accepted the new timeline position, that is where the gcode will begin again.

Background: I was printing a part and the nozzle clogged. I paused the print and unloaded and reloaded the filament and all was well. Unfortunately I lost a little of the layer that I was printing by the time I paused the print. I was able to clear the clog and resume the print with the gap in the layer only causing visual and not structural issues.

Thoughts?

[workinghard]

Sounds like a great feature. But this would require a pretty big enhancement to the firmware which is already at the space limit. The gcode interpreter would need to work in reverse and it can only work if the printer can access the whole print file (SD) because it need to analyze the history.

[raspeitia]

Would it be possible to only read small chunks or individual lines (like a file stream) of the gcode file in reverse order and skip commands that are not X, Y, or Z movements?

This way you would only need to load or process single movement commands at a time without having to do much analysis.

Yeah, I wondered how much memory is left in the firmware for adding additional menu options. Just throwing it out there if its possible somehow.

[workinghard]

Of course you will process single movement line by line. But it can be 1000 lines for a small 1cm circle or 4 lines for a square of the whole size bed. Anyway, reading from SD is not a big deal. This feature could be limited to SD card only. The problem is that you can't use the current gcode processing code for this feature and you need to write a complete new one. That's a pretty big effort in terms of development and also the hardware resources at the end. But I still like the idea :)

[raspeitia]

Makes sense that there are other considerations from the gcode processor that need to be taken into account.

If you or someone else decides to look into implementing something similar let me know.

I have not done C++ in many years, but I know programming in general, like C#, and can see what I can help with. Thanks.

[leptun]

@workinghard well it would be great if slicers implemented G2/G3 commands, having a circle in one line. But untill we stop using stl and switch to somerhing such as STEP it will be quite impossible.

If this doesn’t happen, then the only sollution I see is having the firmware skip short lines when scrolling through the gcode.

[raspeitia]

I was thinking if we could base the scroll wheel movements (left/right increments) on a logarithmic scale based a time interval between steps?

Basically the shorter the time interval between one wheel click to the next determines how many steps of gcode to process/skip over.

The scale could start at 0, meaning the slowest scroll wheel movements skip zero gcode lines, essentially processing each line. As the time interval between wheel steps gets shorter it falls higher on the scale, thus skipping more gcode lines.

I don't think you would need to poll a timer for this, just simply compare a stored timestamp between one wheel click to the next.

Is something like this possible?

[GWdd]

I struggle to see the value in being able to step backwards in a file. If you ran out of filament and the printer ran for some time, how can you find the spot the filament flow stopped in the file? I doubt I could count the number of layers below the nozzle to where the build stopped. One could add a Z move function to lower to a specific point - maybe where it touches plastic, and guess if it's the right layer. Have the code search for the layer change based on nozzle height. But guessing where in that layer filament stopped ... wow ... have you ever watched the nozzle jump around when printing a layer? There is no rhyme nor reason to position. It'll print left side one layer and print right side the next. And then the next time it'll start somewhere near the middle.

Then there's the more important issue of a user knowing where they are at in the file. It isn't like people read gcode and even if the display had the actual gcode as you stepped through (mind you, the LCD update rate is not conducive to fast text updates) finding a line with a move G1 X220 Y330 E0.23 how would a user know it's the one move they are searching for; nor would they have any sense of layer until they found the line that showed the layer jump. But then you'd also want acceleration accounted for, and would need to restore that value to the sequence.

Another thing, polling the wheel is simple, but nearly any timer you choose will work for one person, but not the next. People are just too different. Look at all the issues with mouse acceleration in desktop computers. People would be complaining of stepping too far, then trying to get back but unable to because they went too far again. Users would be lost in no time.

For the amount of effort to code something that might work, and only in a very specific situation/use case, I'd rather see people get layer one cal working reliably and repeatably between different steel sheets.

As for one gcode line circles... now many times do users print perfect circles? I printed a test pad that was circular ... I can't think of anything else. And infill and much of the other "work" around the circle test pad was linear. Not to mention the slicer would need to determine whatever it was slicing was actually circular before using the circle command.

[raspeitia]

I had not thought of that. Thats actually a good idea.

Would it be possible to add to the feature request, that aside from using the nozzle as a visual position reference, that the LCD would also show the line number of the gcode its on and maybe a small snippet of the actual code? Nothing too intensive (don't need it to scroll or anything).

If the LCD refresh is an issue as mentioned, maybe limiting the LCD update of this gcode line info only for scroll wheel movements that are slow enough (like in the scrolling skip option mentioned previously).

This might be of use to more advanced users that know what gcode line they want to dial back to.

[GWdd]

Have you ever looked at a typical gcode file?

I have a gcode file I am printing right now. It is 1,487,227 lines long. Now which line do you want to jump to? Oh, 453,298: G1 X149.130 Y90.811 E0.00867

Ok - so exactly what was that line printing?

Here's a few lines before and after to give you a hint:

M204 S1250 G1 F9211.97 G1 X145.296 Y89.135 E0.01961 G1 X145.408 Y89.179 E0.00488 G1 X145.630 Y89.382 E0.01225 G1 X145.513 Y89.609 E0.01038 G1 X145.368 Y89.754 E0.00831 M204 S1000 G1 X145.826 Y89.669 F10800.000 G1 F2400 G1 X146.289 Y89.870 E0.00346 G1 X146.286 Y89.879 F10800.000 G1 F2400 G1 X145.837 Y89.647 E0.00636 G1 F8640 G1 X146.286 Y89.879 E-0.11664 G1 E-0.68336 F2100.00000 G1 Z12.600 F10800.000 G1 X148.664 Y90.608 G1 Z12.000 G1 E0.80000 F2100.00000 G1 F2400 G1 X149.130 Y90.811 E0.00867 G1 X149.193 Y91.013 E0.00362 G1 X150.136 Y90.868 F10800.000 M204 S1250 G1 F9565.41 G1 X149.730 Y91.274 E0.02247 G1 X150.119 Y91.550 E0.01867 G1 X150.378 Y91.291 E0.01432 G1 X150.733 Y91.601 E0.01844 G1 X150.411 Y91.923 E0.01784 M204 S1000 G1 F8640 G1 X150.733 Y91.601 E-0.10533 G1 X150.378 Y91.291 E-0.10887 G1 X150.119 Y91.550 E-0.08454 G1 X149.730 Y91.274 E-0.11019 G1 X150.136 Y90.868 E-0.13263 G1 E-0.25843 F2100.00000 G1 Z12.600 F10800.000 G1 X155.840 Y91.340 G1 Z12.000 G1 E0.80000 F2100.00000 M204 S1250 G1 F9747.12 G1 X156.520 Y90.659 E0.03693 On a 4 line display ... sure, that will help.

I'm a semi-advanced user and I can't see any situation where I'd want the ability to dial in a specific line. To me, it's a senseless notion to think anyone can understand a gcode file in any tangible and useful print recovery way. I can't even think of an instance where restarting a print at a specific layer would have been useful: and if it had I could edit the gcode file directly and do what I wanted that way far easier than using a single button 4 line UI.

[raspeitia]

Maybe you are printing a clue stick. Doesn't really matter.

The only constructive and relevant information in all of the above blathering is that you are looking for line 453,298, and that is what you would dial back to. Pretty simple.

Your obtuse comments have been noted for everyone to read, but there's obviously nothing else for you to see or contribute to in this thread. Move along.

[GWdd]

LMAO - sorry, but you don't seem to get it. I randomly picked a spot AS-IF I knew where to go to demonstrate just how pointless and non-functional the idea really is.

My secondary point was to ask how on earth could/would you know the line you want to navigate to? Is there some secret knowledge you have that I don't have that allows you to pinpoint the exact line in the gcode where the printer jammed?

Beyond the fact the notion is rather silly, why ask software guys to code something that may well be a man year of effort for something no one can possibly use, and especially when the task is more easily performed using a commonly available text editor? Just as well ask them to do transmutation while they are at it.

[Pathogenius]

"I'm a semi-advanced user and I can't see any situation where I'd want the ability to dial in a specific line. To me, it's a senseless notion to think anyone can understand a gcode file in any tangible and useful print recovery way."

What would be done is, rather than some sort of alchemy involving reading raw gcode, the user would simply use the 3D software to identify the coordinate of the required edit. Short work, literally 3D 101.

In any case the instances I have wishes to be able to 'go backwards' were due to print anomalies caused by the limitation in the print technology, and also doing multi-color tweaks without using an MMU. I like the idea, but unfortunately software engineering remains a grossly closed system despite sincere efforts to work in the open source domain, mostly because machines are complete idiots and have to have every little thing perfectly spelled out for them, and so I suspect we as end users have some time to wait yet for such flexibility as suggested in this very forward thinking idea, pun intended.

[workinghard]

No need to get personal here. Everybody can post any feature request. Maybe someone get inspired by this idea and will implement something similar. It's open source and it can be done by official PR employees but also by anyone else in the world. So please stay constructive.

"Going back" feature can be also for the user just scrolling the wheel and the printer will do the move backwards (without extruding). The steps can be defined as head move/mm. It is possible to implement user friendly. Again: I like the idea and yes I'm fully aware of the huge effort of this request what I actually pointed out already in my first post.

[GWdd]

Pathos - this entire request is presuming someone can "know" the physical location of where to restart a print, and that then the gcode created follows some sort of rule based routing to get to that point, which it did when creating the file, once. The concept also presumes the printer can recalibrate to within a sub-millimeter precision after cooling and reheating, which is questionable.

But for a user to select a line - more or less at random - the result is chaos. There are dozens of precursor commands required to prepare the printer to do a specific move with extrude. The code would need to look back and make arbitrary choices on which of those preparatory precursor commands were necessary. In some cases there may be thousands of lines of code to search through to actually know what state the printer was in before it could do the move as if it was never interrupted.

And I challenge anyone to take a model, choose a point on it, and accurately match that spot in their gcode. especially a point that happens to be mid move, like infill.

As for software being a closed system. It's not closed at all, and this isn't about keeping secret sauce secret; rather, it's about expectation. If you request a feature, have a well defined use case and details of how it should be implemented. The code is open source, and anyone can go in and capture the current build, and make changes on their own. If in your eyes this is such a simple task, go for it. People have implemented 7x7 point bed leveling and posted firmware that does it -- no reason people can't try to implement this themselves, either. All it takes is a bit of time, knowledge, and some effort. Learn C, or C#, or C++, or whatever the code is written in, learn the development tools, what libraries are, what make does, etc. Then download the tools (most can be had for free), and code the exact changes you want.

In any event, the concept is simple, but it appears no one making the request has even considered what would be required to actually implement the 'feature' in a useful way. So to those that believe this is a no brainer, I suggest you take an editor, open up the gcode file you want to revert a line or two back in, to, find your desired point, trim the file to it, then send that file to your printer to see what happens.

After all, all you are doing is moving back a few lines, right?

[github-actions[bot]]

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

[github-actions[bot]]

This issue has been closed due to lack of recent activity.