Is it possible to run multiple prints sequentially from a macro? I need to make a bunch of copies of the same part and was thinking I could create 4 different gcode files (Print1.gcode, Print2.gcode, Print3.gcode, and Print4.gcode where each gcode file prints one copy of the part in a different quadrant of my bed. Originally I was thinking at the end of each file I could insert an M32 command to run the next file but it seems like you can't initiate a print from inside of a print.

Simplistically, I want to be able to hit go on one macro or print and the printer to execute the following:

run Print1.gcode
then run Print2.gcode
then run Print3.gcode
then run Print4.gcode
then run Print1.gcode…

until I either emergency stop the printer or cancel wheatever print is currently running. I realize that setting the printer up to run an infinite loop like this could cause problems (running out of filament or the printer going to print a part in quadrant 1 and crashing on the part already there if I havent removed it yet) but each part takes long enough that I know I'll be able to remove them before the printer gets back to that spot.

Is it possible to do this using some combination of M98 or M32?

@T3P3Tony:

Alternatively we could ship a DuetEthernet with no Ethernet module and then you could add a ESP with a different antenna using a cheap PCB to route the signals.

I have a box printer and am running into the same issues regarding a weak signal. I'm considering de-soldering the perimeter of the ESP module from the Duet main board, relocating the module to some place outside of the printer, and then running jumpers to reconnect the contacts that i de-soldered. Is there any negative consequence that might prevent this from working?

The only two issues that come to mind are - 1. there will be some length at which the voltage drop through the wire will be too much for the module and Duet to communicate correctly, and 2. there's a potential for these wires to see too much interference from the environment if they aren't shielded. Is it possible for everything to function correctly if the module and Duet were to be separated by 1 ft of wire?

Thanks for the additional info! I understand what you are saying as far as using both an end stop and BLT and I'm thinking I may just go ahead and spend the extra time really testing it out so that I can confidently disable the end stop.
@ThePigSlayer:

I agree with Sniffle, using the bl touch for homing is great and if your bl touch works (just test deploy and retract) then there isnt really much of a reason to use a endstop over the probe for homing.

Also you can use m400 and m401 (double check) to retract and deploy the probe.

Last thing I am not sure if most people do it differently, but I use my bed.g file and I fill it with my mesh leveling code, well it homes first in the center and then does the mesh leveling. I can copy it if you want

I agree, I think that your bed.g would be really helpful.

Your mentioning of m400 and m401 (looking at the Gcode page, it looks like its [c]M402[/c] and [c]M401[/c], respectively) for retract and deploy made me realize that in the lines I had above I failed to actually retract or deploy the probe since i wasn't calling the deployprobe.g or retractprobe.g macros anywhere. So I'm guessing you have something along the lines of:

[[language]]
M402
G29
M401

```somewhere within your bed.g and then rather than your starting script containing [c]G29[/c] it would contain [c]G32[/c] which calls bed.g?

@Sniffle:

> …setup macro's for retract(90), deploy(10), reset(160), and self test(120)...

I'm assuming there isn't an Mxxx command similar to M401 and M402 for reset and self test and that the simplest way of running these would be to activate them from the macro buttons on the interface?

Do you need to call the reset and self test in bed.g or somewhere similar or are these dominantly used for testing/troubleshooting?

So I've gone through and read (i think) most of whats been posted in regards to setting up a BLTouch on a Duet Wifi but with everyone seeming to have a different setup or strategy it gets a bit confusing. The wiki seems to cover all of the info needed but its a bit difficult with it being spread through various pages. My end goal is to setup a Cartesian printer with a Zmin end stop for standard homing and with a BLTouch for mesh bed leveling. Initially I'm thinking of having the mesh leveling occur only at the start of a print, though this might get annoying and it might be easier to just run a mesh leveling on command when needed.

I've spelled out my understanding of what each command is needed for and what the parameters are helping to define/specify to confirm my understanding but also to maybe help others trying to set up a BLTouch…if my understanding is actually right.

My understanding of what all needs to happen in the configuration files and gcode files is:

======config.g file======
=needs added:=
[c]M307 H3 A-1 C-1 D-1[/c] {to free up heater 3 control pin for use as general I/O pin} where H3 indicates heater 3 (location that BLT servo control is plugged in)
[c]M558 P5 X0 Y0 Z0 H5 F200 T5000[/c] {to define the probe parameters/usage} where P5 specifies the output of the BLT is plugged into the Z probe connection (P4 would specify the output is plugged into the E0 endstop pins), X0 Y0 Z0 defines that the BLT isnt used for any actual homing (X0 Y0 Z1 would define using BLT for homing Z axis), H5 defines the height of the printer head at the start of each dive/probe, F200 defines a Z speed of 200 mm/min, T5000 defines X and Y speeds of 5000 mm/min
[c]G31 P25 X-18 Y0 Z2[/c] {to define the trigger and positioning of the BLT} where P25 is the sensitivity of the trigger detection (or the pulse duration duet will consider a trigger?), X-18 Y0 is the offset of the probe from the nozzle tip, Z2 is the vertical offset of the BLT's trigger point to the nozzle tip
[c]M557 X50:550 Y50:550 S100[/c] {to establish the parameters of the G29 mesh bed probing procedure} where the X and Y parameters defines the extremes of the probing grid and S defines the spacing of the grid points

======deployprobe.g======
=only contains:=
[c]M280 P3 S10 I1 [/c] where P3 is identifying the pin for heater 3 (pin 8 - wifi, pin 21 - duet 0.8.5), S10 indicates to deploy pin

======retractprobe.g======
=only contains:=
[c]M280 P3 S90 I1[/c] where P3 is identifying the pin for heater 3 (pin 8 - wifi, pin 21 - duet 0.8.5), S90 indicates to retract pin

======bed.g====== isnt needed since I'm not trying to perform a G32

======homez.g====== can remain the same since I'm still using my Z min end stop for Z homing

======[starting script in Simplify3D]======
=needs added (after G28):=
[c]G29[/c]

additionally it seems helpful to add the following macro
======resetprobeerror.gcode======
[c]M280 P3 S160 I1[/c] where P3 is identifying the pin for heater 3 (pin 8 - wifi, pin 21 - duet 0.8.5), S160 indicates to reset error state

What errors/issues do i have in this breakdown or is it fairly safe to say that if I add/edit the above to my duet wifi I should have an operable BLTouch?
Does using the Z min end stop for Z homing and then using the BLT for mesh leveling cause any weirdness as far as operation or offsets? I was intending to use the end stop just because I'm confident that it keeps the nozzle from crashing into the bed. I may convert over to just the BLT as my confidence builds in the setup.