-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom G-code: variables, FUP function & subroutines #7196
Comments
Is it some standard G-code feature? Who implements that?
What's that? Round up?
What are O codes? |
Hello, Here are the answers to your questions: To round down to integer: FIX[arg] These functions allow you to write a "cleaner" gcode. |
round() was implemented with 3216448 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. |
Implements #4048 #7196 Syntax: (global|local) variable_name = (scalar_expression|vector_variable|array_expr|initializer_list) array_expr := array(repeat, value) initializer_list := (value, value, value, ...) The type of the newly created variable is defined by the type of the right hand side intitializer. Newly declared variable must not override an existing variable. Variable may be assigned with global|local expression, but its type must not be changed. Newly the assignment operator also accepts the same right hand expressions as the global|local variable definition.
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.
The text was updated successfully, but these errors were encountered: