@Phil:

Great thanks. Is there any advantage to having a bed.g file ??
I have the Duet installed on my main printer that i use for long prints and plan on probing the bed prior to each print.

I don't think it matters much but if you edit config.g file, you have to restart the Duet for the changes to make effect whilst bed.g is effectively a macro. So you can alter the bed.g file without having to reboot the duet. Having the coordinates in a separate bed.g file also makes them a bit easier to find, rather than scrolling through the entire config.g file. Having said all that, changing the probe coordinates once they have been set is rarely, if ever done. Just my twopence worth…....

Ok, I figured it out.

Marlin outputs the temps while M109 is heating up. Since I am using Octoprint to run my print jobs, it is timing out during the cool down because there is no output from the firmware until the temp is within a few degrees of the target, then M105 replies start coming back. Octoprint is assuming a timeout and dumping the connection, that leaves the last command received by the firmware the M109 and why none of the remaining gcode is run because Octoprint bailed.

I tried putting M109 and M140 into long running commands, but the default time for is still too short. I can bump the timeouts way up to avoid the issue, and will for a short term fix.

Is there any reason why the temp is not sent via the serial connection during M109?
I found the following discussion, but I don't see that anything came of it. I could send a PR for the change if desired. It would be very useful to see the temp during heat up via the serial connection.

http://forums.reprap.org/read.php?146,612559

@lignumaqua:

Ah, thanks. That makes complete sense and I started off thinking that's what I was going to have to do, then I read the Wiki (text below) which suggests that
I assumed (always dangerous I know) that the steps/mm were based on the default 16x microstepping, and everything else was calculated from there. The Wiki appeared to confirm that assumption, but you always see what you want to see…

When RRF sees a M92 command it takes that as the number of microsteps/mm at the current microstepping rate. If you subsequently use M350 to change the microstepping, then the steps/mm is recalculated by the firmware to allow for the change. If you then issue another M92 then that will be the number of microsteps/mm at the new microstep setting.

So if you want to experiment with different microstepping, it's probably easiest to put your M92 command, calculated at x16 microstepping (the default at power up) before the M350 command. Then you can adjust the M350 command without having to adjust the M92 command.

@mjhall29:

Thanks for the response, I am now looking forward to the release of of the DueX5, if you need any testing done I am your man.

That job has already been taken - you'll have to get in the queue 🙂

One of the PanelDue features not mentioned which I particularly like is the virtual keyboard to send Gcodes to the Duet.

There is a nice stl to check for effector tilt here http://www.thingiverse.com/thing:1369444 clip it onto your effector and move the head around, its easy to see if there is tilt. You can use it in several orientations.

I've got a similar problem but fixing it is on hold as my magnets in my magnetic arms are not strong enough and they keep becoming detached, I am waiting until stronger magnets turn up. I have redesigned a fan shroud to position the IR sensor as close to the nozzle as I dare (which is quite close as I've got the E3D silicone cover), this reduces the magnitude of the nozzle-probe discrepancy.

Whilst I really like the IR sensor, having just moved it from my corexy, it does seem a little trickier on a delta machine where a small amount of mechanical error in the build and therefore tilt, is inevitable until we start building them using robots or on jigs to ensure 100% mechanical precision. Its hard not to conclude that if a totally reliable nozzle to bed contact probe were available it would be preferable. I've tried FSR's and they seem reasonable. I believe some promising work with piezo discs is being done.

Seems the board does not accept wifi passwords if they have a + in them. Confirmed this with another router, tested various password lengths and combinations of alphanumeric and non-alphanumeric characters, everything works fine until you try to use a password with a plus in it. Unfortunately my board will remain on the shelf until this is fixed.

Another way is to download all of it as a zip file via the clone button.

Powering off and on again. USB disconnected, turning ATX PSU off at the wall, then back on again.

There was already some text and schematics for Duet fan connection here :
http://otocoup.com/aql/#hlp:allb/fans

thanks for pointing that out … I tested, and I see now that when I trigger the x or y endstop the led does come on. They were probably on before because the enstops were shorted.

I have an IR mini Z-probe ... can I also use the z-endstop as a 'fail-safe', I don't see the z-motor led come on when the IR z-probe is triggerd.

Sorry for all the newbie questions .. moving from arduino/marlin to Duet has been more of a learning curve than I anticipated - but I'm sure with everyone's patience I'll make it...

Yes, that's right. CoreNG is also the hardware abstraction !ayer for iap4e.bin.

Yeah I started there but when I asked for 16 points it wouldn't generate the points, "suggest probing points" was greyed out. In the end since my maths has utterly left me, I just moved the head around manually and entered the coordinates of some suitable points.

Also nowhere on the page does it ask for Probe offset. It is a very useful tool, I might run some of the numbers on my Kossel Mini through it.

I'd like to add my thanks here too! The community around the Duet is by far the most helful and friendly I have come across. It is partucularly helpful having core developers like dc43 and T3P3Tony around and willing to answer questions. Maybe it's becuase we're all mad keen to make the most out of our kit?

Thanks, I've just corrected it.

The standard speed ratings are for writing data in the large chunks typical of a digital camera. In a 3D printer the chunks we can buffer up are much smaller, so Class 10 is not necessarily better than class 4 in this application. See http://forums.reprap.org/read.php?416,664836,664853#msg-664853.

Hi ttl64, to get rid of the heater faults, see https://duet3d.com/wiki/Tuning_the_heater_temperature_control.

HTH David

Well, after much testing (and some time off to do a few other projects) I've come to the conclusion that the probing issues I've had with the IR Probe are due to the fact that I use CA to fix scratches and divots in my PEI. PEI has different IR characteristics. I developed this "fix" for PEI several years ago to allow me to have a perfect first layer as that is the most visible on the fly fishing reels I manufacture. I love the idea of the IR probe but its nearly impossible to visually tell where a CA fix has been made in order to change the probing location. I've gone back to my FSR probing and everything has been working great.

I have these big red emergency off switches on all my printers.

http://m.ebay.co.uk/itm/Emergency-stop-button-station-twist-to-release-CE-1-N-C-contact-PT-A1-/231146690965?nav=SEARCH

They are only single pole so for mains heat beds in an error state caution is still advised.

I also with a bit of help from David and a few other on reprap came up with a simple smoke power shutoff.

http://forums.reprap.org/read.php?392,578686

It's not been extensively tested to determine if it will shut off the power before a fire begins, but it does latch in an off state when smoke is detected and requires manually resetting once the fault has been cleared, I expect it would work best in an enclosure. No false triggers yet after over a year in use, no genuine one either thankfully. It's obviously independent of the controller, and fairly simple.

What I have started using on my new printer is a plug-in rcd (ground fault device) right next to the machine. I can hit the test button as an emergency stop or general off switch, it should protect me against a mains heat bed problem and its double pole so shuts off the power to the device completely.

Hi Pete, yes I think the problem is in the gcode at the start of the file. There are commands to set the tool temperatures but no commands to select tools until the first T0 command. Also it has commands like G1 T0 E8 but I have never seen a T parameter used on a G1 command before or documented anywhere.

You should aim for your start gcode to look something like this:

M106 S0
M140 S100
M190 S100
G10 T0 S220 R170 ; set tool 0 active and standby temperatures
G10 T1 S220 R170 ; set tool 1 active and standby temperatures
T0 ; select tool 0
G1 E8 ; prime tool 0
T1
G1 E8
T0

I have chosen a standby temperature of 170C in the above but you may want to adjust that.
Also, we recommend to select relative extruder coordinates if your slicer supports it.

HTH David