Feedback wanted: conditional GCode without indentation

wilriker

My opinion: use a keyword to end blocks (end is fine for me, but honestly I don't care).

Do not allow mixing styles, use block end keywords exclusively (but allow indentation for style purposes).

fcwilt

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

My opinion: use a keyword to end blocks (end is fine for me, but honestly I don't care).

So you would be ok with "ruvineckerned" or "footguratunnie"?

Just checking to be sure.

Frederick

garethky

@wilriker +1

The target audience for this language is not skilled programmers. Its designers & makers that are trying to solve some problem with their printer. There is going to be a LOT of copy/paste code that mixes indentation types (tabs, spaces, number of spaces). Begin/end constructs survive this kind of abuse better than Python style strict indentation. Having just 1-way-to-do-it makes its safer/easier for newbies copying code.

The few of us that are writing most of the code can use whatever construct you come up with.

DanS79

I think php might be a good example here as it allows two types of syntax.

For pure php

<?php
if ($a > $b) {
    // do somehting
} else {
 // do somehting else
}
?>

For php mixed with large chunks of something else like html, JS etc.

<?php if ($a > $b) : ?>
    // do somehting
<?php else: ?>
 // do somehting else
<?php endif; ?>

All standard control structures have the second alternative syntax.

The parser knows php is only contained between the opening and closing tags

<?php  // some code here ?>

The alternate control structures lets the parser know that logic spans multiple sets of opening and closing tags.

Each control structure has it's own unique opening and closing tags.
here is a quick little tutorial with examples.
https://riptutorial.com/php/topic/1199/alternative-syntax-for-control-structures

OwenD

One thought I guess as is how any start/end construct might be interpreted by common slicers if used in start gcode etc
Prusa slicer uses if-endif so is definitely going to try to post process that. Whether it causes any issues probably depends on how PS handles things it doesn't understand

garyd9

I agree that styles shouldn't be mixed and that RRF should either support one thing or another (and not both.) However, RRF 3 is a released product, so any change could be breaking a LOT of code, macros, etc.

Even the initial "conditional gcode" stuff in RRF3 was done in such a way to not break any existing gcode.

For that reason, I still think there are ways to solve the actual problem without breaking changes to the language. One idea I proposed above, though I don't know if that would actually work. Immediately after, someone else proposed something else that wouldn't break any existing gcode.

Breaking an existing programming language for single special cases isn't a good practice. Even large functional changes should be careful to not break existing code. I still have old K&R style C code that still compiles with a modern C/C++ compiler!

OwenD

@dc42

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.

For this particular case, could it not be solved using a loop Gcode as in CNC or plasma cutting? In the case of Hypertherm controllers they use G97 & G98 to define the loop.
In my day job I sell CNC plasma systems and the nesting program would output thusly if you used step and repeat.
I would have thought that instead of stepping on Y, you'd just do Z?

%
G21
G91
G97 T10; loop 10 times
N1
M00
G00X0.Y45.278
(Seq 1 - square)
G41
M07 ; torch on
G01Y4.722
G01X50.
G01Y-50.
G01X-50.
G01Y45.278
M08 ; torch off
G40
G00X0.Y104.722 ; move to be ready for next part
G98 ; Repeat at G97 point
M30 ; end of program
%

deckingman

@OwenD I'd have thought, for that particular use case, one would simply advance the belt, reset the Y position using G92, then start the next print. To expand on that, when a print finishes, move the belt (say) 200mm. At that point the Y position would be (say) -250. So simply use G92 Y50 to reset it to 50, then start the next print. It's a little more complicated because the starting Y position, before the 200mm move would differ with each print, but it wouldn't be beyond the wit of man to subtract (say) 200mm from whatever the end point becomes.

DonStauffer

@dc42 I'd like to see indentation not have semantic meaning, mainly because the way it is now, I can't have a macro write a macro that writes a macro with conditionals in it. Believe it or not, I have a use for that. and this won't work:

M560 P"/macros/Outer"
M28 "/macros/Inner"
if condition
; stuff
M29

(Ironically, the forum software eats my leading spaces and won't let me put in a tab! So ; stuff is supposed to be indented.)

oliof

@donstauffer put your code in a block starting and ending with triple back ticks ( ```) on a single line each to retain spaces.

o_lampe

I haven't read all the replies so here's my 2 cent.

I like to keep indentation (with TAB) for readability.

There's already the break keyword for IF/ELIF constructs, why not use this generally to end IF statements?
Then end would be exclusively for WHILE-loops.

Putting while loops in start/end code of a slicer could lead to conflicts when a print was cancelled.

GuruSMI

This post is deleted!