How to set offsets for multiple extruders on duet?

Hi All,
I've *almost* got things working. I was able to print 2 color dice using a Tricolor Mendel-3 (duet electronics, latest firmware). I set G10 XNN YNN commands in my config.g file and that seemed to allow me to calibrate the heads to the same origin.

My problem now is that I have 3 colors on the extruders and I want to print an STL on extruder 3 (happens to be blue). My X offset for 3 is something like 42. When viewed from the front, T0 is on left in first of 4 slots, there is no nozzle in second slot, T1 is in 3rd slot, and T2 (the blue extruder3) is in the last slot. I specified positive offsets, though I'm not clear if that was correct or not, other than it made my dice line up.

In slic3r I created a printer called something like Mendel N3 Onl. Here I modified the default custom G code for the Mendel-3 Triple nozzle from the latest slicer config packages from reprappro such that the unused nozzles have -273 for standby and hot temps. I also have a custom printer setup called Mendel N3 Only where on the multiple extruders page I set all the values to 3 (seems skirt won't come out in the printing color otherwise?)

When I print in this configuation, everything is find and dandy with small footprints (my dice) but I am trying to print a spool holder which takes nearly the full width of the bed. I'm printing with nozzle 3 (~42mm right of nozzle 1) and as soon as nozzle 1 would have to go negative, the printer truncates the print even though the mendel-3 can move nozzle 3 to the 0,0 position on the bed (making nozzle 1 be around -42).

So I have a misconfiguration, or I am thinking about things wrong, or there is some trick I need to use.

Choosing T2 and then printing seems to make it print at the G10 offsets in my config.g file, but something else seems to be saying-- hey, T0 is about to go negative so I'm not going to let you go any further, even though T2 is selected and can still go 42 mm more. Both 2 and 3 are showing this problem.

Help?
--
Craig

You haven't said which fork of RepRapFirmware you are using. The following applies to my fork, but many of the changes I made are now in the official RRP release, so this may apply to that too.

You need to choose a datum position on the head. On a single nozzle machine, this will be the position of the nozzle. On my dual nozzle Ormerod, I chose the point midway between the two nozzles; but you could choose one of the nozzle positions instead if you like. Having chosen that datum:

1. Define the nozzle offsets relative to that datum using G10 commands. The G10 offsets can be positive or negative.

2. Define the maximum allowed position of that datum in the +X, +Y and +Z directions using the M208 (or M208 S0) command. This also defines the position when a high-end homing switch is triggered.

3. Define the minimum allowed position (i.e. in the -X, -Y and -Z directions) of the datum using the M208 S1 command. These are also the positions at which any low-end homing switches are triggered.

So if on your machine nozzle 1 is the datum, and it can move as far as -50mm in the -X direction, use M208 S1 X-50 to tell the firmware that. Otherwise, it will assume that X=0 is the lowest allowed position for the datum. See [reprap.org] for more.

Another quick hack to get round your problem is to use the M564 S0 command to disable axis limits, but I don't advise that for long-term use.

Edited 2 time(s). Last edit at 09/01/2015 05:31PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I appreciate the timely response!

I only skimmed your reply but the key point I gathered is that the machine has its own built-in axis safety limits and i have to extend them in some particular way to account for the offsets. I've already applied the G10 offsets as you mention and my datum would be the first nozzle (on left when looking at the X axis with 0 to the left). Sounds like using positive offsets from that reference was correct which fits with my success thus far. I just need to make the machine aware of the axis limits

As for the fork I am using-- I haven't yet mastered the reprap git repository (huge understatement). We downloaded master branch of [github.com], and the duet has 1.0.9 iirc. Hopefully the commands you mention will have been merged there. I'll post a reply if it works.

My son is printing something for another hour or so (it's actually his printer, but I'm the guy stuck figuring it out so it can work), but I'll try your suggestions as soon as I am able. We're still very much in the 'getting the hang of it' phase. Once we're set so that we can print from any spool or spools we like and actually get what we want, we'll start trying to fix some of the minor imperfection.. i.e. the 2-color dice I printed have the two colors off by a fraction of a mm (pips stick out just a tad on 2 sides). But need to get the 'gross motor skilll' shored up before we can focus on the fine details.

Thanks again!

The machine recognized the M208 command which was great. Thank you again

I added the two M208 commands right after the tool defs and G10 commands in config.g. It was not clear if this was wise or correct or not, but it seems to be working. This led to a cascade of changes because I then adjusted the 0,0 position on the plate which caused changes in homex and homey. But homez finds the white square relative to that location so that had to change as well. Then homeall is also needed all those changes as well. Finally, bed had to be updated to accomodate the change in 0,0 so that the plane can be identified with the sensor over a white spot. I got through it though, and I was able to adjust it so I can request overshoots on X and y and it stops before bumping the limits, and all 3 nozzels can safely trace a 190x190mm surface without falling off the plate or running over a clip. I could probably get the full 200mm if pushed the y to the nth degree before it hit the clips and remounted my 3rd nozzle on the first heater block. I built the mono first and didn't want to disassemble it, so it was easier to just add the 2 new nozzles at once on the other side.But until I need that final cm for a print I think it is fine for us.

One thing that has been annoying me though is that if homeall is run with anything but T0 active, the coordinates moved to for Z probing are relative to the active tool, not the datum. Thus I have to always watch or double check for fear that on homeall the senor will be hanging off the edge of the plate. It happened the first time while I wasn't paying attention and it drove the x carriage don a good cm below the plane of the plate, really torquing the bed. Thankfully no harm done that I can really see.

But it seems one ought to be able to rewrite homeall to somehow account for that. I tried adding T0 at the beginning but then it seemed nonfunctional and Reprappro support advised against doing it that way anyway. Their advice was to add T0 to the end of the gcode for each print. That works unless you cancel the job (which for us is somewhat frequent as we try to dial in temps and process for new filaments we are playing around with).

Any advice how to deal with the tool selection during homeall-- it *has* to be the coordinate system for the default nozzle or the landing spots for probing just don't work.

Try putting T-1 at the start of homeall.g to deselect all tools. Then it will use the datum position for all movements.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

T-1 does not work for me. On initial boot up, homex and homeall both work fine with T-1. However, if I cancel a print while T2 or T1 is in use, homeall and homex do not seem to fully run. I'm using the web interface. After the first press the Home X, Y, and Z all go orange so the T-1 seems to do something, but the motors don't move. It occurs to me now that perhaps the temps were tyring to adjust to standby based on the T-1 and that is why nothing happened, but I vaguely recall checking that last night when I tried and did not think that was happening.

I've removed T-1, and can deal with the cancel on T1 or T2 like this

1) cancel homes the carriage relative to the nozzle in use, so the z probe is over the X limit pad (when I am printing on nozzle 3 anyway). 3rd heater is still hot and bed is still hot
2) I Z + 10
3) I set standby temp for heater 3 to 160 (or some number close to 190
4) I click on Heater 1 and it goes active (default active is 0 and standby is 0 as I'm in a config that only prints on 3rd nozzle
5) Heater 3 goes to standby and must wait until it reaches standby temp before it will do anything further
6) Now I can load a new print and all goes well.

