Conditional GCode and object model variables

Danal

Everything reported in an M408.
Time (ticks? ).
User (dynamic)
EVERY command that sets anything, perhaps as a %command% to make it easy to remember.

The above probably covers this: Everything that has a position. The 'control point' Work coordinate systems, every kind of offset like tool offset, cutter offset, and so forth. Everything that has a position or offset.

dc42

What I am actually asking for is the most useful things to include in the object model, so that I can do a beta release that is useful to some people. If I wait until I have implemented everything that I plan to include, it will be weeks or even months before the beta release.

jay_s_uk

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.

littlehobbyshop

Currently selected filament (Similar uses to currently selected tool)
min(), max(), ave() functions. Could be used universally. Like with G29 if your initial suggestion returned a list (max deviation) rather than a specific function alone for G29.

mrehorstdmd

I use a Duet wifi card in my sand table. Right now I can program playlists using the M98 command, but it would be nice if there was some means to randomly select pattern files to run from among any gcode file stored in a specific directory on card 0 or card 1. It would be especially nice if I could call a single gcode macro file upon power-up that would then randomly select pattern files to run and just keep doing that until the machine is powered off (maybe days or weeks later). That would require some looping capability, I imagine.

It would be especially nice if the random function were seeded by a real time clock or other means so that when I power up the table, the random sequence that it plays would be different every time (or almost every time).

@dc42 said in Conditional GCode and object model variables:

Are you sure?

Unfortunately, yes. that's for e.g. why Falcon never went GA after so many engineer years was put in and hundreds of bugs reported (and fixed) to both GCC and Intel C/C++ compiler. It's not unsafe by design, it's just that most C++ compilers have it buggy as hell. Today situation is much better than for e.g. 2009, but is still not resolved. Again, no clue how that relates to embedded systems, and if it relates at all.. it's just one of those things few ppl think about and can hit you below the belt when you least expect

Now that C++ supports threads natively, that seems odd.

If that's the only thing

only the GCode parsing part of RRF uses exceptions, and only one task calls that code.

That's safe.
I think it would be safe even if not only that 'cause the unsafe part start to pop up under contention, I don't finally remember all the details but but I think it's the number of threads and not the CPU load that was a problem so since I doubt you'll have issue with number of threads on the RRF you should be safe whatever you do... but yes, single thread using exceptions will never hit any of those bugs

wesc

@dc42

Ternary operator like the c language ? :
Very useful for doing machine specific parameter substitutions vs having to do if then else.

Min, max functions

Max z of the current print job. Useful for doing tuning of parameters. That, or an interpolate with z function. For example
M572 DO S%zinterpolate(0.1,2.0)%
which would be the same as
M572 D0 S%0.1+(2.0-0.1)*z/max_z%

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!

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.