This is really turning out to be the right answer. One of the benefits of using the work offsets is that they are one of the few things that can be stored with M500!

(I thought I could store things from the object model by exploiting M28/M29. But no expressions between those commands gets evaluated, so you can't store the result of an expression.)

So I explained above how to store things by writing gcode to a file you run on startup. But what if you want to store something in the work offsets during operation of the printer? You have a tool number, say 2, and you need to write a gcode expression with an axis letter, G10 L2 P5 Z.... How do you get that Z?

Well, you can write an if block to do that but that code is pretty long and you wouldn't want that cluttering up your all your macros. So I wrapped that up into macro itself so I can re-use it everywhere I need to store something. The trick is we don't have a way to pass variables into macros yet. So I just write the tool #, value to store and desired coordinate system index into coordinate system #9. Basically coordinate system #9 is now the stack for my program:

; copy_var.g ; ; this macro copies a variable from the temporary variable slot and stores it in the requested slot for the specified tool: ; ; How To use: ; ; G10 L2 P9 X{state.currentTool} Y{value_to_store} Z{target_coordinate_system_index} ; M98 P"/macros/scripts/copy_var.g" ; ; Inputs: ; ; move.axes[0].workplaceOffsets[8] - tool number to store the value for ; move.axes[1].workplaceOffsets[8] - the value to store ; move.axes[2].workplaceOffsets[8] - the coordinate system number to store it in if move.axes[0].workplaceOffsets[8] == 0 G10 L2 P{floor(move.axes[2].workplaceOffsets[8])} X{move.axes[1].workplaceOffsets[8]} elif move.axes[0].workplaceOffsets[8] == 1 G10 L2 P{floor(move.axes[2].workplaceOffsets[8])} Y{move.axes[1].workplaceOffsets[8]} elif move.axes[0].workplaceOffsets[8] == 2 G10 L2 P{floor(move.axes[2].workplaceOffsets[8])} Z{move.axes[1].workplaceOffsets[8]} elif move.axes[0].workplaceOffsets[8] == 3 G10 L2 P{floor(move.axes[2].workplaceOffsets[8])} C{move.axes[1].workplaceOffsets[8]} else abort ; if you pass -1 you call at the wrong time!

Now that is solved I can combine it with M500 and I give you per-tool baby stepping adjustment that persists between reboots:

call this in tfreeN.g

; save_babystep.g ; writes the baby stepping value into the work offset 7 and then stores it with M500 G10 L2 P9 X{state.currentTool} Y{move.axes[2].babystep} Z6 M98 P"/macros/scripts/copy_var.g" M500

and call this in tpostN.g

; restore_babystep.g ; restore the absolute babystepping value from its storage slot M290 R0 S{move.axes[state.currentTool].workplaceOffsets[5]}

Then call M501 at startup before you write any config values as described in the post above.

alt text

😸 🍻

Thanks for reporting this problem, I'll fix it in the next version.

@gloomyandy
Thanks for confirmation

@DaveA I already do something similar. You can use the workplace coordinates to same information and then calculate from.
I mainly use this when probing on my CNC. Examples can be found here https://forum.duet3d.com/topic/19698/rrf3-2-request-to-enable-g43-g44-tool-height-offset?_=1609278343985

@dc42 Thanks David this isn't a huge problem, only an aesthetic one. Also thanks on the development roadmap for RRF! I can't wait to try a future input shaper implementation!

I think I got it working , I made a couple of wrong assumptions, most importantly offset Z needs to be -0.2 is the second head is 0.2mm higher.
thx for your help

@dc42

What do you Think about 2.?
After the Board is repowered, It has forgotten the previous loaded filament in Tool 0.

An alternative is to use G32 and in bed.g put:
M561 ; clear any bed transform
G29 S1 ; load current heightmap.csv
if result > 1 ; if no heightmap.csv, make one.
G29 S0

I was able to get a basic function but would like to add a bit more ability would it be possible to do an if statement with a while this is what I was thinking but have not been able to get to work

if sensors.analog[2].lastReading > 65
m117 pinda to HOT cooling down
while sensors.analog[2].lastReading > 65
M106 S100
G1 Z10 F1000.0
G4 S1
M99
elif sensors.analog[2].lastReading < 62
while sensors.analog[2].lastReading < 62
G4 S1
M99)

What firmware version are you using and can you share a sliced gcode file so we can see your print settings.

How fast are you printing?

What kind of printer is this?

Move and Axes are part of the object model which is used to query various parameters

https://duet3d.dozuki.com/Wiki/Object_Model_of_RepRapFirmware

Think of it like a tree or a flow chart.
Each object may branch out into other objects.
Where it's necessary to identify the same parameter on many tools or axes, each one is allocated a unique identifier in an array. Arrays are surrounded by square brackets [ ]

In the case of move.axes[0].min
It will give the the axis minima you set for axis 0. (X) in your config.g using M208
move.axes[1].min would be Y minima.

You can the use curly brackets { } to allow you to do math based on the values.

This allows you to write macros which will automatically update if you were to change the value in M208 for example

So i have messed with it a bit more trying to use some while loops.

pretty much this

while !sensors.filamentMonitors[0].filamentPresent G1 V1 E1 F1000

and that actually works okay up to a point. the loading it smooth and continues. but the problem seems to be that it might be buffering some moves because it will continue moving a bit after triggering the filament monitor.

i then tried adding a G4 P100 or a M400
this makes it so that it triggers at the correct time but makes it run slow and chopping as it moves 1 mm stops, moves 1 mm, stops and so on.

I just realized the page you linked is for Duet3. I can't find similar for Duet2.

It is for a school project. G-code analyzer that I'm creating does few other things too such as looks for faulty values in the code.

Try a different frequency? M950 Q

G10 works for setting temp, but that's not my goal. My goal is to make a pause.g script that automatically takes the temps of the 4 tools, stores them, and sets them to 0, so I can unpause with the temps automatically going back to what they were.

It is a reset:M122 B122
Diagnostics for board 122:
Duet TOOL1LC firmware version 3.2-beta4.1 (2020-12-03)
Bootloader ID: not available
Never used RAM 4580, free system stack 96 words
HEAT 50 CanAsync 89 CanRecv 83 TMC 60 MAIN 326 AIN 64
Last reset 00:00:19 ago, cause: software
Last software reset at 2020-12-03 10:17, reason: HardFault, available RAM 4360, slot 1
Software reset code 0x0060 ICSR 0x00417003 SP 0x200011c0 Task
Stack: 20001014 00000012 0001d3e3 00000000 20000928 0001757d 000184fe 01000000 0000aed0 0000afca 20001210 200032d8 00000020 00017d11 20004668 00000000 20001300 000086e5 0000aed0 20004678 0000afca 41a73180 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5
Driver 0: position 0, 80.0 steps/mm, standstill, SG min/max 0/0, read errors 0, write errors 1, ifcnt 36, reads 9946, writes 9, timeouts 0, DMA errors 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0
No step interrupt scheduled
VIN: 12.3V
MCU temperature: min 28.7C, current 28.9C, max 28.9C
Ticks since heat task active 197, ADC conversions started 19940, completed 19940, timed out 0
Last sensors broadcast 0x00000000 found 0 201 ticks ago, loop time 0
CAN messages queued 99, send timeouts 0, received 189, lost 0, free buffers 36

But I am in beta 4.1 and it happen with both heater off. Only when I reset the board via the dialogue box that appear then we save the config.g file

@dc42 It's like you can read my mind! I'll update as soon as I can - still on beta3.2.

In case anyone is following this thread, this is implemented by - G1 H1 E moves (stopping on motor stall).