Feedback wanted: conditional GCode without indentation

dc42

The existing conditional GCode mechanisms have proved very flexible. However, the need to indent the body of a conditional or loop makes it impractical to use a while-loop to create a looping GCode file, for example for a belt printer. So I would like to provide an option for the bodies of 'if' and 'while' commands to be terminated by a keyword instead of by the end of indentation. This would also allow the Marlin M808 command to be mapped to RRF conditional GCode.

There are a few decisions to be made:

Should the keywork be 'end', or something else?
Should it be permitted to mix keywork-delimiting and indentation-delimiting in the same file? If so, what problems might arise, and what restrictions should be enforced?
How should the user indicate to the firmware that a loop or conditional is to be delimited by a keyword instead of by indentation? One option is to have a new command keyword (e.g. 'noblockindent') that means that for the remainder of the file, keywork-delimiting will be used. Using that keyword when already inside a block would probably have to be banned. Another option is to use different variations of 'if' and 'while' (e.g. a different keyword or some extra character) to indicate keywork delimiting for that command.

This isn't intended to be a vote, however I will take account of opinions expressed here. Other solutions that I haven't thought of would be especially welcome.

Sindarius

Speaking for myself I am not the biggest fan of indented scope because font, editor, and a few other factors can make the indentation difficult to follow.

I think 'end' is a perfectly fine keyword for the task considering 'begin' and 'end' have been used in multiple programming languages and has a very specific meaning that applies here.

jay_s_uk

Less indentation is probably helpful as currently, none of the slicers handle this and it means all conditional gcode needs to be macro based etc

fcwilt

@dc42

1 - END by itself is easy but if you don't see it in context you don't know what it is the end of. It might be better to have unique keywords - ENDWHILE, ENDIF or something along those lines.

2 - I would make the use of the new keywords mandatory. Yes existing users would have to do a bit of work but it would keep things simple and consistent for all in the future.

3 - While you are implementing the change I would also suggest that a REPEAT/UNTIL or a DO/WHILE loop be implemented - the type of loop that always runs once.

Frederick

DaveA

As a C & C++ programmer from around 1976 I'd love to see the Kernighan and Ritchie style with { } syntax. I hate Python indention style.
Just my opinion since you asked.

arhi

I loathe the use of whitespace to define the flow so removing that and moving to begin/end, {/}, if/endif ; while-endwhile; do/while; repeat/until.. syntax is appreciated

I don't mind rewriting all my conditional g-code to the new syntax

garyd9

Can you please give an example of a gcode sequence that would impractical with the current space delimiting blocks?

