I can not count the places in my macros where I have to use code like

if !exists(global.xyz)
  global xyz = some complex expression
else
  set var.xyz = SAME complex expression

This is caused by that HARD restriction that the "set" command EXPECTS the assigned variable to exist. I even may do a

if !exists(var.xyz)
  var xyz = 0 ; or any fake value
set var.xyz = to the really wanted expression value

but I am not happy with this - for example the really set value type may not be numeric - but I know that this is an argument of esthetics.

My sugestion: (a) add another command - perhaps name it "assign" - that is a "set" but automatically will do a create of that variable before if neccessary.
Or (b) add a gcode like "Mxxx 0 / 1" which defines the behaviour of "set" on a global base.
Both options will not block to use the old coding but the will help to write cleaner and more secure macros.

@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 !

As the title says: I want to increase the font size in the macro code editor. My 4K monitor displays the source code lines quite small and I would appreciate if I could enlarge the displayed text to better readabilty.

Is this possible and where are settings to be done and saved?

As the title says: how can I access some part of the object model within a macro to handle some set of values (example: all global variables with names and values) programmatically?

My intention is to save all defined global variables after config.g execution and later be able to restore those variables after a 2nd M999 to allow some persistent value use. Currently I do it with a large macro where I am forced to use individual "global xxx ..." and "set global.xxx ..." commands with lots of chances to include missmatches and/or wrong assignments.

I also did not find a possibility to write and re-read json-formatted data to/from sd-card. any chance to get this?

@gloomyandy I am quite sure that it is not in that macro.

I commented out the macro calls in config.g and inserted their respective content instead (without the final M99 ;-)).
The config.g now stops somewhere in the configAxesRange coding in the area :

if !exists(global.ZaxisState)
  global ZaxisState = "unknown"         ; may be "Homed"        when Z axes endstops nicely triggered
                                        ; or     "HomedZero"    when G30 for Z = 0 in the center was done
                                        ; or     "Levelled"     when bed.g (for command G32) executed OK
                                        ; or     "MeshGrid"     when G29 has been done for the complete grid   
                                        ; or     "unknown"      again after resetting/failure happens
  if global.axesZnumber == 1
    if move.axes[2].homed && move.axes[3].homed
      set global.ZaxisState = "Homed"
  else
    if move.axes[2].homed
      set global.ZaxisState = "Homed"
echo "configAxesRange : set up axes, phase 3"
    
if !exists(global.XaxisMin)
  global XaxisMin     = -19.0
else
  set global.XaxisMin = -19.0
echo "configAxesRange : set X axis   range: " ^ global.XaxisMin

and the last log output is "configAxesRange : set up axes, phase 3" !
I use these if ... else sequence everywhere when I need global vars and it NEVER failed.

My only suspicion currently is that there is a limit of global variables reached while running the config.g (plus every such variable pending since M999/reboot which was somewhere created).

I have to study how to get some system info about used/avail memory (perhaps).

If this is the case for rel 3.50, its a roadblocker for me.

@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 !

@gloomyandy Hi, I can answer part:
1/ it is MB6HC with Raspi 3B which previously (before switching to 3.50-rc1) did run fine with 3.4.6 even for 9hrs prints.
2/ I did insert echo statements between every few lines and at some point there was no output in the log. Then I did add a global var at the begin of config.g like

global var test = 0
... some lines
set global.test = global.test + 1
... some more lines
set global.test = global.test + 2
... and so one , having some bits set in global.test while propagating through the config.g
... at the end of config.g I would add
echo "config . final state : " ^ global.test

I also created a small macro to be called independently from config.g to show global.test (bitwise).
With these helpers I was quite sure to identify that config.g stopped execution at some point midwise.
3/ yes, reproducible behaviour. I currently have the effect that in the middle of config.g I have a sequence

; ----------------- actually from line 151ff -----------------------------
if global.verboseExecution
  echo "config : further config settings in sub-macros ..." 

; Axis Limits
echo "config : call sub-macro configAxesRange.g ..."
M98 P"0:/sys/configAxesRange.g"                    ; set M561 & M564 S1 H1 at the end
echo "config : macro configAxesRange.g executed, result = " ^ global.configAxesRange
set var.configCompleteSubmacros = global.configAxesRange 

; Endstops
 
M98 P"0:/sys/configEndstops.g"
echo "config : macro configEndstops.g executed, result = " ^ global.configEndstops
set var.configCompleteSubmacros = global.configEndstops 
........

and the cosole output is

14.10.2023, 12:45:17 	M98 P"0:/sys/config.g"
14.10.2023, 12:45:17 	config : macro configAxesRange.g executed, result = true
14.10.2023, 12:45:17 	configAxesRange :       Therefore the real nozzle is somewhere at Z = -4.0 ... -5.0.
14.10.2023, 12:45:17 	configAxesRange :  NOTE that Z axis MAX is set to 345 to prevent early nozzle crashes.
14.10.2023, 12:45:17 	configAxesRange :  all axes min & max positions are initialized
14.10.2023, 12:45:17 	configAxesRange :  Z axis    : 0 : 345
14.10.2023, 12:45:17 	configAxesRange :  Y axis    : -22 : 312
14.10.2023, 12:45:17 	configAxesRange :  X axis    : -19 : 325
14.10.2023, 12:45:16 	configAxesRange : init running ...
14.10.2023, 12:45:16 	config : call sub-macro configAxesRange.g ...
14.10.2023, 12:45:16 	config : further config settings in sub-macros ...

where this console output is to be read reverse (i.e. last msg on top).

