@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

Thanks a lot.

I have modified your bed.g and now it works.

@Tinchus It's conditional gcode based on the object model.

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

@appjaws Yup, the script only adds UV (and AB) moves to existing gcode files. It doesn't modify any macro which might be called by the slicer start or end codes. But it looks like you are keeping the axes mapped to XY to do the other stuff, then mapping them to XYUV just before the print starts - so that ought to work I would have thought (make sue that you use an M400 at the start of your "MapDrivesXYUV" macro to ensure any moves are completed first).

I've replied to your email.

Ian

By the way i have found one thread about this topic: https://forum.duet3d.com/topic/18942/calculating-tool-offset-cnc/3?_=1604994474624

@oliof that's a good idea and would be easy to implement.. I have a lot of ideas to add into this before calling it complete, but just haven't revisited until variables are made available. However, I did think about beefing it up through a custom execonmcode script for the time being..

Update:
Since I had to reinstall the firmware, updated RRF 2.05.1 to 3.1.1, the problem persisted. So, during one of the errors I read something about an SD card error, now I don't remember it anymore, so I used the original SD that came with the Duet 2 Wifi and the problem didn't occur anymore. I will soon try to format the card as previously indicated.

Anyway, I believe it was a problem with the SD card, thanks.

Thanks for confirming.