feeding gcode through a pipe

[petaflot]

feeding gcode through a pipe

[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