The last msg is "14.10.2023, 12:45:17 M98 P"0:/sys/config.g" but the expected output from the command "echo "config : call sub-macro configEndstops.g ..." and anything following is missing. Obviously config.g was stopped after that last visible echo and the next (almost immediately following echo) somewhere. I did comment out the assignement statement between these two echo statements, but no change.

Btw: I checked with Ultraedit the config.g (and all sub macros directly used) for proper indentation for If#s etc (I always use blanks instead of tabs) and no garbage after code lines which might confuse a code-interpreter. All files are NICE looking.

4/ Stripping down config.g to achieve something small might be difficult. First I will try again by replacing the macro call by directly inserting the complete macro code into config.g which will make it quite large! I hope that this does not create new problems

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!

I noticed in the changelog for 3.50-rc1 that there a some changes for the G10 command but did not see (?) mentionings about mandatory number format adaptions for parameter values...

In rel 3.4.6 I did a "G10 P0 X0 Y0 Z0" for tool 0 axes offsets as well as a subsequent "G10 P0 R0 S0" for tool 0 heater temps. This was working for me.

When running my config.g in rel 3.50-rc1 I stepped into the situation that the config was prematurely stopped without any messages with these commands (took me some longer debugging to isolate this).
When I change the first G10 to "G10 P0 X0.0 Y0.0 Z0.0" config works OK and executes the command.
Changing the 2nd command to "G10 P0 R0.0 S0.0" seems to not to help, but I continue to investigate...
I am wondering how macro execution just terminates without any messages ...

Are there plans to split up this command into separate variants as its current use may create confusion?

I just switched to 3.50-rc1 from previous 3.46 release and followed needed changes in my macros (change to macro parameters...) until I again was able to start my 3d printer.

But some spurious abort in a few macros (home*.g, G32 ...) forced me to look closer into my code to isolate a new behaviour in the (MB6HC in SBC mode with a PI 3B):
In several macros a use of a G1 move command for any axe(s), followed by a M400 command to wait for the movement completion and directly follwed by an access to the object model variables to check for the recorded coordinates was not always OK. The code looks something like:

G1 H1 Z{var.totalZ} F300           ; slowly touch again
M400                               ; wait for command completion
var currentZ = move.axes[var.axis].machinePosition

In Rel 3.46 (and before) this code worked fine and "currentZ" did reliably hold the actual coordinate (assuming that no hardware error had happened).

In the new release, the use of M400 obviously does NOT suffice to allow a secure access to the correct synchronized values in the move.axes[*].machinePosition values!
A workaround was to add another "G4 P500" after the M400 command to wait for another 500msecs (a guess which worked) ... but this is akward and just a strange workaround.

My questions:
1/ is this behaviour of 3.50 something that is already known and worked on?
2/ is there a solid and secure solution to access the machinePosition programmatically AND RELY on the correct value?
3/ if there is not a ready-to-use solution, is it feasible to look/wait for another command line M400/G4 (or a variant of it with special parameter(s)) that allows to "wait for the objectmodel to be in sync"?

I expect that some of you do not see the need for a solution to this behaviour of the software but believe me, I discovered that most of my problems to achieve good printing results were solved when I assured that the power up, initialisation and CALIBRATION of my printer were done with checking all possible missbehaviour in start-up macros and hardware-wrong-use/processing until EVERYTHING was checked and running properly. I may be a bit overcautious with my macro coding and error handling but more than 45 years of software development have proven me that this is the only way to have software that has a looooong lifetime and works as required. As long as the object model provides an access within the macro coding and is not only a documentary help to clearify how the RRF may work, a reliable access to its values is mandatory (or at least an indicator/semaphore flag should show if the model is in sync with the board/hardware or when it is not). I do understand that the RRF software is a multitasing thing where the object model is somehow handled independently fromt kernel GCode processing, but this is nevertheless something that can be handled properly!

I hope for some positive feedback

I am adding a small TOF sensor to get a "rough" (good estimate) of the current print bed in the given Z axis range to to add to my Z endstops in the max position. With it I will be able to to "see" if my print bed is near the hotend and I can directly use Z-Probing to get to the Z = 0.0 position with G30 (+bed.g) without first doing a round down of the print bed to reach the Z = max endstops and then move up again. But I guess that a direct G30 after board reset/power-on will not be allowed as the Z axis is not yet homed at this point in time?

Currently my homeZ.g macro will move the print bed down until the Z endstops trigger which seems (?) to set the object model variables move.axes[2].homed to TRUE and activate further movements accordingly.

My question: Can this "homed" state by set in software without using Z endstops or are the physical switches needed? I do know that there is a stall detection mode for axes movement but I do not want to use it (tested and it did sound terrible and btw I do not believe that it can be calibrated precisely for always the same Z coordinate reference when bumping into a mechanical end stop).

Confusing behaviour in DWC tool control area - maybe since I have updated to firmware 3.4 beta.
I have 2 entries in the tools area: T0 (hotend heating) and bed (print bed heating). When I select a temp > 0 for T0 - via the drop down menu - the selected temp will be shown, BUT the tool stays OFF. Selecting a tem > 0 for the printbed entry, the selected value will also be shown, BUT the bed heating automatically switches to state ACTIVE.
My 1st question: Why are these two entries behaving differently? I have a vague remembering that this was not in rel 3.2 (some time ago).
2nd question: When issuing (via command line entyr in DWC) a GCODE like M104 S200 T0, the tool entry will show the temp value AND switch to state ACTIVE!?
3rd question: Selecting a temp value = 0 is imho a possibility to swicth a too//bed heating OFF, but in DWC the value is acepted, but state stays ACTIVE. Does this really make sense?
4th question (finally): Is there a GCODE to set the state = OFF at all?

I have checked the DWC manual but could not find a clarification for my above questions. Please help me sort things out.