Skip to content
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

Open
PhBeuthe opened this issue Oct 29, 2021 · 6 comments
Open

Custom G-code: variables, FUP function & subroutines #7196

PhBeuthe opened this issue Oct 29, 2021 · 6 comments

Comments

@PhBeuthe
Copy link

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:

  • the definition of variables: # 1 ... # 100 ... etc ;
  • the FUP function [arg] ;
  • and while doing so, to be able to integrate subroutines with the O codes, to avoid having to create programs external to the slicer.

Thank you in advance for your answer.

@bubnikv
Copy link
Collaborator

bubnikv commented Oct 29, 2021

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?

@PhBeuthe
Copy link
Author

PhBeuthe commented Nov 1, 2021

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.

@bubnikv
Copy link
Collaborator

bubnikv commented Nov 1, 2021

round() was implemented with 3216448
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.

@PhBeuthe
Copy link
Author

PhBeuthe commented Nov 3, 2021

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.

@richgumy
Copy link

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

lukasmatena pushed a commit that referenced this issue Mar 31, 2023
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.
@lukasmatena
Copy link
Collaborator

Support for local and global variables was implemented in 2.6.0-alpha6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants