RRF provides the mod(a,b) function instead.

@droftarts Oh yeah found it! I cant believe i havent noticed 🤔 . Anyway thank you for your help in understanding the problem. It works much better now . Have a great day 🙂

i printed a calibration cube when i first biuilt the printer noticed the skew and kept it for comparison. so i compared the new prints with the values entered and the is no change between the models. the firmware version iam running is

Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)
Duet WiFi Server Version: 1.23

You could edit the PanelDue firmware itself maybe.

If the extrusion speeds in the PanelDue interface are too high it won't really matter, because if the speed limit is set low in the config.g it won't be able to move it faster.

@dc42 thank you. This is very helpful. I will give it a try. It seems the assistant you have asks the user to adjust per a given thread pitch. I do like the craftbot method of just continuously probing and letting the use make micro adjustments to see how close they are getting to the desired positions.

Perhaps once we have SBC capability on the Duet2 we can make more elaborate wizards and guided assistants.

@deckingman said in Need help with homing XYUV and conditional gcode:

EDIT. Thinking about it a bit more, I guess an elegant solution would be to have a macro which checked the status of all end steps, which could be called at the start of any homing macro, but I'm open to suggestions.

You can iterate over all endstops (or other arrays) by using # to give you the number available

while iterations < #sensors.endstops if sensors.endstops[iterations].triggered echo "Endstop " ^ iterations " is triggered" abort

I had thought maybe this could be expanded to try to move away from any active endstop which would effectively test if it was broken (i.e. if it's still active after a 6mm move it's broken), but I can't see an easy way in the object model to determine if the endstop is at min/max or whether it's N/O or N/C.
Nor does it seem possible to determine the axis it is associated with other than to assume the endstop number would align with the axes number.
But if you had two endstops on an axes that'd fail.

@fcwilt

Like this ?

if state.status = "paused" M24 elif state.status = "processing" M25

still getting the same 'elif' did not follow 'if

o.k I've got you

if state.status = "paused" M24 elif state.status = "processing" M25

Thanx! woprks very well now. This is what I ended up with.

M558 K0 P5 C"!io2.in" F100; create probe #1 for use with M585, active low

G38.2 X596 P0 G10 P2 L20 X0 G0 X{move.axes[0].userPosition-1} G38.2 X0 P0 G0 X{move.axes[0].userPosition/2} G10 P2 L20 X0 G38.2 y810 P0 G10 P2 L20 Y0 G0 Y{move.axes[0].userPosition-1} G38.2 Y0 P0 G0 Y{move.axes[1].userPosition/2} G10 P2 L20 Y0

Well this is definitely going to be a game changer for me, I will have to do some testing on one of my other test rigs to play around with this.

Thanks a million @OwenD, I am constantly amazed on how helpful the Duet Community is and i hope one day I know enough to be able to help others out as you have helped me.

🙂

@Kolbi said in Random number generation with Meta Commands?:

@dc42 said in Random number generation with Meta Commands?:

It will be in the 3.02beta releases.

Nice! Is there a list of new expected features?

You can see what is already implemented or partly implemented at https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md.

I finally found some time to work on the minor bug list.

@mitch Yup, I use M701/2/3 to make the system aware of what filament type it has loaded. For awhile I was trying to access/parse the /sys/filaments.csv file via macro but it wasn't possible afaik. I do agree that with some firmware revisions to the M701/2/3 commands that it should be possible, and useful, but I don't think it is obtainable as of now - at least not with stand-alone configuration.

Once variables are enabled you could have the slicer's output write the required filament's weight to a variable, and then start.g could compare that with a weight-sensor's reading to give a go/no-go?

and again another object model question 🐒

I would like to get the current status of the z-probe for an if statement

I can find it in the object model:
M409 K"sensors.probes[0].value"
{"key":"sensors.probes[0].value","flags":"","result":[1000]}

but when I try to echo the signal
echo sensors.probes[0].value
[array]

I don't get the information I would like to have (whether it is 0 (not triggered) or 1000 (triggered). Could you please once more help me - thank you in advance!!

Okay never mind!
echo sensors.probes[0].value[0] did the job!

@dc42 Thanks!

@Stephen6309 said in Conditional on G29 S0 or S1:

G29 S1
if result > 1
G29
It works with no errors

I was just playing with this.
Since I have a heated bed and also use the filaments/config.g to set different bed temps depending on the filament loaded - the bed heights could vary, but I haven't really seen that in real life. With that being said, I always do G29 with the bed heated to the filament's config.g settings. So depending on the different filaments in the DWC profiles, bed warp-age could vary - so not one bed height.csv for all. Hence this:

G29 S1 [P{move.extruders[0].filament^".heightmap.csv"}] if result > 1 G29 G29 S3 [P{move.extruders[0].filament^".heightmap.csv"}]

Will yield:

G29 S3 [P{move.extruders[0].filament^".heightmap.csv"}] Height map saved to file 0:/sys/PETG.heightmap.csv

They already are:

04/08/2020, 21:40:20 echo move.axes[0].workplaceOffsets[move.workspaceNumber-1] 0.000 04/08/2020, 21:39:33 echo move.workspaceNumber 1

Note, workspace numbers are counted from 1 upwards as defined by NIST, but the workplaceOffsets array is indexed from 0 as usual; hence the -1 in the index expression.

@Phaedrux
i know but surely you can understand were the frustration come from..
one thing i must say is the only reason i always recommend to friends to go for duet bored are the forum support ,its crazy how fast and good all the reply's here!!, specially by dc42!!
@dc42 said in use variables with in macros:

You can simulate a small number of numeric variables already, by defining a dummy tool and using its XYZ offsets as variables.

can you please give me an example?,just to see how you use this correctly.

btw did you consider using https://duet3d.dozuki.com/Wiki/Gcode#Section_G38_2_to_G38_5_Straight_Probe and use conditional logic to remap the endtop before/after as needed?

I've worked out what's going on. The G10 command would normally be synchronised to the movement queue. If there are movements not yet complete, it is put in the deferred execution queue. When it is retrieved from that queue, the "iterations" context has been lost.

I think the solution will be to substitute for all { } parameters when copying the GCode command to the deferred execution queue.