Now I see why I could not find my 'Download' it always save it as rr_download.txt
or rr_download-<n>.txt if you take the [Create New File] option instead of overwrite.</n>

@dc42:

I have already explained this in the wiki page on connecting thermistors. I already updated the E3Dv6 firmware configuration instructions, and I have just updated the instructions for the Lite6 too.

Ah, gotcha, sorry. I only noticed because I happened to swap my J-Head for an E3D v6 Lite last night. I had used the instructions for RepRapFirmware on E3D's website which says to use the book value for RepRapFirmware.

David

edit- typo

The amount of filament used since the start of the print is displayed on the Print Status page, above the right hand end of the progress bar.

@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