Conditional GCode and object model variables

DaBit

I suspect most of my conditional code use would be some form of
while (measured value < setpoint) {
move this
move that
pause a while
}

and if (this) then { that }

The conditional code provided by LinuxCNC and accessing of state information through numbered or named variables is not all that complicated and works well enough.

I would at prefer to have access to axis positions and sensor values.

JoergS5

My proposal for G-Code is to have all sorts of input values like external pin signals, temperaturs, voltages, current stepper positions; then calling macros to react to them and have some time waiting/pausing/reset to specified state methods. G-Code to call external methods like a Raspi for camera analysis and come back for reaction. The G-Code implementation should follow syntax rules of a known programming language (C++, Python etc. but only one of them), so the syntax needs not to be learned new again.

dc42

The syntax has already been defined. It id described at https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands. We are constrained by the conventions and symbols that are already used in GCode.

As GCode is a line-oriented language, the main decision that had to be taken was whether to denote block scopes using indentation (as in Haskell and Python) or using block end keywords (as in Algol 68, Ada and Fortran). I chose indentation.

mwolter

Min and Max X and Y coordinates of the print.

Would be very helpful if the min and max X and Y coordinates of the print could be read from the g code and used as a variable in an M557 which is saved before running G29. This would allow a custom probe grid to be used that only probes the area of the bed used for that particular print.

Luke'sLaboratory

@mwolter
It would be pretty neat to have this built in to the printer instead of the slicer as I've been thinking about!

A Former User

On the subject of Min/Max. Access to work dimensions as well as the specific job dimensions as mrwolter requets.

dc42

@bearer said in Conditional GCode and object model variables:

On the subject of Min/Max. Access to work dimensions as well as the specific job dimensions as mrwolter requets.

This is tricky, because GCode files do not contain information about the total dimensions of the part being printed/CNC'd/cut. But we can make a reasonable guess at it by scanning the entire GCode file. This assumes the the GCode file does not contain custom scripts for purge or prime towers, or similar operation that move to coordinates outside the model.

fšk

@jay_s_uk said in Conditional GCode and object model variables:

The most useful thing for me would being able to detect a voltage on an input to identify which tool is fitted.
E.g. tool 1 is 1V, tool 2 is 2V and so on.
Then the machine would be aware of what tool is fitted and apply offsets accordingly etc.

I would also find this very useful. Probably the only thing i would need conditional gcode for.
Would need this to load a different config depending on what is connected on machine boot.

HebigT

The ability to call a macro using a "Layer_#" variable would be useful for my research. I'm planning to develop non-extrusion tools for tool-changing printers.

Riev

@dc42 , I think The most useful things is :

The conditional block may consist "AND / OR" expression so we can combine two or more logic expression.
SELECT CASE Function as alternative conditional block after IF-ELIF
Attach "LABEL" name Function in any certain line and "JUMP TO LABEL / GOTO LABEL" Function so we can jump or loop to any line we desire. I think this is more flexible than "While" or other Loop function.
"WAIT" Function for any input signal or variable is triggered/changed, and make decision with conditional expression based on change of that input signal (Like wait for button is pressed)
Any variable / command to manipulate "Counter and Timer" Function.

dc42

@Riev said in Conditional GCode and object model variables:

@dc42 , I think The most useful things is :

The conditional block may consist "AND / OR" expression so we can combine two or more logic expression.

SELECT CASE Function as alternative conditional block after IF-ELIF

Attach "LABEL" name Function in any certain line and "JUMP TO LABEL / GOTO LABEL" Function so we can jump or loop to any line we desire. I think this is more flexible than "While" or other Loop function.

"WAIT" Function for any input signal or variable is triggered/changed, and make decision with conditional expression based on change of that input signal (Like wait for button is pressed)

Any variable / command to manipulate "Counter and Timer" Function.

Thanks for your suggestions. #1 is already implemented. #2 is complicated to do in a line-oriented language, also I don't envisage any common situations in which there would be many cases to choose from; so I won;t imllement it at least for now. For #3, 60 years of program language development have taught us GOTO is bad, so I won't be implementing it. #4 is interesting and I will consider it. Can you explain exactly what you mean by #5?

garyd9

@dc42 said in Conditional GCode and object model variables:

For #3, 60 years of program language development have taught us GOTO is bad, so I won't be implementing it.

Surely you knew when typing the above that you'd be starting a discussion on the merits of goto in programming, right?

