arithmetics and variables in gcode ?
-
I am trying to understand if there is arithmetics and variables in the reprap firmware. I can't find anything in the doc.
I went into the source code, and GCodeBufferState doesn't seem to have a state for equation, so I suspect not.
I would like to send my heater 20°C lower than it's target while the bed goes to 5°C from it's target and then send everybody to final target simultaneously, I don't see how I can do that.
Thanks for your help.
-
Currently no variables, but it sounds like it's in the works.
I'm not sure I understand your use case, but perhaps what you want to do can already be achieved with a macro?
-
You can do the two step heating in g-code, you just can not do the math to determine the temperatures in the g-code itself.*
You MAY be able to do the math in your slicer start script... and you can absolutely do the math in a slicer "post processing" script since those can be any language, PERL, PYTHON, shell script, etc, etc, and doing the math there would be trivial.
.
* As currently implemented in RepRap firmware. NIST standard G-Code does define some math operations. Being in the standard is a large part of the reason Dave is considering adding this, if enough of us ask for it.
-
-
I would like to add that those features are enablers, currently any single feature we ask for has to be crammed into an Mcode and coded by dc42. With enough programming features, dc42 can tell people to fuck off and do it in gcode (which I'd gladly do, I have a weird mind and I'm perfectly ok with having weird scripts).
The thing can go quite far, Renishaw sells gcode macros for CNC controllers that do interesting geometric computations (with an horrible interface, but there is no hope in gcode).
-
@nraynaud said in arithmetics and variables in gcode ?:
having fusion360->Cura-> duet is error prone and frustrating enough.
We all have our tool chains to bare.
-
@nraynaud said in arithmetics and variables in gcode ?:
I would like to add that those features are enablers, currently any single feature we ask for has to be crammed into an Mcode
To do what OP wanted, no additional M codes are needed. A sequence of temp setting codes, with and without wait, will do what he wants, today. He just can't calculate the offsets in the g-code itself.
Math does not need any new M codes. It is a part of the NIST G-Code specification. In that spec, it math is simply "in line" wherever a number could appear.
DC42 would have to add math to the reprap firmware, and from his comments in other threads, he's at least considering it.
.
So, yes, work on DC42s part.
In this particular case, no new M or G codes required.