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.

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.

@o_lampe Hi, I am wondering if your primary mentioning of a "descriptive language" to control NeoPixels/Dotstar has seen any progress? I am currently adding some stripes to my machine and finally have decided to use an arduino to do the work of controlling the stripe colors and link the arduino via serial comm to a client app (for the time being, I test all stuff with the PC, but there is no problem to attach that small arduino to the Duet3 SBC (Raspberry 3+).

So far, what is that LSD doing

I had a look into the Duet3 schematics and verified that this board only uses 6 connections (5V are to be provided to the SBC from separate supply) taken from the 2x13 flat cable. If I would use just a small 6-wire cable with proper shielding, is it OK the replace that larger flat cable and free all unused GPIO pins? And what is the max length for this SPI connection?

As the title says, I would like to know if someone has tested a Duet3 mainboard with a Raspberry PI400 (that thing with keyboard and better cooling inside) as a SBC? The RPI400 has the same 40-pin connector as a regular Raspi 4 and I use one as a Linux frontend for the DWC browser with my Duet2 Wifi and this works just fine. But now I am upgrading to the Duet3 and am just considering to reuse as much as possible.

@owend Yes, that is the way as I am doing it now...but as I tried to state, there seems to be room for improvement
Btw: this solutions creates a lot of global variables - in different (nested) macros - that "exist" too long , use up precious memory...and are a non-esthetic way to trivially communicate a "result" from a called macro back to the caller! So far my first msg is more of a proposal for improved meta command handling than a mere question. OK, lets wait for RRF 3.5

I did a search for "M98 result" and did not find something that matches. So my question is: Is there a way to receive a result from a macro execution (done via M98 P"...") back to the calling line of code?
I imaging that this would be similar to that "iterations" variable in loops which has a very specific context and lifetime. Its use would be :

M98 P"some-macro.g" ...
set var.gotValue = result

where the variable "result" is provided directly after that M98 command. It may get its value inside of the called macro "some-macro.g" when a explicit M99 is executed:

; this is my macro "some.macro.g" with a lot of embedded commands ...
M99 200  ; return with "result" = 200

I do not know if this is very complicated to implement on basis of the current RRF 3.4, but I would be even happy if I could get a simple "true" / "false" back from a M98. As far as I have understood the "abort" command, it willl kill the complete chain of macros executed and can not be used to return with a "failed" indicator to its direct calling macro?!

@dc42 Ah yes, that clarifies. So the position of that axis may be any value.

The documentation simply states that the value of "move.axes[n].homed" reflects the "homed state" of that axis. Does this mean:
(a) At some time BEFORE inspecting this value, there was a gcode "G28 X" for n = 0 resp G28 Y or G28 Z done which caused a homing to be executed somwhow.
or
(b) the respectiv axis is "homed"
i.e. its current position == move.axes[n].min
I am a bit unsure what "homed" really means ... and how long it is valid. The only experience I have is that M999 or a gcde that stops axis motors, will set homed = false.
I have several macros where I assumed that homed = true implies that the current axis position = at the min axis position AND that the endstop switch would be triggered /when defined) for the min pos).
Is it perhaps better to check for the endstop state also?

@owend Oh yeah, I have overread this! Thank you...I had expected this to be a "function" like length() or var.length ...
mea culpa for to scanning the docs more intensively.