Conditional GCode and object model variables

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.

A Former User

@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

It can, many of us use post-processors for G-Code after it exits the slicer, and there many useful info can be embedded in the code... for e.g. there are some that embed %done, total amount of plastic, date, time etc etc... it's fairly easy to embed the size of the object, position... now, most of them embed this info in form of comment but when you implement the VAR xxx = yyy I assume that's it as then we can set in slicer/postprocessor to instead add this as comment, add these in form of VAR maxwhatever = 12345 ..

tbh I expected this gcode addon to be also inside comments, to use some "special comments" like for e.g. bash uses #! or mysql /*! to be special comment ... so I expected something like ;! if blah blah .. so that G-Code works on other interpretters too (kinda) but I don't mind it like this

gtj0

@dc42 said in Conditional GCode and object model variables:

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

The one that sprang to mind immediately was defining the mesh grid
M557 X0:460 Y0:450 S25

DaBit

Should I ask these questions here or in the 3.01beta topic?

I flashed 3.01 on my Duet2; I want more intelligent heating/cooling in my toolchanges.

Two things I notice right away:

In heat.heaters there is both a sensor number (heat.heaters[x].sensor) and a copy of the sensor value's lastReading (heat.heaters[x].current). That is redundant. And the actual setpoint is missing?
There is no information about tools in the object model, right?

Part of the M409 response:

"heat": {
      "coldExtrudeTemperature": 160,
      "coldRetractTemperature": 90,
      "heaters": [
        {
          "current": 16.5,
          "sensor": 0,
          "state": "Off"
        },
        {
          "current": 66.4,
          "sensor": 1,
          "state": "Active"
        },
        {
          "current": 40,
          "sensor": 2,
          "state": "Standby"
        }
      ],
      "sensors": [
        {
          "lastReading": 16.5,
          "name": "",
          "type": "Thermistor"
        },
        {
          "lastReading": 66.4,
          "name": "",
          "type": "Thermistor"
        },
        {
          "lastReading": 40,
          "name": "",
          "type": "Thermistor"
        },
        {
          "lastReading": 29.5,
          "name": "mcu-temp",
          "type": "microcontroller embedded temperature sensor"
        }
      ]
    },

Can I also access the response given by M408 P1 somehow?

dc42

@DaBit said in Conditional GCode and object model variables:

Should I ask these questions here or in the 3.01beta topic?

Here is good.

In heat.heaters there is both a sensor number (heat.heaters[x].sensor) and a copy of the sensor value's lastReading (heat.heaters[x].current). That is redundant.

Correct. We could remove the one in the Heater object, but then you would have to write heat.sensors[heat.heaters[n].sensor].lastReading instead of just heat.heaters[n].current. Maybe that's acceptable and I should remove the redundant one.

And the actual setpoint is missing?

I haven't got round to adding it yet.

There is no information about tools in the object model, right?

Not yet, just the current tool number.

Can I also access the response given by M408 P1 somehow?

Yes, see the wiki page about the object model.

DaBit

Duplicating data is not often a good idea so my vote goes to heat.sensors[heat.heaters[n].sensor].lastReading. On the other hand there is a line length limit of 160 characters.

About accessing the M408 P1 object in Gcode (which at least contains active/standby temps): how? 'echo heaters[0]' does not work.

Now that I look at the JSON response I see something weird in the M408 P1 response; after executing these G10's with T0 active and T1 in standby:

G10 P0 S60 R30
G10 P1 S70 R40

The M408 P1 response is:

{
  "status": "I",
  "heaters": [
    18.4,
    60,
    40
  ],
  "active": [
    0,
    60,
    0
  ],
  "standby": [
    0,
    30,
    40
  ],
..
..

Heater 0 is the bed heater, 1 is for T0, 2 is for T1

The active temperature for heater 2 returns 0 instead of the 70 I would expect.
(RRF 3.01-beta1+1 (2020-01-15b2), by the way)