feeding gcode through a pipe

[petaflot]

Context

I've just finished writing this program that generates tool trajectories according to recursive rules (they're not quite fractals, but close) ; AFAIK it works pretty well and it's fast to display the result on-screen.

at this stage I can press a button and it generates the gcode : and then all hell breaks lose. while it took me less than two minutes to have a beautiful model on my computer screen, it has now been over 3 hours that I see the gcode lines scrolling in my term - I'm writing to stdout, not a file. - and I'm about half way done. Also, I'm running the simulation at a theoretical 3mm layer height, around 10 times mor than production values

There are a few optimizations I can do to make it faster, one to reduce the size of each line (avoid repeating Z coordinate), the other is to avoid computing avg_feedrate = (P[p].feedrate + P[p+1].feedrate)/2 in favor of using the feedrate for the first point of not using custom feedrates at all, but that is pretty much it. I suppose cythonizing the code might help too, though I don't know to what extent. I have no idea yet how large the gcode file is going to be but I have a feeling it's going to be nuts.

Proposed solution

It is known that slicing takes a long time. Being able to pipe the gcode as it's being generated would IMHO be a very useful feature. Lines 88-90 in printcore.py suggest it is not quit as straightforward as reading from a file that is being written to:

 88     gcode = [i.strip() for i in open(filename)]
 89     gcode = gcoder.LightGCode(gcode)
 90     p.startprint(gcode)

[petaflot]

but that is pretty much it

turns out this is not quite true, I do compute a norm in an apparently inefficient way.

doesn't take away the fact the the gcode file is going to be massive and I'd definitely rather be piping it

cheers!

[rockstorm101]

Being able to pipe the gcode as it's being generated would IMHO be a very useful feature

Maybe I did not understand what you are trying to achieve but, could you not simply call printcore.send_now(command) for every G-code command you generate and at the same rate you generate them? If you generate them faster than your CNC can move, commands will be simply added to a queue. If not, the CNC would pause in between commands.

[petaflot]

I guess you understood well. I didn't go deep enough in the code, my apology.

Just raises one question though... having a queue is OK (as long as we have enough memory and don't OOM the host, but this is pretty straightforward) ; however having the machine stop between instructions can be a problem, and then it would be preferable to rather slow it down (feedrate throttling).

What I did see however is that Marlin has this new format for ACK messages, such as b'ok P15 B3' where the numbers represent the size of some internal queues, and we could use this to throttle the feedrate to unsure that a queue is never empty and the machine always knows what to do next. Is there something like that in printcore?

[petaflot]

you know what? we'll mark this issue as closed.. I am writing a urwid-based interface for machines (it already does some throttling, but at a slightly different level), I got it to work fine on one (defective) board, but not on the new one (and printcore was tested ok on the new board.

Now that I know a little more about printcore I'll try to use it in my program (I was re-inventing the wheel somewhat), then I'll deal with the feedrate throttling issue and submit a patch if required.

Cheers