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

@deckingman Ah I was going by the functionality on the gcode library. I just checked this, and R2 does works but I need to still be able to use the relays during a pause. Maybe there could be an R3 option where the trigger is only available when idle and in a paused state.

This would be for turning on a dust extractor during a CNC pause - and manually cleaning up a mess, which is one of the reasons you pause on a CNC machine - in case anyone was wondering.

@EducatingSavvas

If state.gpOut[3].pwm==0 M42 P3 S1 else state.gpOut[3].pwm==1 M42 P3 S0

condition in else is obsolete, and more "elegant" way is

If state.gpOut[3].pwm != 0 M42 P3 S0 else M42 P3 S1

@LB said in switching via an unused pin a relay (to drive bigger loads):

(I do not really get it, what it means in the reference by ";M950 command must have exactly one of the H, F, J, P or S parameters
" any help appreciated, they way I understand it is "must have not more then 1 H, F, J, P/S parameters"?)

It means that your M950 must be for EITHER a single (F)an, (H)eater, Input pin (J), Output pin(P)/(S)ervo pin.

So it depends on what the pin will be used for which of the F/H/J/P/S you would use.

In M42 the P value must match the pin number you created for it in M950

So M950 P88 means your must be M42 P88

The 88 is just an index number and could be any unique number from 0 on up. The important thing is that it matches.

Have you tested your conditional gcode yet?

@LB said in switching via an unused pin a relay (to drive bigger loads):

since this pin cannot do pwm

I thin that would mean the pin you choose isn't switchable, and not really suitable for switching a relay.

I thought the P parameter for G1 commands was documented, but it seems not to be. I have just [re-]added it.

@OwenD ah, thanks

It's not currently possible to pass parameters to macro files. Support for macro parameters is planned for firmware 3.3.

@dc42 I can confirm this works with one exception.

The start.g and resume.g refer to a file I've named conditional2.g with the following:

while sensors.gpIn[6].value=0
M291 S2 R"Enclosure Door Open" P"Close the door and press OK to continue"

while the door switch itself uses external trigger5.g with the following:

if state.status == "processing" & sensors.gpIn[6].value=0
M25 ; Pause
M291 S1 R"Enclosure Door Open" P"Close the door before resuming"

The exception is if I change the M291 in conditional2.g to an S3 which includes cancel - pressing cancel results it the job running while the door is open. It would be good to link that cancel option to cancelling the job. Is there a way of instructing the cancel in M291 to do something specific?

@Phaedrux said in manual bed levelling assistant:

@fcwilt I've adapted your reply as part of an introduction to the MBL page.

I read it - great!

@fcwilt
@Phaedrux

Maybe someone should also add on the same page, that from RRF>=___ it is recommended to use M557 (after M208 if used with conditional-g-code) with G29

e.g. in my case for a cartesian:

in config.g something like

M557 X{move.axes[0].min+15}:{move.axes[0].max-15} Y{move.axes[1].min+15}:{move.axes[1].max-15} P2:2) ; define mesh grid with G29 for probing, in this case for a manual levelling with 4 screws with 15mm offset from the heatplate

in bed.g something like

G53 ;Use machine coordinates ; If the printer hasn't been homed, home it if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed G28 ; home printer M400 ; finishes all current moves and and thus clears the buffer G90 ; set to Absolute Positioning M561 ; clear any bed transform ;G29 (newer probing mode(s)) workflow: ;M401 ; deploy Z probe (-> if you defined it in config.g - comment if defined M558 P0 in config.g for no probe installed) G29 ; mesh bed probe (needs acrive z-probe via M558), if no S or S=0 -> probe the bed, save height map to /sys/heightmap.csv and enable compensation ;M402 ; retract probe (-> if you defined it in config.g - comment if defined M558 P0 in config.g for no probe installed) ;M376 ; optional set bed compensation taper, define a height to taper off the compensation if needed

(I do not know where these "{1}" come from seems the software running this site is adding them to code-snippets...)

Good idea?

Typically the radius method would be used in a delta printer where the bed shape is round and the 0,0 origin point is the center of the bed. So it may make sense in your case to use a center origin as well.

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

cool!
looks like what i'm after

cheers