But it's my son's printer (he has a learning disability and 6 sequence steps are very hard for him to repeat fully without a *lot* of practice). I'm trying to make this as simple as possible for him. For now I've told him when he cancels a print, he must reboot and start with 'Home All' followed by 'auto-bed compensation' which is just 2 step and he is able to do that reliably. I was hoping that we could get to a point that he can cancel and just start a new print, but still searching for the magic bullet.

Can I put T-1 in stop.g? comment in stop.g say called after M0-- but I'm not clear what the web interface issues when you press pause and then press cancel. It might just be M2.

I suppose in pause.g I could do
; pause.g
; Put G/M Codes in here to run when a print is paused using M25 or M226
M83
G1 E-10 F3600
G91
G1 Z+5 F200
G90
T-1
G1 X0 Y0 F6000


that is add T-1 before the existing G1 X0 YZ-- that way it would home vs the datum, not the active tool.

But then how to fix resume so that it returns to the active tool. I couldn't find a command that means use previous tool. But this may be a viable way to go-- it would just mean we can't pause and resume, only pause and cancel.

Any futher suggestions?

I think that T-1 would work using my fork of RepRapFirmware as long as you don't have any commands in your tfree0.g or tfree1.g files. If you want to try my fork, you can download it by going to [github.com] and clicking on the Raw button. If instead you want support on the official RepRapFirmware release, then I suggest you post this question on the Mendel or the Ormerod forum, where RepRapPro staff are more likely to see it.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
I think that T-1 would work using my fork of RepRapFirmware as long as you don't have any commands in your tfree0.g or tfree1.g files. If you want to try my fork, you can download it by going to [github.com] and clicking on the Raw button. If instead you want support on the official RepRapFirmware release, then I suggest you post this question on the Mendel or the Ormerod forum, where RepRapPro staff are more likely to see it.

Thanks again dc42. You've been very gracious! I just noticed the machines organized by name section. When you go to reprappro support they send you to the top level [forums.reprap.org] and the 2nd item shown is reprappers (people building or using repraps) and that sounded like me. I'll give T-1 another try when I get a chance-- it may have been that temps were adjusting preventing the home from running after the T-1. Not entirely sure. I'll also have a look at your branch at some point. Your advice on the nozzle config was very helpful. Seems that should have been able to have been easily spelled out on reprappro's multi-materials page. I had no problems sorting it out from your brief reply.

I just realised what is going on. You are using the RepRapPro homing files, which use G92 commands in the homing files to define the positions. These commands used to be needed in RepRapPro's fork, but not in mine. My fork sets the position when a homing switch is set from the limits specified in M208. I think it also takes the nozzle offset onto account, but I ll check this when I am back in the office. So I think that switching to my fork and homing files will fix the problem.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].