Goto isn't the demon that it's made out to be. The problem is that it was massively abused. (Just like anything.) For things such as state machines, they are extremely useful. (Is conditional gcode a state machine?)

Keep in mind that all our languages are usually compiled to assembly. Show me any functional assembly that isn't littered with "goto" (jmp) instructions.

(I'm not suggesting that any type of 'goto' should exist. I was just making a silly point.)

grizewald

@dc42 said in Conditional GCode and object model variables:

60 years of program language development have taught us GOTO is bad, so I won't be implementing it.

I'm guessing you mean that GOTO is bad for those who don't know how to program. They should certainly be used very sparingly and can be misused to create spaghetti worse than any 3D printer, but they are not bad per-se.

In deeply nested decision blocks, a goto can be a life saver for code clarity. Even in those languages which don't provide a goto but give you a try, catch pattern instead, it still boils down to an absolute jump once it gets compiled.

infiniteloop

@grizewald I’ve spent many years with GOTO, because the first incarnation of APL had nothing else to offer. This 'style' makes your code unreadable and difficult to debug, it’s a nightmare. Even with labels instead of line numbers: it’s easy to break the stack, to jump out of context… or think of someone who re-assigns a label by accident to something else. No, GOTO is nothing else than an invitation for bugs.

JoergS5

C++ has goto and even Java has something similar with labels to jump out of a loop. I would prefer if it's available in a language and the developer can decide himself whether he wants to use it in extreme cases. I myself don't use it, but there may be specific cases.

wilriker

@JoergS5 said in Conditional GCode and object model variables:

even Java has something similar with labels to jump out of a loop

Java even has goto as a reserved word - it will lead to a compiler error when used.

I don't actually want to chime in on the goto discussion. All I would have said is a mixture of the above.

@dc42 I was reading the language description wiki page and I was surprised that logical AND and logical OR are on the same precedence level. Most languages I know have a higher precedence for logical AND than for logical OR.

A Former User

@wilriker said in Conditional GCode and object model variables:

it will lead to a compiler error when used

Touché!

But I guess we can put the whole discussion to bed with the following. All in favour of removing jmpinstruction raise their hand .. and having it doesn't mean you have to use it.

OT aside, really looking forward to this beta!

gtj0

@dc42 said in Conditional GCode and object model variables:

@bearer said in Conditional GCode and object model variables:

On the subject of Min/Max. Access to work dimensions as well as the specific job dimensions as mrwolter requets.

This is tricky, because GCode files do not contain information about the total dimensions of the part being printed/CNC'd/cut. But we can make a reasonable guess at it by scanning the entire GCode file. This assumes the the GCode file does not contain custom scripts for purge or prime towers, or similar operation that move to coordinates outside the model.

This reminds me of a discussion we had a while back about having the DCS provide pre-processing hooks on files. The hook would provide the name of the file, the script would do whatever it needs to it, write it out to a temp file, then tell the DCS the new file name. This may already be possible with intercepts ( @chrishamm ? ).

What RRF would need to do is allow statements to set variables in the print file that would later be accessible from macros.

The original thought came up when we were talking about having multiple bed heaters creating zones on a large bed plate, then having the gcode only turn on the zones needed for the particular print. The thought was that the script would calculate the bounds and either override the bed heater commands in the input gcode or pass the bounds on to a macro with conditional gcode.

gtj0

I kinda missed this thread but in reading it and the Meta Commands stuff it looks pretty good. Variables are the most important for me since I really want to make changes to things temporarily then set them back to the original value when I'm done.

I also didn't see this in the discussion ( or I missed it ) but being able to get things set in config.g that aren't already in the object model is something I think we'd need. Kinda like a JSON output of M503 that we can reference in the macro.

dc42

@gtj0 said in Conditional GCode and object model variables:

I kinda missed this thread but in reading it and the Meta Commands stuff it looks pretty good. Variables are the most important for me since I really want to make changes to things temporarily then set them back to the original value when I'm done.

Can you give me an example?

If you need to restore everything to the values in config.g, you can do that by re-running config.g. To restore a subset of values, set those up in a macro that config.g calls.

I also didn't see this in the discussion ( or I missed it ) but being able to get things set in config.g that aren't already in the object model is something I think we'd need. Kinda like a JSON output of M503 that we can reference in the macro.

The plan is that everything you can configure (and some things you cannot) will be in the OM. Now that the OM framework is complete, it's mostly a matter of adding entries to tables and a few simple getter functions.