Allow TPL to emit arbitrary G-code

[gadelan]

There are some issues that could be solved allowing TPL to emit arbitrary G-code. Instead of comment() or message() that wrap their argument in parentheses, a new function emit() just writes its argument to the g-code file.

Of course, this suggestion is just for TPL. Not for the simulator. If the simulator does not know what the g-code you just emitted means, nothing can be done. And you can emit, literally, any g-code.

Also, this function is for advanced users. It will confuse the TPL interpreter if you emit an instruction that moves the machine bypassing the standard matrix-applying code, linearization code, and so on.

On the other hand, maybe your machine uses M7.1 and M8.1 to turn off coolant outputs #332. Well, emit("M7.1") and emit("M8.1") until the issue is resolved. Or your machine uses M106 and M107 for LASER control #318. Then, while waiting for the issue to be implemented, just emit("M106") and emit("M107"). Disable GRBL hard limits? emit("$21=0") This laser machine uses G0 to turn the laser off? emit("G0")...

[jcoffland]

There is already the print() command. However, running such code in the simulator may not have the desired effect. Any GCode which is emitted by print() will be missed by the simulator. You could preprocess with TPL, then run the resulting GCode in the simulator.

[gadelan]

That was a quick reply. Thank you!

We are not talking about the simulator. Just TPL. The simulator cannot understand arbitrary g-code. That's obvious.

I tried what you suggested using the tplang program as preprocessor. But, when executing

tplang test.tpl --out "test.nc"

Where the file test.tpl is

print("G0 X0 Y0");
print("G1 X10"); 

The resulting file test.nc is

G21
M2 

The command line console does show

G0 X0 Y0G1 X10

in the standard output, and we could use --out - but then we are conflating two different streams. One with the g-code and the standard output.

I have tried to understand how the print command works following the source code. The only appearance of "print" is in GCodeInterpreter::specialComment() which uses LOG_INFO. However, both message() and comment() call the same-named methods in GCode::GCodeMachine and these methods use GCode::GCodeMachine::stream which is the output file of CommandLineApp::build() initialized in CommandLineApp::init().

As far as I can understand the source code, there is no command to emit g-code from TPL. I mean, a command that has a semantics that says "write to the g-code file/stream". We can use print (to standard output) and make the g-code file be the standard ouput to get around that, but... is this it? By design?

[jcoffland]

It should be writing to the same stream. CAMotics::CommandLineApp::stream is also passed to TPLContext in TPLangApp::run() in tplang.cpp. This is what cb::StdModule::print() writes to. Are you saying that print() still ends up in stdout when you set --out <filename>? What build are you using?

[gadelan]

tplang --version says 1.2

[jcoffland]

I just tested this in my local build and the streams are the same. I in believe v1.2 print() always prints to stdout but that has been fixed. I've been trying to make a new CAMotics release for a long time now but haven't been able to find the time. You can always build from source.