Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Make use of variables

    Scheduled Pinned Locked Moved
    Firmware wishlist
    14
    40
    6.6k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Googliolaundefined
      Googliola
      last edited by

      I'm afraid that is not possible. Or how would you suggest to just change the pin parameter in
      M280 P22 I1 S10 ;deployprobe.g
      without affecting the others? This does not just set the pin, but makes the servo move.

      1 Reply Last reply Reply Quote 1
      • OBELIKSundefined
        OBELIKS
        last edited by OBELIKS

        Hm, now I am confused.
        With M28 the commands are only written in to the specified file, you close the command with M29. There is no code execution. So this is the same as setting a variable. If you want to change it to default, you need to write the file again. There were some bugs with M28/M29, but they should be solved.
        Or if you want to change it only in deployprobe.g change it there. Why do you then want to have it in one place?
        Both use cases that you provided before are solvable like I suggested.

        P3Steel Toolson mk2 - Duet 2 WiFi --> RatRig V-Core with Duet WiFi 1.03
        Original Prusa i3 MK3S

        Googliolaundefined 1 Reply Last reply Reply Quote 0
        • Googliolaundefined
          Googliola @OBELIKS
          last edited by

          @obeliks please stop replying. No offense, but it cannot be done the way you think. M28 / M29 are NOT helping either.

          Would please someone else try to make a better point than I did. I know for a fact that it can't be achieved with "static" code. Unless you want to maintain a ton of macros - which is exactly what I want to avoid.

          1 Reply Last reply Reply Quote 1
          • elmoretundefined
            elmoret
            last edited by

            Good reading here:

            https://forum.duet3d.com/topic/5039/macro-variables/4

            tl;dr - g-code variables are not a simple matter to do, and unlikely to be implemented.

            What I'd recommend in your case is commenting everywhere there's a variable to change with some searchable word, then just doing a find operation and replacing all the relevant values.

            1 Reply Last reply Reply Quote 0
            • Googliolaundefined
              Googliola
              last edited by

              Thanks for the link. While loops and arithmetics are probably difficult to implement, I doubt that variables are hard to process. Why not 'just' do a search / replace if the first letter after the parameter is an @ or #? Is the storage of key / value pairs the tricky part? Or limited CPU resources or performance issues?

              I'm not familiar with RepRap dev (yet), but if someone @dc42 could point me to a good entry point, I would be willing to look into it.

              1 Reply Last reply Reply Quote 1
              • dc42undefined
                dc42 administrators @Googliola
                last edited by

                @googliola said in Make use of variables:

                It would be very handy to define variables in e.g. config.g for bed center, default speed, acc, jerk, pin for probe etc. Right now, changing bed center has to be done in many different places which makes things error-prone. I can think of multiple use cases.

                Suggestion:

                • set value of a simple variable like that: Mxx0 Kkeyname Vvalue.
                  To retrieve the value simply prepend an @: G1 X@keyname

                A facility to make this possible is already planned.

                Why do you need to change bed centre after initial configuration?

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                Phaedruxundefined 1 Reply Last reply Reply Quote 1
                • Phaedruxundefined
                  Phaedrux Moderator @dc42
                  last edited by

                  @dc42 I'm not sure if the goal is to change bed center after it's configured, or to use the location of bed center as a variable that could be referred to in other macros.

                  Honestly this is readily serviced by macros as it currently stands. The difference is between managing a collection of individual macros that serve a single function, either movement, or configuration, and managing a collection of variables in a single file like how Marlin does it. Yes variables gain some flexibility, and augment macros, but the current macro system largely satisfies what you're looking for.

                  There are some examples of config file sets that put a lot of work into parameterizing the whole thing, making system state switches by calling macros. This can be tedious to troubleshoot as you have to chase down the issues between macros to see how the system state is being altered through each step of the way. But it does allow for keeping sets of configuration variables in one place to edit, and then apply everywhere the macro is called.

                  Having $variables defined in one place would let macros become a lot more readable and you could refer back to the single variable definition file to see what is what. Currently the state of a gcode is always explicitly defined when it's called.

                  I'd be curious to see if people would find that more difficult or less difficult than it is now. And beyond the initial setup of the machine, you're not really editing those variables very often.

                  An example of a highly parameterized config set:
                  https://github.com/mzbotreprap/VORON/tree/master/Firmware/Duet/V2/daveidmx

                  Z-Bot CoreXY Build | Thingiverse Profile

                  1 Reply Last reply Reply Quote 1
                  • SupraGuyundefined
                    SupraGuy
                    last edited by

                    This does seem like something that is more useful for a machine that is in development, where you might change some parameter several times before you get the one that is the way that you want it.

                    I'm unlikely to be changing major things, and in some of these cases (Bed centre for one) it not only has to be changed for the printer, it also needs to be changed in the slicer, and there may be more than one slicer involved, so cases like this would require the slicer also be able to deal with the change.

                    Marlin configuration uses a .h file wiht a lot of #define statements. This then forces direct substitutions in the source code. (Forget about #ifdef/#ifndef statements, which get terrible for something like this.) A mechanism where you could have a .h file with:

                    #define BED_X_CENTRE 110.0
                    #define BED_Y_CENTRE 137.5
                    #define BL_TOUCH_PIN 22
                    Then, as a part of your gcode

                    G1 BED_X_CENTRE BED_Y_CENTRE 5.0
                    M280 PBL_TOUCH_PIN I1 S10

                    The pre-processor would translate this to

                    G1 110.0 137.5 5.0
                    M280 P22 I1 S10

                    Of course your slicer would have to be able to put out what is basically a non-numeric and pretend that it is a numeric. Might be easier with macros, or the .g files that the Duet keeps on-board, but honestly, I think that it's probably more trouble than it's worth, but then I suppose it depends on how many macros you make/use regularly, and how many count on things that you might change.

                    I have a few macros right now that change the Z probe definition, since mine isn't working correctly, so I have a few macros that set the probe to a type "0" (No probe installed) and then set it back to a type "8" (digital, unfiltered) when they've done the job that I ask for. I suppose that having some global variables (Or #define substitutions) to re-set the probe might be handy for this, but I'm definitely not planning on needing these macros for long-term, as I intend to just fix the actual problem so that the probe will just function as defined in the config.g file, which I feel would be a better solution.

                    It is, however true that the defined variables might be easier to read in the .g files, later when you can't remember what does P8 mean on the M558 command, as opposed to P0. Having:
                    #define Z_PROBE_NONE 0
                    #define Z_PROBE_BLTOUCH 1
                    #define Z_PROBE_DIGITAL 8
                    #define Z_PROBE_SPEED 600
                    #define Z_PROBE_DELAY 0.8
                    then in config.g

                    M558 PZ_PROBE_DIGITAL H8 FZ_PROBE_SPEED I1 T9000 RZ_PROBE_DELAY Z1

                    Easier to read, probably doesn't even need a comment anymore... but probably easier to comment. I mean the point of config.g is to set up something that sets the configuration all in one place, abstracting that to another place where the configuration is... Who watches the watchers?

                    Lead screw driven printer, powered by Duet 2 Wifi
                    MPCNC powered by Duet 2 Wifi
                    CoreXY printer driven by Duet 3 6HC
                    LowRider CNC powered by Duet 2 Wifi

                    1 Reply Last reply Reply Quote 1
                    • dc42undefined
                      dc42 administrators
                      last edited by

                      IMO it's better to define the bed centre as X=0 Y=0 no matter what type of printer you have. That's what I do on my Cartesian, Delta and SCARA printers. It is one of the things that allows me to print the same GCode files on all of them.

                      Duet WiFi hardware designer and firmware engineer
                      Please do not ask me for Duet support via PM or email, use the forum
                      http://www.escher3d.com, https://miscsolutions.wordpress.com

                      1 Reply Last reply Reply Quote 3
                      • Googliolaundefined
                        Googliola
                        last edited by Googliola

                        @phaedrux said in Make use of variables:

                        There are some examples of config file sets that put a lot of work into parameterizing the whole thing, making system state switches by calling macros. This can be tedious to troubleshoot as you have to chase down the issues between macros to see how the system state is being altered through each step of the way. But it does allow for keeping sets of configuration variables in one place to edit, and then apply everywhere the macro is called.
                        Having $variables defined in one place would let macros become a lot more readable and you could refer back to the single variable definition file to see what is what. Currently the state of a gcode is always explicitly defined when it's called.

                        That's one reason to have variables. Less effort, more control over system state (as it is defined in one place). and better readability.

                        I'd be curious to see if people would find that more difficult or less difficult than it is now. And beyond the initial setup of the machine, you're not really editing those variables very often.

                        Well, having many parametrised macros is certainly quite messy the bigger the number. And if someone does not like to use variables then they could still use the existing approach.

                        A facility to make this possible is already planned!

                        @dc42 can't wait to use it. Bedcenter is just an example, where it variables would be helpful. Running a z-probe repeatabilty test would be much easier to implement too. Let's assume I want to repeat the test in other places than bedcenter (to spot a mechanical issue). Again, I would need to create yet another macro to set the location of the probing to take place. With vars, one could

                        ; StartProbeLocationMacro.g:
                        Set probing location coords $X $Y at bedcenter
                        Run repeatProbe.g and record results in log file
                        Set probing location coords $X $Y at front left
                        Run repeatProbe.g
                        Set probing location coords $X $Y at front right 
                        ......
                        Reset probing location to default state $defaultBedCenterX $defaultBedCenterY
                        
                        ; StartProbeSpeedMacro.g:
                        Set probing feedrate, speed, height
                        Run repeatProbe.g
                        Change probing parameter
                        Run repeatProbe.g
                        ....
                        Reset probing params to default state
                        

                        This does seem like something that is more useful for a machine that is in development

                        @SupraGuy Absolutely. Either to setup and fine tune the configuration during development, but also to perform quality control upon setup of a new machine or to run maintenance tests.

                        As for the changes in the slicer as you pointed out:

                        G1 BED_X_CENTRE BED_Y_CENTRE 5.0
                        M280 PBL_TOUCH_PIN I1 S10

                        Hmmm, true. I don't see a use case for that - yet. Both lines are likely to bo into the start or end code scripts. Plus, that could just as well be done with macros containing the variables. But then how can you instruct your slicer to run a macro (apart from onstart, onlayerchange etc events)

                        As for the #define statements, I think the "gcode everywhere" approach is a MUCH better fit, due to adherence to coding standards and coherence.

                        I think it is important to point out that the value of the variables can be altered by
                        Mxx0 Kkeyname VNewValue

                        Thanks everyone for your input!

                        1 Reply Last reply Reply Quote 2
                        • Phaedruxundefined
                          Phaedrux Moderator
                          last edited by

                          @Googliola Check this out. I think it will deliver very close to what you're after.

                          https://github.com/token47/duetcfgen created by @token47

                          To quote:

                          duetcfgen
                          Duet Config Generator

                          What this is NOT:

                          • attempt to negate the RRF "All Gcode" filosophy
                          • an attempt to create a Configuration.h (a la Marlin) for RRF

                          What this IS:

                          • a way to quickly edit all the files on the same place
                          • a way to use variables for repetitive information
                          • a way to use "vim" on my linux instead of the web editor

                          It will:

                          • compile a template, generating all the individual files
                          • do variable replacement while compiling
                          • upload all of them to the duet using ftp
                          • optionally will reset the duet after uploading
                          • can potentially download a backup of all files before uploading (currently broken)

                          Z-Bot CoreXY Build | Thingiverse Profile

                          1 Reply Last reply Reply Quote 0
                          • Googliolaundefined
                            Googliola
                            last edited by

                            @Phaedrux Thanks for the link. Indeed a simple and nice workaround. Unfortunately, I'm a Windows (8.1) and not a Linux person. But I starred the project and will check back.

                            1 Reply Last reply Reply Quote 0
                            • Danalundefined
                              Danal
                              last edited by Danal

                              There is no "right or wrong" answer to having (or not) variables in G-Code.

                              At the same time, the NIST standards writers for G-Code chose "not". There is a fairly deep philosophy behind this: G-Code is/was intended to be a machine control language. It is philosophically not intended to be a programming language.

                              Anyone who's coded, even the simplest languages, knows that programming languages that have conditional execution and variables can have many emergent behaviours. This is highly undesirable when controlling machines that can break themselves, break parts, and injure operators.

                              G-Code is specifically limited to "deterministic" behaviors. Even allowing math on a single line is a bit debateable in this philosophy; it did make it into the final standard. Nonetheless, people tend to avoid it in truly deterministic G-Code.

                              The assumption is that all conditional execution, repetition, etc. will be accomplished in the generator of the G-Code, not the G-Code itself.

                              Again, no right/wrong here, but knowing the background philosophy may help explain why things that seem desirable in G-Code may have been intentionally excluded.

                              Delta / Kossel printer fanatic

                              1 Reply Last reply Reply Quote 2
                              • dc42undefined
                                dc42 administrators
                                last edited by

                                This week I have been designing a mechanism for conditional and looping GCode with variables. I will publish the proposal soon.

                                Duet WiFi hardware designer and firmware engineer
                                Please do not ask me for Duet support via PM or email, use the forum
                                http://www.escher3d.com, https://miscsolutions.wordpress.com

                                timcurtis67undefined 1 Reply Last reply Reply Quote 2
                                • timcurtis67undefined
                                  timcurtis67 @dc42
                                  last edited by

                                  @dc42 said in Make use of variables:

                                  This week I have been designing a mechanism for conditional and looping GCode with variables. I will publish the proposal soon.

                                  Sweet! I've been waiting for this feature.

                                  1 Reply Last reply Reply Quote 1
                                  • SupraGuyundefined
                                    SupraGuy
                                    last edited by

                                    @Googliola : For what it's worth, this seems to be a collection of shell scripts and python code. There is a Windows port of bash to execute the shell scripts, and python can be run on just about anything. You MIGHT need to do some translation of some of the different locations and so forth, but I see little reason why this can't work in a Windows environment, if you're willing to put up with some teething pains and see what needs to be changed.

                                    @Danal : Certainly fair point, until you get things like configuration files and macros in a "gcode everywhere" the idea that the generator should be doing all of the work is a good one. In this case though since the configuration files, and presumably most of the macros are going to be (for the largest part) hand-coded, with the exception of things like the RepRap Configuration Generator, it gets to be a bit of a pain.

                                    I was thinking about the things that I was talking about above, and I realized that gcc includes a facility for running things through its preprocessor without trying to run them through the actual compile process. It throws certain errors, as it expects C/C++ style comments, and not ones with a semicolon prefix, but that isn't too hard to handle.

                                    So for example, I have a file test.h which contains the following:

                                    #define DEFAULTPROBE P8 H8 F780 I1 T9000 R0.8 Z1
                                    #define MESHGRID X30:190 Y35:235 S20
                                    #define PROBEOFFSETS X0.0 Y0.0 Z-0.1

                                    Then there's a file called manualprobemacro.c (The .c is just more convenient for the preprocessor)

                                    ; manualprobe.g manually define a mesh grid without needing to probe manually 90 times

                                    #include "test.h"

                                    M558 P0
                                    G31 X0 Y0 Z0
                                    M557 X35:185 Y25:250 S75
                                    G29
                                    M558 DEFAULTPROBE
                                    G31 PROBEOFFSETS
                                    M557 MESHGRID

                                    Then I run gcc -E manualprobe.c

                                    I get some returns from gcc on stderror, since this really isn't C code, but on stdout I get

                                    4 "manualprobe.c" 2

                                    M558 P0
                                    G31 X0 Y0 Z0
                                    M557 X35:185 Y25:250 S75
                                    G29
                                    M558 P8 H8 F780 I1 T9000 R0.8 Z1
                                    G31 X0.0 Y0.0 Z-0.1
                                    M557 X30:190 Y35:235 S20

                                    Now I can probably do something with awk to fix or remove things like the # comment lines. I can probably have it redirect the .c files to .g versions which can then be uploaded en masse to the macro directory. I can probably set up a makefile so that I can just do something like make macros.

                                    Maybe if I ever think that I'll have more than a dozen such macros, I might go through the trouble of setting it up.

                                    Lead screw driven printer, powered by Duet 2 Wifi
                                    MPCNC powered by Duet 2 Wifi
                                    CoreXY printer driven by Duet 3 6HC
                                    LowRider CNC powered by Duet 2 Wifi

                                    1 Reply Last reply Reply Quote 1
                                    • dc42undefined
                                      dc42 administrators
                                      last edited by

                                      I've put a draft proposal at https://docs.google.com/document/d/1urmNjfs2QXUZ2aFeWu6LOaj78cyfNeYZ0ofMJoQsZVk/edit?usp=sharing. It's lacking some detail, in particular the object model, but it should be sufficient to use as a basis for discussion.

                                      Duet WiFi hardware designer and firmware engineer
                                      Please do not ask me for Duet support via PM or email, use the forum
                                      http://www.escher3d.com, https://miscsolutions.wordpress.com

                                      wilrikerundefined 1 Reply Last reply Reply Quote 5
                                      • wilrikerundefined
                                        wilriker @dc42
                                        last edited by

                                        @dc42 I personally would already been happy with just variables. Anyway very good proposal.

                                        Only I found one thing missing. At the requirements you state that variables need to be type-safe but in their declaration the type is only inferred from the value (at least nothing is stated). It might be safer to have the declaration include the type. But I know that these makes it more complicated and inconvenient.

                                        Manuel
                                        Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                                        with probably always latest firmware/DWC (incl. betas or self-compiled)
                                        My Tool Collection

                                        1 Reply Last reply Reply Quote 0
                                        • Googliolaundefined
                                          Googliola
                                          last edited by Googliola

                                          @dc42 I haven't had time to properly review your proposal yet - will do over the weekend. First of all: Wooooohooo, you are the most responsive dev I have met so far. Big up for your effort!!!! And in contrast to (an-)other dev of hard- & firmware, you are super friendly and quick at solving customer needs! I feel like I found the right place to base my printer kit on!

                                          At first sight, I would kind of stick to the Gcode-everywhere paradigm, when it come to the simplest of all - setting and reading a variable. But as I can't read your mind 👨‍🎓 but suspect that the RRF object model you have in mind is separate from the Gcode processor (or for any number of another reasons), the var approach seems to be unnecessarily stray from your paradigm.

                                          Maybe M123 Kkeyname Vvalue is a better approach? Where KeyName could be retrieved by just adding a designator like @ or $?
                                          Also, M123 could be extend by the data-type such as M123 KmyInt V3.1412 Dfloat would be reflected?

                                          On another page, but related: In terms of usability of a specific product (like the e3d tool-changing printer), it would be tremendeously helpful to be able to read the current setting of commands like M558, M584 and the like by issueing a M558 A? (and get the value of A back) or M558? to get the values of all parameters back (either as string or as a named array - preference for the latter of course 😉 )

                                          One major use-case is the way you could set your z-probe offset with G31 Z$measuredZmean
                                          The way I do it now is by running @Phaedrux script he provided here but with the above suggestion, there would be no need to read the mean value in the console - just get the mean value, store the value by M123 KtriggerHeight VmeasuredZmean and set triggerHeight value by G31 Z$measuredZmean
                                          Except for the paper-trick, no further manual action would be required....

                                          Or think about how endstops could be used (again for tool-changing) if I had a simple microswitch, I could retrieve the state of and them take according action - like if T1 parked or is a tool loaded.

                                          dc42undefined 1 Reply Last reply Reply Quote 0
                                          • dc42undefined
                                            dc42 administrators @Googliola
                                            last edited by dc42

                                            @googliola, thanks for responding.

                                            At first sight, I would kind of stick to the Gcode-everywhere paradigm, when it come to the simplest of all - setting and reading a variable. But as I can't read your mind 👨‍🎓 but suspect that the RRF object model you have in mind is separate from the Gcode processor (or for any number of another reasons), the var approach seems to be unnecessarily stray from your paradigm.

                                            The object model is just a way of referring to all the machine parameters, so it's more or less independent of the syntax of the additional commands in my proposal.

                                            Maybe M123 Kkeyname Vvalue is a better approach? Where KeyName could be retrieved by just adding a designator like @ or $?
                                            Also, M123 could be extend by the data-type such as M123 KmyInt V3.1412 Dfloat would be reflected?

                                            One concern is readability. GCode isn't very readable because you need to remember what each code does. So for things like loops, conditional blocks etc. I think it makes more sense to use keywords. The question then arises, should we also use keywords for things like setting variables, for which there isn't an existing GCode command?

                                            On another page, but related: In terms of usability of a specific product (like the e3d tool-changing printer), it would be tremendeously helpful to be able to read the current setting of commands like M558, M584 and the like by issueing a M558 A? (and get the value of A back) or M558? to get the values of all parameters back (either as string or as a named array - preference for the latter of course 😉 )

                                            That will be possible, because all configuration variables will be included in the object model.

                                            One major use-case is the way you could set your z-probe offset with G31 Z$measuredZmean
                                            The way I do it now is by running @Phaedrux script he provided here but with the above suggestion, there would be no need to read the mean value in the console - just get the mean value, store the value by M123 KtriggerHeight VmeasuredZmean and set triggerHeight value by G31 Z$measuredZmean

                                            Yes, that or something similar will be possible.

                                            Duet WiFi hardware designer and firmware engineer
                                            Please do not ask me for Duet support via PM or email, use the forum
                                            http://www.escher3d.com, https://miscsolutions.wordpress.com

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Unless otherwise noted, all forum content is licensed under CC-BY-SA