@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.

@dc42 I'm an idiot. You literally said that above and I somehow read past it. My apologies.

Yes, that probably works nicely. I will implement that.

(Still, I could use variables well from time to time, and persistence would be nice too. Isn't is possible to add a few user locations to the object model, or is the object model readonly from g-code anyway?)

Now I only have to find out why that Scaffold stuff keeps plugging the heatbreak, even with very little retraction, cooling the inactive nozzle and moving a bit of the stuff each layer.

@dc42 Wanted to check on this also. Since you're looking into the filament sensor code, would it be possible to add an additional S parameter to M591 to monitor filament movement during all filament moves?

I finally got the macro working with following code:

; Source: https://forum.duet3d.com/topic/4202/homing-to-z-max-when-also-using-a-z-probe/19 ; Start g-code: G28, M98 P"0:/macros/Leveling/SetZ" ; run z fine tuning ; If the printer hasn't been homed, home it ;M291 P"checking homing status" R"Homing status" S1 ; Report status if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed ; Check if axis are not homed ;If axis are not homed, home axis echo "Axis are not homed, performing homing" M98 P"0:/sys/homeall.g" else ;If axis are already homed, home only the X and Y axis echo "axis are homed, re-homing x and Y" M98 P"0:/sys/homex.g" ; Run the Home X macro M98 P"0:/sys/homey.g" ; Run the Home Y macro ;G1 X100 Y100 H0 F1800 ; move to be centre slowly. ;End homeing check M291 P"Axis homed" R"Homing status" S1 ; Report status ;echo "start fine tuning z-level" G1 X100 Y100 H0 F1000 ; move to be centre slowly. G1 Z15 H1 F8000 ; Raise the bed to start probing G30 ; probe for z=0 G1 Z10 H1 F1000 ; raise nozzle G30 S-1 ; check z gap G1 Z10 H1 F1000 ; raise nozzle M400 ; Wait until all moves are completed

I changed and tested several different thing, but i think the trick that did it was removing the empty line between the end of the "If" block and the start of the "else" block.

Presumably your usage case does not require a shutdown or other more definite action in the event of a heater fault or you will have set the firmware to take such action above a certain threshold.

You could monitor a heater or sensor in daemon.g and use something like the following.
You have to create the file and put it in /sys
Note, this hasn't been checked for correct syntax etc.
It's just a general guide.

EDIT: Also you have to consider that this would resume any paused print if the temp was under the set value, regardless of why it was paused! You have to figure out how to differentiate the reason it was paused. Until we get variables that's a bit harder. You could maybe set a dummy fan value or something.

if {(heat.heaters[nnnn].current > 150) && (state.status = "printing")} M25 ; pause if {(heat.heaters[nnnn].current < 150) && (state.status = "paused")} M24 ; resume G4 S10 ; wait 10 seconds before checking again.

@npedro said in IR temperature Sensor and Conditional Programming:

I was thinking using an analog IR sensor.

If the sensor produces an analog output that you can scale or limit to 0-3.3V then you can use the LinearAnalog type of sensor in RRF. You could use the daemon.g file to read the sensor periodically, calculate the correction needed and use the M220 command to change the feed rate multiplier. Please note, M220 doesn't affect moves already in the queue, so it may take up to 2 seconds + 1 move before changes in M220 take effect.

@tekstyle said in need conditional commands:

@OwenD

thanks for your help. i am not familiar with conditions and its syntax. this totally helps. does duet website have any information on other conditional commands that can be used ( not particular to this OP)?

Full documentation of the object model is still coming, but there is enough to get started here.

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

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

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

Then it's a matter of poking around with M409 and testing using echo or similar

Both sound like good ideas

That worked. Thank you!

@techild
Glad you're sorted.
Might be best to mark thread as solved.

It's a simple manual bed leveling macro.
So far I have 3 macros level test1 to 3.
first 1 homes Z then G30 S-1 at that X Y location then moves X Y to right side of bed and does G30 S-1 prompts for OK or Cancel. If result of G30 S-1 matched the result of probe position 1 then I cancel else I adjust the bed screw at that point then hit OK, which repeats G30 S-1 in the same X Y position.

2nd Macro doesn't probe position 1 since I now know the result from previous probing., it moves X Y to the 3rd probe position and then G30 S-1.
I repeat the above as needed calling macro's 1 through 3.
Based on the outcome of a G32 bed level test, I could run 1 or more of the macros again.
The X Y locations match the outer 4 points that G32 probes.

If that makes sence..

Ok, that's interesting about the uptime. I realise my solution would have to wait for variables.

I also just discovered that I can use the M291 command to periodically check with the user if they want to continue. It's a useful workround for now.

@dc42 and @mwolter Thank you both for your help.
As I mentioned conditionals are not my forte.

I eventually got it working and am pleased with what it does.
I include it for anyone else, even the original above by @mwolter would work but tweaked what I knew I could tweak, namely I used 4 screw locations instead of 3.

This is for a RailCore II CoreXY with 3 Z motors but could probably be applied to anything else.

New bed.g

; New 2/5/2020 if !move.axes[0].homed || !move.axes[1].homed ; If the printer hasn't been homed, home it M98 P"0:/sys/homex.g" ; home x M98 P"0:/sys/homey.g" ; home Y M98 P"0:/sys/homez.g" ; home z ; M561 ; clear any bed transform ;M558 P9 H5 F120 T24000 ; increase dive height M98 P"0:/sys/bed_FourScrews.g" ; perform bed tramming ; echo "Bed Traming Cycle: 1 - Difference was " ^ move.calibration.initial.deviation ^ "mm" ; while move.calibration.initial.deviation >= 0.02 ; perform additional tramming if previous deviation was over 0.02mm if iterations = 5 abort "Too many auto tramming attempts" M98 P"0:/sys/bed_FourScrews.g" ; perform bed tramming echo "Bed Traming Cycle: " ^ iterations + 2 ^ " - Difference was " ^ move.calibration.initial.deviation ^ "mm" continue ; ;M98 P"0:/macros/Utilities/Config/bltouch_config" ; Apply default BLTouch config G28 Z ; home z

bed_Fourscrews.g

G30 P0 X15 Y45 Z-99999 G30 P1 X15 Y275 Z-99999 G30 P2 X275 Y275 Z-99999 G30 P3 X275 Y45 Z-99999 S3

If you make it better, please let me know so I can implement it also!

Regards,
Paul

@OwenD said in M117 and Conditional GCode Statements:

Not sure if there's something screwy going on with caching in DWC here, but the same command sometimes works and sometimes doesn't

DWC doesn't display a message if it was exactly the same as the previous one.