[WIP] Gcode scrolling / stepping / skipping

[duk3luk3]

I am using Printrun to control a DIY embroidery machine.

Stepping / skipping through an embroidery file is a standard feature on embroidery machines, and also on most CNC systems.

I have created a quick and dirty implementation of this, that allows to do the following (in pronsole only for now):

• line command that shows the next G-Code line to be sent and surrounding lines
• start pause command that starts the print in paused state
• skip command that allows to skip lines forward / backward in the G-Code file
• next command that exposes send_next to send a single line of G-Code from the G-Code file
• Resume without restore so that the print can be resumed directly as previewed by line

This is currently very messy and a clean implementation would have to involve "pulling apart" and making the state machine of a print being live / paused a little more complex.

Please let me know if this is something you'd like to add to Printrun and I can spend time to clean it up.

[DivingDuck]

Some thoughts...

This is an interesting idea @duk3luk3 and I think the use case can be a nice add-on for Pronterface. I had seen some of those DIY embroidery machines during the last decade.

Regarding an implementation we should think about how this can be implemented and tested. I guess there are not a lot users around for this use case for now, but this can change and we should no one stop realizing new ideas.

Looking to what you want to implement I think there need to be something like a special setup for embroidery that then can handle all special requirements that differ from Pronterface/Pronsole normal use case. E.g we should not have a general activated monitor function as it ask for trouble in 3D printing, CNC or laser cutting. It can generate a lot of traffic and load for a microprocessor and you don't really want that in our main use case. Actual monitoring asks for other information and behavior as it is needed for embroidery. Something like an additional setup feature like "Embroidery" and if activated do what ever you need to do different to a normal behavior in Pronterface/Pronsole.

I guess it is for anyone a bit early to decide if this is something to implement in the main branch at this early stage. Maybe it is worth to add a separate branch for this and look where we will end with this idea.

Any thoughts, @rockstorm101, @kliment ?

[rockstorm101]

Hi @duk3luk3 thanks for contributing, I love the idea of extending Printrun to control an embroidery machine. I understand this PR is a sort of proof of concept or demonstrator of what would be needed for such a support. Which I understand would consist "only" of the stepping/skipping feature. Which in turn sounds like a feature that would benefit any CNC really. So I'd be happy to add such feature.

Looking at this PR my first thoughts are:

1. I feel like changes to printrun/printcore.py should be kept to a bare minimum. In my mind this "library" should only be tasked with simple send/receive tasks. Keep it as "dumb" as possible. Make all the "smart" G-code manipulations at higher levels (pronsole/pronterface). I will have a closer look in the following week at this. It might be that changes to printrun/printcore.py are unavoidable anyway. (Reminder to myself to merge the code refactor for printrun/printcore.py (Refactor printcore.py #1346) before any other changes to it whatsoever)

2. The proposed changes seem backwards compatible at first sight so no issues there but keep this in mind for a future more-elaborated proposal.

Once more, thanks, I think it is a great idea. I'll have another look.

Looking to what you want to implement I think there need to be something like a special setup for embroidery that then can handle all special requirements that differ from Pronterface/Pronsole normal use case.

I totally agree here that a setting activating/deactivating all special settings (if any) sounds like the sane thing to do.

Maybe it is worth to add a separate branch for this and look where we will end with this idea.

Agreed. Good idea. Though again it might not be needed if it is a "simple" feature addition.

[rockstorm101]

Hi @duk3luk3, I've given this feature another thought. I think this can (and should) be implemented without too much modification to printrun/printcore.py and a special setting might not be necessary. I would propose something along this lines, haven't even tried to code it so might not work at all:

1. Keep the option to resume without restoring status on printcore.resume(). That's a very reasonable feature that probably should've been there from the very beginning. All other changes to be moved to pronsole.

2. The new functions on pronsole would play around with printcore.queueindex like in this pseudo-code/schematic:

   def do_load():
       # same code as today but add:
       self.p.queueindex = 0
       
   def do_skip():
       self.p.queueindex += 1
       
   def do_next():
       index = self.p.queueindex
       line = self.fgcode.lines[index].raw
       self.p.send_now(line)  # won't be that easy, will need comment strip and such
       self.p.queueindex += 1
       
   def do_line():
       # show next lines as proposed but do all the logic here instead of on
       # `printrun/printcore.py`
   
   def do_print():
       # same code as today but:
       self.p.startprint(self.fgcode, self.p.queueindex)
   
       # `self.p.queueindex` will be different from 0 if one skipped/stepped
       # before starting the print
       
   def do_resume():
       # add a parameter to either restore or not the previous state?
       #   
       # if one skipped/stepped while the print was paused, one will have
       # increased `self.p.queueindex` and therefore `printcore.resume()` will
       # send commands starting from wherever the queueindex is now

I hope it makes sense what I tried to describe here. Let me know your thoughts, chances are I missed something big and the whole idea is nonsense so please don't hesitate to comment against it.

Thank you for your patience.