I'm still on 3.1.1 and I'm still having issues with the the M291 command. Here is the macro I'm trying to run:

; ToDo check Temp of bed and nozzle, so both are cold ; Cancel any currently active mesh compensation M561 ; Set z-probe trigger height to 0 G31 Z0 G1 X0 Y0 Z200 F6000 M291 P"Move to point were the z probe shall be calibrated." X1 Y1 S2 M291 P"Get a 0.1 mm thick metal spacer" S2 while iterations <= 5 G1 Z50 M291 P"Remove the z probe sensor if it is already or still attached" S2 G1 Z5 M291 P"Move FFF nozzle down until it just grabs a 0.1 mm thick metal spacer and then remove it." Z1 S2 G92 Z0.1 G1 Z50 M291 P"Attach the z probe" S2 G30 S-1 M291 P"Now calculate the average of the test. The average is the z probe trigger height for that point. Set it the config.g with G31 Z{ave} " S2

After I click OK from the first M291 in line 7 the machine just stays busy and the second window does not open.

When variables are added to the gcode meta commands you will be able to use the arduino to set user variables for those fields and then write a DWC plugin to display them.

If you wanted to do that before variables are implemented you could either:

hack a work around by using fields that exist in the object model (things like settings for an axis that you did not use and was hidden). write the file to the SD and and then have your display plugin read the file

Thanks all! Ill try it out.

After running multiples tests at a reasonnable speed (Feedrate : 15000 mm/min), I can tell that the motion is continuous between multiple G0/G1 commands!

By the way, I don't understand how the "T" parameter from the M670 works (when using the "P" parameter in a G1 command). I thought at first that is was the delay between the beginning of the movement and the beginning of the output being set to '1'. But when testing with multiple values for "T", the output was always set to '1' immediatly after the beginning of the G1 command.

Edit : The "T" parameter appears to be important when using the P1 parameter with a G1 command on a very short distance. Reduce the "T" value if you're looking to trigger an output to '1' on a short distance and high speed (30 mm and 15000 mm/min).

@dc42 OK. I'll give it a try.

In regards to running real-time loops in daemon.g, would it be possible to use a loop in daemon.g to call for a variable that can reduce the feedrate mid-print to 1% while a long single line segment is being printed? Ideally I would be able to pause mid deposition, but I know the current command needs to complete before a pause can be invoked.

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?