Conditional GCode and object model variables

@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.

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.

@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.