Using macro calls in config.g

hlwerschner

While adapting my config settings (a main config.g and several sub-macros called from within config.g) for known rel 3.50 changes, I added another small macro to intialize some global variables ...
I did some coding like

; Configuration file for Duet 3 6HC (firmware version 3.4.1)
; executed by the firmware on start-up  

; General preferences
M550 P"xxx"                                        ; set printer name
; not with SBC : M552 S1                           ; enable network
; not with SBC : G4 S1                             ; just wait a second
M575 P1 S1 B57600                                  ; PanelDue
M669 K1                                            ; select CoreXY mode
G90                                                ; send absolute coordinates...
M83                                                ; ...but relative extruder moves

M98 P"0:/sys/configCompleteInit.g"                ; reset some global.config*** variables

; Network --- not used because of SBC attached
; M552 P0.0.0.0 S0                                 ; disable network
; M586 P0 S0                                       ; disable HTTP  (we use the SBC mode)
; M586 P1 S1                                       ; enable FTP
; M586 P2 S1                                       ; enable SSH with T parameter
; M586 P2 S0                                       ; disable Telnet

....

Running this config.g terminated it very early (without any messages) or resumed after configCompleteInit.g call SOMEWHERE in the config.g and produced strange results before terminating (I added LOTs of echo commands into the config.g to "trace" its execution but never got the same runs!

I finally commented the macro call out and simply copied its body after the call in config.g and these errors WHERE GONE! I tested the sub-macro separately (its really trivial) and was sure that it did not itself produce any error situation (see my remark copying its content directly into config.g)

So my question: Is there some limitation in rel 3.50 to disallow macro calls in early execution of config.g ? Please note, that I use several macro calls later (around lines 100ff including a large comment-lines block) and these have been OK and are OK in 3.50 also.

Its a bit weird but I am worried about macro aborting (!?) without any messages on the console. Just end-of-execution and no messages on the console. Such runs were reproducible!

fcwilt

@hlwerschner

Just FYI you can call .G files in the SYS folder from other files in the SYS folder with just M98 P"filename.g" - you don't need to include 0:/sys/

And remember you cannot "re-create" global variables that already exist - that will generate an error and the file trying to do so will terminate.

BUT I don't use 3.5.x since it has not been released, as far as I know.

Frederick

hlwerschner

@fcwilt Ty for your tipps.
1/ Yes, I do know this. Its simply a coding copy/paste thingy which started when I started to use this "macro-language" or whatever we call it.
2/ Yes, and I hate it as it creates ugly (but SAFE code) to do:

if !exists(xxx.vvvvv)
  xxx vvvvv = value
else
  set xxx.vvvvv = value

This is one of the reasons why I have sub-macros which only do the creation/reuse of global variables which I need to communicate values between macros (sorry: no return values from macros, no parameters "by-name" etc). I have accepted that this macro-meta-coding does not make macros to "good programming"
3/ I understand your statement about 3.50 and its current state. I also follow that road for most of my working with 3d printing. But the urge to learn new usage of the great Duet3 hardware and looking into a interesting implementation of input-shaping ... and finally the reason that I do not have needs to use my printer for some "real" work can push me sometimes a bit too far.

I have to admit that this new releases creates far more trouble than all other versions I had before (I started some years ago with a DUET 2 WiFi board, switched later to the MB6HC which is great and promises to allow 3-Z-axes expansion more easibly and now I sit on that board and wait for some features that I would like to use

But ist for learning new stuff even as a retired guy with 75 years !

fcwilt

@hlwerschner

I have one create_globals.g file with (currently) 73 variables.

I "refuse" to use the "if exists" approach, as you mentioned it is ugly. I just -re-boot if needed - which is rare - most of the variables are actually there in lieu of constants.

The "meta" features have greatly expanded what can be done and I am taking advantage of it. I now have 70 some .G files.

Editing those in the DWC became a problem so I now use a text editor which supports FTP. Projects (which are a batch of related files) work the same when using FTP, just as if they were on the local computer drive. The files on the Duet are downloaded into the editor. When you edit one and save it, the editor FTPs it back to the Duet. You can even configure the FTP connection to maintain backups on the local drive and/or on the Duet.

Being able to use all of the features of the editor (multi-file search and replace is great) has made working with the multiplicity of .G file much easier.

Again, just FYI.

Frederick

Mr Yod

@hlwerschner said in Using macro calls in config.g:

So my question: Is there some limitation in rel 3.50 to disallow macro calls in early execution of config.g ? Please note, that I use several macro calls later (around lines 100ff including a large comment-lines block) and these have been OK and are OK in 3.50 also.

Its a bit weird but I am worried about macro aborting (!?) without any messages on the console. Just end-of-execution and no messages on the console. Such runs were reproducible!

Calling macros I don't know, but I found an odd behavior with local variables in config.g in 3.4.6 (as I described here: https://forum.duet3d.com/topic/34505/possible-bug-with-local-variables-use-in-config-g ), so maybe it's a similar situation and at this point I'd say: initialize variables only at the end of config.g...
EDIT: no, that was due to an error by me: I forgot to use var.var_name
So at this point I'd say: no problem as long as they are declared correctly.

BTW: I'm with you with the uglyness but safe(tiness) of if !exists and I'm a bit more extreme

var val = <var value>

; val
if !exists(global.value)
	global value = {var.val}
else
	set global.value = {var.val}

First I have the values declaration block in local variables only, then the global creation/changing for global values, so that I don't have to put the same value twice for every global variable (and scroll to find it when I want to modify it, and remember to modify it twice and not making typos...); the if !exists block is just crtl+c - ctrl+v and, once made (and made sure it's correct), it doesn't have to be touched ever again.

@hlwerschner said in Using macro calls in config.g:

switched later to the MB6HC which is great and promises to allow 3-Z-axes expansion more easibly and now I sit on that board and wait for some features that I would like to use

Thatis relatively easy: there are macros here on this forum for 3-Z autolevel.