Personally, I'm not a big fan of spaces marking blocks of code. This is especially true when a mix of tab and space characters might be allowed. If spaces will continue to be used, I'd be in favor of the interpreter disallowing a mix of space/tab characters in the same file (similar to what I've seen python interpreters doing.)

Using "end" type keywords comes with it's own set of problems unless you create different "end" types. "end if", "end while", etc -- or you are very strict with requiring blocks to be 'end'ed.

For example, in the following code, is the 'end' ending the "while" loop or the "if" conditional?

if conditional
while (iterations < 5)
// do something
end

Using if/while specific versions of 'end' make things a bit less confusion, but still can be confusing:

while (a)
while (b)
end while // is this ending while(a) or while(b)?

If you REQUIRE 'end'ing EVERYTHING, it tends to result in more verbose code, but is also clearer:

if (conditional)
while (iterations < 5)
while (b)
// do something
end // this can only be ending the while(b) loop
end // this can only be ending the while(iterations) loop
end // this can only be ending the if conditional

-- and if an 'end' is missing, the interpreter would generate an error.

This approach (requiring every single 'if' and 'while' to have it's own "end") would probably be easier to write the interpreter for, and easiest to debug.

As for mixing keywords and space indents, I think that would be a recipe for confusion, both for the user and for the code interpreter. The fact that RRF and DSF might handle things slightly different would only add to confusion. My suggestion is to pick one way and enforce it.

timcurtis67

@Sindarius said in Feedback wanted: conditional GCode without indentation:

Speaking for myself I am not the biggest fan of indented scope because font, editor, and a few other factors can make the indentation difficult to follow.

I think 'end' is a perfectly fine keyword for the task considering 'begin' and 'end' have been used in multiple programming languages and has a very specific meaning that applies here.

+1

fcwilt

@garyd9 said in Feedback wanted: conditional GCode without indentation:

Can you please give an example of a gcode sequence that would impractical with the current space delimiting blocks?

The issue is gcode files as generated by a slicer - not the files you would create yourself on the duet.

Frederick

fcwilt

@DaveA said in Feedback wanted: conditional GCode without indentation:

As a C & C++ programmer from around 1976 I'd love to see the Kernighan and Ritchie style with { } syntax. I hate Python indention style.
Just my opinion since you asked.

Ugh - no.

C++ syntax was devised by sadists.

Frederick

DaveA

@fcwilt Yeah, I can agree with you on C++. I'd rather stick with straight C as most of my experience was with windows device drivers. In any case, it's better than Python.

zapta

@fcwilt said in Feedback wanted: conditional GCode without indentation:

END by itself is easy but if you don't see it in context you don't know what it is the end of. It might be better to have unique keywords - ENDWHILE, ENDIF or something along those lines.
Frederick

One option is to annotate it with comments.

END ; while xyz

BTW, I am also not a fan of white space indentation having semantic meaning. It's too fragile, event with language specific editors that support it.

reghend79

I think both keyword-delimiting and indentation-delimiting should be permitted in the same file to allow for flexibility and varying degrees of clarity. I'm working on analyzing print data in Matlab to create feedback control, and I am quite fond of using both indentations and "end" statements at the same time. The indentations are not normally required in Matlab, but they're done automatically to help visualize the blocks.

zapta

@reghend79 said in Feedback wanted: conditional GCode without indentation:

The indentations are not normally required in Matlab, but they're done automatically to help visualize the blocks.

That's a good point, END should still allow indentation for code clarity, though the indentation would have no semantic impact. E.g. these code snippet should have the same meaning

            IF
     COMMAND1
  COMMAND2
COMMAND3
    END


IF
COMMAND1
COMMAND2
END


IF
    COMMAND1
    COMMAND2
    END

IF
    COMMAND1
    COMMAND2
END

fcwilt

@zapta said in Feedback wanted: conditional GCode without indentation:

One option is to annotate it with comments.

END ; while xyz

True but with specific keywords I'm forced to do the "right" thing.

Frederick

alankilian

Here's one way to "DO" it.

https://www.cnccookbook.com/cnc-g-code-macro-conditions-looping/

garyd9

@fcwilt said in Feedback wanted: conditional GCode without indentation:

@garyd9 said in Feedback wanted: conditional GCode without indentation:

Can you please give an example of a gcode sequence that would impractical with the current space delimiting blocks?

The issue is gcode files as generated by a slicer - not the files you would create yourself on the duet.

That doesn't answer the question. Without an example of the problem, it's difficult to give a reasonable opinion on a proposed solution.

bot

I think removing all indentation/whitespace from the syntax is a good idea. I also think a single END keyword is best. Multiple end keywords is just unnecessary. Keep track of the ENDs the same way one keeps track of the }s.

fcwilt

@garyd9 said in Feedback wanted: conditional GCode without indentation:

That doesn't answer the question. Without an example of the problem, it's difficult to give a reasonable opinion on a proposed solution.

As dc42 said in his opening post:

However, the need to indent the body of a conditional or loop makes it impractical to use a while-loop to create a looping GCode file, for example for a belt printer.

That seems clear enough.

Frederick

dc42

@garyd9 said in Feedback wanted: conditional GCode without indentation:

@fcwilt said in Feedback wanted: conditional GCode without indentation:

@garyd9 said in Feedback wanted: conditional GCode without indentation:

Can you please give an example of a gcode sequence that would impractical with the current space delimiting blocks?

The issue is gcode files as generated by a slicer - not the files you would create yourself on the duet.

That doesn't answer the question. Without an example of the problem, it's difficult to give a reasonable opinion on a proposed solution.

Suppose you generate a GCode file using a slicer. But you have a belt printer and you want to print it 10 times, with a belt movement between each iteration.

Using existing slicers, there is no way to use the slicer start and end scripts to achieve this.

You could achieve it by editing the GCode file, but then you would have to indent almost the whole GCode file so that it became the body of the while-loop.

If we offer the option to delimit if- and while-commands explicitly, then you could insert one line near the start of the file (the 'while' line), and one near the end (the 'end' line). You might even be able to put the 'while' line in your slicer start script, and the 'end' line in the end script, so that you don't need to edit the file at all.

Does that make the reason for this proposal clearer?