Conditional GCode and object model variables

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)

dc42

@DaBit said in Conditional GCode and object model variables:

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

As stated in the wiki page on GCode meta commands, object model expressions in them must evaluate to primitive types, not objects. Try 'echo heat.heaters[0].current'.

DaBit

That refers to the object model as returned by M409. I can access those. M408 does not return a 'heat' sub-object or whatever the official JSON name for nested items is.

I was just hoping that I could use the values in the JSON object as returned by M408 also. Those contain info about the tools....

Nevermind, I will exercise a bit of patience until more is added to the object model.

appjaws

Just a few question for @dc42

Has the object model been updated recently?
Is it possible to have the fan[].fanPercent included?
What test can I used to check if a filament is loaded?
When will we be able to define a variable?

Thanks for any help

dc42

@appjaws said in Conditional GCode and object model variables:

Has the object model been updated recently?

Yes, in 3.01-RC2.

Is it possible to have the fan[].fanPercent included?

I will look into it.

What test can I used to check if a filament is loaded?

Currently you would need to define a GP input pin for the filament present switch and then test it.

When will we be able to define a variable?

In the 3.02 release.

dc42

@appjaws said in Conditional GCode and object model variables:

Is it possible to have the fan[].fanPercent included?

fan[].requestedValue and fan[].actualvalue are already provided.

dc42

@appjaws said in Conditional GCode and object model variables:

What test can I used to check if a filament is loaded?

Filament monitors of type 1 and 2 (simple switch) already provided a filamentPresent field in the object model. I have just added the same field for type 4 (rotating magnet + switch) and type 6 (laser + switch).

appjaws

Thanks dc42,
The fan entries are failing with "Error: unknown value"
I'm I using it correctly?
while true
if fan[3].actualvalue <0.2
M106 P3 Sfan[3].requestedValue+0.1
M400
echo "LED Red value = " ^ fan[3].actualvalue

Where can I print out the latest object models?

dc42

I'm sorry, it's actualValue with uppercase V.

appjaws

@dc42 said in Conditional GCode and object model variables:

actualValue

Sorry but none of these work
"Cooling"
echo "LED Red value = " ^ fan[0].actualValue
"Extruder"
echo "LED Red value = " ^ fan[1].actualValue
"System"
echo "LED Red value = " ^ fan[2].actualValue
"LED Red"
echo "LED Red value = " ^ fan[3].actualValue
"LED Green"
echo "LED Red value = " ^ fan[4].actualValue
"LED Blue"
echo "LED Red value = " ^ fan[5].actualValue

dc42

I'm sorry again, it's "fans" not "fan".

Send M409 K"fans" to see all the fan OM values.

NexxCat

Apologies is this is a stupid question, or I'm overthinking this problem, but currently I run a delta calibration prior to every print. Whilst it's not a big issue normally, if I'm doing one print after another, allowing the nozzle to cool to my probing temperature (130C), probe, and then heat back up, is time wasted. With the release of 3.02 and variable support, would the following be possible for example?

On startup (in config.g?) assign a variable (say deltaCalibrated) to 0
After G32 is run, set deltaCalibrated to 1
If G28 is called, check to see if the calibration has been run, if so override the homing and move to Z-Max instead. If not, act as normal
If M84 is called, reset deltaCalibrated to 0

This would mean I would only have to run the delta calibration once per power-on under normal circumstances. It wouldn't re-home and mess up the existing Z height, and would only re-calibrate when needed.

Again, apologies if I'm overthinking this, or something like this is already possible, but this has been in the back of my mind since conditional gcode was first talked about