@RevoAlex please upgrade to 3.5.4 and test again.

@SanderLPFRG

thought of a workaround which is a macro to do the meshing and capturing the values in an array - so will give that a try at some point.

I haven't really explored SBC mode yet- will look at it too at some point.

So far I liked the non SBC mode compared to klipper - because start up is so much quicker

@psychotik2k3 you can test 'result' after the G30 command to test whether it succeeded. For example:

G30 .... If result != 0 abort 'Probing failed"```

@jay_s_uk thx a lot!

You are absolutely right.
And to my shame: got this information already last week, and forgot about it .. 🤦

@fcwilt Exactly what I needed to get past my mental roadblock. Some small code blocks doing just what I need. Now to refine the hardware to go with it. Most appreciated Gilly

@apak my bad, DWC 3.2.2

updated to 3.5.4 and works fine

@dc42 said in Having problems with M118 and variables:

@fcwilt are you running in standalone or SBC mode?

Standalone.

Frederick

I ended up solving this with a few lines of code and it works really well.
Step 1.Created a file called saved_var.g with a single line in it

global z_offset = 1

Step 2. Added the following line to the end of config.g

M98 P"saved_var.g" ;Load saved z offset

Step 3. In homez.g, I replaced my G31 code with

G31 P1000 X-32 Y0 Z{global.z_offset}

Step 4. I made a Marco with the following

set global.z_offset = global.z_offset - move.axes[2].machinePosition + 0.5 echo >"saved_var.g" "global z_offset = " ^ global.z_offset

Step 5. Reboot, Home All, bring the nozzle to the correct height using my gauge. Then run the macro.

Note: I used a metal ruler that happens to be exactly 0.5mm. If you use something else, then you need to replace the 0.5 with whatever thickness gauge you use.

@JADoglio said in M0 not behaving as I would expect it to..:

The bigger issue is how do I cancel or intercept the inherent M0 issued by Rep Rap so the firmware does not ALWAYS turn off the heaters at the end of the gcode execution for a print.

When M0 is executed within a print job (and in 3.6, when the end of the job file is reached without encountering M0), RRF runs file sys/stop.g if it exists, otherwise it uses the default behaviour which is to turn off all heaters. So you can change the behaviour by creating a stop.g file.

When M0 is run when the print is paused. RRF first tries to run sys/cancel.g, then if that isn't found it behaves as above.

@davidjryan thanks, we've established that it's specific to SBC mode. We've implemented and tested a fix in RRF, which will be in the next public build. Thanks for reporting this.

@jonathanbrent Since 3.6.0beta4 the functions "drop","find" and"take" have been implemented.
documentation is here:
https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands#functions
I have updated this github issue with an example of how to use them for date/time splitting into a string.

https://github.com/Duet3D/RepRapFirmware/issues/787#issuecomment-2658795794

T3P3 created this issue in Duet3D/RepRapFirmware closed allow date and time to be retrieved as individual strings/ints #787

@Perspective said in Synchronised Bed & Hotend, Homing not required after print.:

but in saying that i like what you have done although adding the auto fill temps from the slicer would add the cherry on top e.g. S[first_layer_bed_temperature] & S[first_layer_temperature];

You can easily achieve that by either moving the whole shebang to your slicer start gcode, or what I would probably do is set temps in your slicer start gcode but put the heaters on standby (or off).
Then in the macro, instead of using the target values derived from M291, you just use heat.heaters[n].active

@dc42
Ok, thanks a lot for your help. If I get it working, I'll post it on the forum for anyone who might be interested.

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!

@mikeabuilder I don't have multiple tools, so it's simple. I never thought we can use slicer for this. In my start script, it tries different area (4 side rects) with different clearances, and calls this macro at the first suitable place. I think you may need to find a larger area so that multiple head can purge at the same time?

var min_x = ... ... var xc = (var.min_x + var.max_x) / 2 var yc = (var.min_y + var.max_y) / 2 var clearance = 40 ; start from 40 / 2 var rect_x1 = 0 var rect_x2 = 0 var rect_y1 = 0 var rect_y2 = 0 while var.clearance > 1 if mod(iterations, 4) == 0 set var.clearance = var.clearance / 2 if var.clearance < 1 break set var.rect_x1 = mod(iterations, 4) == 0 ? var.max_x + var.clearance : move.axes[0].min set var.rect_x2 = mod(iterations, 4) == 1 ? var.min_x - var.clearance : move.axes[1].max set var.rect_y1 = mod(iterations, 4) == 2 ? var.max_y + var.clearance : move.axes[2].min set var.rect_y2 = mod(iterations, 4) == 3 ? var.min_y - var.clearance : move.axes[2].max if var.rect_x1 + global.NOZZLE_DIAMETER > var.rect_x2 continue if var.rect_y1 + global.NOZZLE_DIAMETER > var.rect_y2 continue if (var.rect_x2 - var.rect_x1) * (var.rect_y2 - var.rect_y1) < var.purge_area continue ; Project (xc, yc) into the rect set var.xc = min(max(var.xc, var.rect_x1), var.rect_x2) set var.yc = min(max(var.yc, var.rect_y1), var.rect_y2) ; Shrink the rect to purge_area, close to (xc, yc) and close to a square var xl = max(sqrt(var.purge_area), var.purge_area / (var.rect_y2 - var.rect_y1)) var yl = var.purge_area / var.xl set var.rect_x1 = max(min(var.xc - var.xl / 2, var.rect_x2 - var.xl), var.rect_x1) set var.rect_x2 = var.rect_x1 + var.xl set var.rect_y1 = max(min(var.yc - var.yl / 2, var.rect_y2 - var.yl), var.rect_y1) set var.rect_y2 = var.rect_y1 + var.yl echo "Purge in the rect " ^ {var.rect_x1, var.rect_x2, var.rect_y1, var.rect_y2} M98 P"0:/macros/purge_rect.g" A{var.rect_x1} B{var.rect_x2} C{var.rect_y1} D{var.rect_y2} break if var.clearance < 1 echo "no place to purge"