IF statements in RRF must be indented, so none of the statements you have will be working.

https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands#conditional-construct

It looks to me like to me IF statements are from a slicer START G-Code section.
They may be workable there, but only the M140 commands should end up in your job g-code.

@mikeabuilder said in WHILE loop acts like an IF statement:

if there is some lag in getting the object model updated, it could give the result you are seeing.

There is no lag in reading OM values within macros when running in standalone mode. Even in SBC mode there is usually no lag because the SBC asks RRF to evaluate expressions.

I think the current "RRF-ish" way to store parameters would be to write each to the file as a gcode statement that will create the value in a global variable.

So if you have three calibration values you need to store : calib1 = 10, calib2 = 20, calib3 = .2
You could write them in a file called saved_values.g

echo >"saved_values.g" set global.calib1 = 10 echo >>"saved_values.g" set global.calib2 = 20 echo >>"saved_values.g" set global.calib3 = .2

Note the use of a single ">" on the first line which overwrites any previous file contents and ">>" on the others that appends a new line to the file.

To read in the values, you first create the global variables, then run the macro. This code is either in your config.g or is run when you want the saved values:

global.cabli1 = null ; creates the variable and assigns it a dummy value global.cabli2 = null global.cabli3 = null M98 P"saved_values.g"

In the M98 command, it's ideal to include the file location (something like 0:/sys/saved_values.g if the macro is saved on the local SD card and is in the "sys" directory)

@machinemark said in Seemed like daemon.g was not starting.:

@machinemark

Thanks for the clarification.

No problem.
There's more documentation specific to daemon.g here and here

You will also find plenty of instances of it;s use on the forum.

Once you're satisfied it''s working correctly, mark you post as a question and then mark it solved.

Thank you both for your responses.
@dc42 this has helped me out enormously. I think you're right on the money with:

@dc42 said in Reading Multiplexed Analogue Inputs:

a G1 command followed by a M42 command followed by a command to read an input, the command to read the input is likely to take place before the M42 command.

I went back and tested a few things and found the above to be true. The solution I came up with was to set the mux select pins with M42 in daemon.g and then idle in a while loop until they had changed according to the object model:

while((state.gpOut[10].pwm!=var.muxInputs[0])&&(state.gpOut[11].pwm!=var.muxInputs[1])&&(state.gpOut[12].pwm!=var.muxInputs[2])&&(state.gpOut[13].pwm!=var.muxInputs[1])) continue G4 P250 set global.muxValues[iterations] = sensors.analog[2].lastReading

I found that a 250ms delay was still required to get consistent results, but this is much better than the 600ms I had before.
I also tried using an M400 after setting the mux pins, but unsurprisingly, this caused to print to stutter as the move queue emptied and refilled again.

Thanks again for all your help. Keep up the good work!

@droftarts Thank you for your reply. I should have added more details; the reason I don't have the R parameter set to 0 is that I don't want to trigger a driver error just because the servo gets disabled. For example, I have safety switches on the printer doors that cut power to the servos when the doors are opened. So I suppose that I really only want the driver error to occur when a movement is commanded, but the servo is not enabled.

Thanks!