Open PhBeuthe opened 2 years ago
the definition of variables: # 1 ... # 100 ... etc ;
Is it some standard G-code feature? Who implements that?
the FUP function [arg] ;
What's that? Round up? You can roughly round up with {int(yournumber + 0.99999999)} or with the upcoming PrusaSlicer 2.4.0-beta1 with {round(yournumber + 0.5)}
and while doing so, to be able to integrate subroutines with the O codes, to avoid having to create programs external to the slicer.
What are O codes?
Hello,
Here are the answers to your questions: https://gcodetutor.com/cnc-macro-programming/cnc-variables.html http://www.linuxcnc.org/docs/html/gcode/o-code.html http://www.linuxcnc.org/docs/2.4/html/gcode_overview.html
To round down to integer: FIX[arg] To round up to integer: FUP[arg]
These functions allow you to write a "cleaner" gcode. Of course we can use the tips you provide. But being of the generation which knew the beginnings of the microcomputer programming ('79 -'80), it reminds me of the "pirouettes" that we had to do to save memory.
round() was implemented with 3216448bbc67d76da197591f349e81ab9f65113e round() does the math rounding you would expect.
Regarding the variables, O-code, subroutines and such, there is a fundamental difference between PrusaSlicer G-code macro processing language and G-code language: PrusaSlicer does macro-processing, thus we must not repurpose the G-code language, there is no real time input from the machine and for loops and such have limited utility as we don't want to generate excessive G-code blocks.
Thank you for your reply. I understand the concept of your product. However, as a user, a reduced g-code compared to that of other CNC machines does not meet my expectations.
I would also find the gcode variable functionality useful. E.g. adding '#101=0.5;' would create a variable named #101 with value 0.5).
Support for local and global variables was implemented in 2.6.0-alpha6.
Version
PrusaSlicer 2.3.3+x64
Operating system type + version
MacOS 11.6
3D printer brand / version + firmware version (if known)
MK3S
Behavior
New feature request:
Hello,
By integrating a personalized gcode allowing to automatically define the temperature of the bed according to the layer where the nozzle is located to neutralize the warping, I noticed a strangeness in the calculation of PrusaSlicer. For those who want to test the question, insert M117 in the gcode customization.
For the example, I defined the following values in the slicer: -> first_layer_bed_temperature: 80 ° C -> bed_temperature: 90 ° C
If I encode:
M117 {(bed_temperature[0]-first_layer_bed_temperature[0])/(15-6)}
The result in the gcode will be 1 because the result 10/9 = 1.11 ... 11 is greater than 1.On the other hand, if I encode:
M117 {(bed_temperature[0]-first_layer_bed_temperature[0])/(15-4)}
The result in the gcode will be 0 because the result 10/11 = 0.9090 ... 9 is less than 1.The point is, PrusaSlicer does not round up to get an integer, but round down to get that integer. However there is in the gcode the mathematical function FUP [arg]. If the second case could be programmed as follows:
M117 {(bed_temperature[0]-first_layer_bed_temperature[0])/FUP[(15-4)]}
-> the result would be 1. In this case it would be useless to ensure that the value of a division is always greater than 1.So this message to the Prusa team: it would be handy if you made it possible to program a gcode with the following functions:
Thank you in advance for your answer.