New RepRapFirmware release 1.12-dc42

I've updated the repo to treat duet.inf as a binary file, and it seems to be working properly now.

---

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

Quote
jimustanguitar
I end up with a heater fault every couple of minutes using a thermocouple and a Max31855 board (Logxen from Uberclock/Smoothie). I've got a very nice, well insulated PTFE cabled thermocouple that I encapsulated in heatsink epoxy to shield the bare metal of the welded junction from the aluminum heater block like your wiki mentions...

Can you confirm that you are using firmware version 1.12a? How long are the cables between the Duet and the thermocouple board? Can you post a photo of the wiring?

Also, when a spike occurs and a heater fault occurs, is there a message on the GCode Console page informing you what the nature of the fault is?

---

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].

David,

I'm a bit late to this party, but I've just updated to 1.12a successfully on my Linux Mint 17.3 64-bit machine. Seems happy to connect to the web server without complaint, and will try to print something soon.

What's the current version for Chris's web server code?

Cheers,
David

Quote
David J
David,

I'm a bit late to this party, but I've just updated to 1.12a successfully on my Linux Mint 17.3 64-bit machine. Seems happy to connect to the web server without complaint, and will try to print something soon.

What's the current version for Chris's web server code?

Cheers,
David

Thanks for the feedback. Can you still connect to the Duet using USB too?

The current version of DWC is 1.11.

---

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

Thanks for the feedback. Can you still connect to the Duet using USB too?

The current version of DWC is 1.11.

I'm printing something just now - I'll try USB later (it's not something I use very often...)

BTW: uploading the G-code file was 3x faster - about 600Kb/s or so.

Edited 1 time(s). Last edit at 05/11/2016 08:11AM by David J.

USB update: I plugged the printer in, and all the right messages came up in dmesg and lsusb. Tried printing, didn't really seem to have a solid connection - then changed the USB lead to a known good one, and everything sprang into life... crummy old USB lead now in the bin.

I remembered why I didn't use USB with this duet-powered printer - I have never managed to make it work properly: it does straight lines very well, but curves get the motors clattering and the results aren't very nice. I am 99.9% sure that this is due to my USB connection config and/or protocols rather than anything to do with this update (it's been like this for ages). Same software, same lead and same port work perfectly when used with my RAMPS-powered Prusa. I'll bring this up as a separate topic, rather than cluttering up this one.

Quote
dc42

Quote
stephenrc
Windows 10x64 and Chrome, both are up to date. Downloaded the whole firmware as a zip and the individual files as raw. I get an Install Error dialog with "The hash for the file is not present in the specified catalog file. The file is likely corrupt or the victim of tampering"

I found the problem. Git has changed all the line endings in duet.inf from CRLF to LF. I'll take a look at whether I can force git to treat duet.inf as a binary file. Meanwhile, attached to this post is the correct duet.inf with the original line endings.

It installed with no errors.

Quote
David J
USB update: I plugged the printer in, and all the right messages came up in dmesg and lsusb. Tried printing, didn't really seem to have a solid connection - then changed the USB lead to a known good one, and everything sprang into life... crummy old USB lead now in the bin.

Thanks again for the feedback. FWIW the micro USB A/B connector on some Duet 0.6 boards don't give a reliable connection. I have to waggle the USB lead connected to one of my Duet 0.6 boards to make it work. The micro USB B connectors on Panel Due. Duet 0.8.5 and Duet NG are more reliable.

---

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
Thanks again for the feedback. FWIW the micro USB A/B connector on some Duet 0.6 boards don't give a reliable connection. I have to waggle the USB lead connected to one of my Duet 0.6 boards to make it work. The micro USB B connectors on Panel Due. Duet 0.8.5 and Duet NG are more reliable.

I use a very short extension lead between the Duet and the outside panel - it's about 10cm long, and has a very firm connection to the Duet USB socket. I'm not sure that this arrangement is ideal, but this connection has worked well in the past when updating the firmware by the old-fashioned method.

As I said - I'm sure it's down to the setup. I'm only putting a half-hearted effort into fixing it though, as I prefer to use the web interface.

Edited 1 time(s). Last edit at 05/11/2016 01:36PM by David J.

Is it just me or does the duet not allow me to select temperatures higher then 250 from the dropdown after upgrading to 1.12a?

Read the first post, your answer is there.

Derp. Read the first two parts and skipped the entire section. Thanks.

Edited 1 time(s). Last edit at 05/11/2016 10:16PM by Bob64.

Can the temp limit be over-ridden? It's just that E3D specify a temp of 285C when tightening the nozzle.

Hold on - I should RTFM (or original post, anyway) - the M143 command allows me to set a different limit!

Edited 1 time(s). Last edit at 05/12/2016 10:16AM by David J.

Quote
dc42
Can you confirm that you are using firmware version 1.12a? How long are the cables between the Duet and the thermocouple board? Can you post a photo of the wiring?

I am using 1.12a, yes. The thermocouple is a 1m cable, the same PTFE one that E3D sells, except I bought mine in bulk from RS Allied.
I was originally using a Logxen thermocouple amplifier from Smoothie, and since I've switched to one from Adafruit. Same behavior, unfortunately.

Here's my wiring form one end to the other.









I'll try a print this weekend with the console open (I've been printing on SD lately) to check for GCode error messages besides the pop up in the previous post's screenshot.

You didn't answer this bit, and I can't tell from the photos:

Quote
dc42
How long are the cables between the Duet and the thermocouple board?

It shouldn't matter what thermocouple board you use, provided it is MAX31855-based, is compatible with 3.3V signalling levels and power, and has the input capacitor fitted (or you have added it). The board in your photo appears to have 5V level-shifting chips on it. Can you confirm that Adafruit guarantees that it will work with 3.3V signalling too?

A reading of 2000C indicates failure to read the thermocouple. Possible causes include a dodgy thermocouple connection, or too much noise on the interface. Keep the Duet <-> thermocouple board wires short and away from stepper motor and heater cables.

Do you still get the temperature spikes when the printer is idle, with the motors not moving?

I'm not ruling out the possibility of a firmware problem at this stage, but I'd like to eliminate other causes first. I don't have a printer using a thermocouple at present, instead I have a Duet on the bench that I use for testing hardware features that neither of my printers uses. I don't see any temperature spikes on that system.

EDIT: On my test system, I found it very difficult to get reliable connections between the fine thermocouple wires and the terminal block on the thermocouple board. I ended up soldering the thermocouple wires to header pins, and clamping the header pins in the terminal block.

Edited 3 time(s). Last edit at 05/13/2016 05:00AM 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].

Quote
jimustanguitar
The thermocouple is a 1m cable

Sorry about that, it was brief and poorly depicted.

I'll have to see what I can do about location and or shielding. I hate the idea of running 5 more conductors down to the hotend since it's so light and clean as is, but you're exactly right that they run in parallel with the heater wires and might be seeing some 'crosstalk' from them. Interesting that I don't see the same behavior on my other large Delta, its taller and its thermo cabling goes twice as far (up the bowden tube to the top and then all the way back down into the base) before reaching the amplifier board... I guess I've got some experimenting to do.

I'm also going to try using one of the other pins on the Duet (NPCS0,NPCS1,TXD1,RXD1) just in case it makes any difference. I'm paranoid about SPI collisions from a bad experience with Smoothie... Out of curiosity, what is the firmware's behavior if that connection goes intermittent, does the firmware interpret a high or a low reading if it receives no data?

If the firmware fails to get a reading from the thermocouple, it reports 2000C. It should also write a message to the web console and the USB host if any.

The SPI bus on the Duet is used only for reading thermocouples and RTDs, so there should not be any collisions. The coding of RRF isn't like Smoothieware, it's closer to the way I write safety critical software in my other job, so more deterministic.

---

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].

Notes it is actually reading the Inferred prob and the Z probe reading is right. So way didn't the X and Z end stop indicators change?

3:41:21 PMM119
Endstops - X: at max stop, Y: not stopped, Z: at min stop, Z probe: not stopped
3:40:09 PMM119
Endstops - X: at max stop, Y: not stopped, Z: at min stop, Z probe: at min stop
3:39:21 PMM119
Endstops - X: at max stop, Y: not stopped, Z: at min stop, Z probe: not stopped

I have tried to install the latest dc42 firmware 1.12-dc42 but with no luck. I get an error message "Invalid mcode M997".
I have tried both yours and Christians iap.bin.This is with duet 0.8.5 and renamed the firmware to RepRapFirmware.bin.
I have probably done some thing stupid but I donot know what.

Manjaro linux 64bit

Firmware Name: RepRapFirmware
Firmware Version: 1.09b-dc42-t3p3-axis-switch (2015-06-22)
Web Interface Version: HTML: 1.11, JS: 1.11

I have not tried updating over USB as I am getting the message No device found on ttyACM0 and donot wish to end up with no firware at all.
(The command I used worked previously with duet 0.6)

Any suggestions. Thanks.

You have to have at least 1.10 (I believe) to use the web update. You will have to do the update via USB one last time.

As ElmoC mentioned, I believe you need at least 1.09x firmware and 1.10 DWC along with the iap.bin file in order to upgrade via the web interface.

For upgrading via USB from 1.09b, I believe you will have to erase the current version of the software to default back to a Arduino Due bootloader before installing the new firmware. At least I believe that is what I had to do to go from 1.09r to 1.09x...might be wrong on the versions, its been awhile.

Many thanks ElmoC and Kurzaa.After much messing about getting bossac to work I finally managed to update the firmware to 1.09x
and from there updated over the web to 1.12a.I did not have to rename the firmware to upload and I used dc42`s iap.bin.

Firmware Name: RepRapFirmware for Duet
Firmware Version: 1.12a (2016-05-10)
Web Interface Version: HTML: 1.11, JS: 1.11

The upload speed has been dramatic,going from 18.2 KiB/s to well over 287.2 KiB/s.
So many thanks to Christian and dc42 for all the effort invoved.

Quote
jondel
The upload speed has been dramatic,going from 18.2 KiB/s to well over 287.2 KiB/s.
So many thanks to Christian and dc42 for all the effort invoved.

Looks like you need a better SD card. DC42 did a speed test with several and almost hit 1MiB/s with the right card.

[forums.reprap.org]

I'm comfortably seeing 640Kb uploads with the defualt supplied 4Gb MicroSD card. suspect this will jump a lot with a faster card

Firmware Name: RepRapFirmware for Duet
Firmware Version: 1.12a (2016-05-10)
Web Interface Version: HTML: 1.11, JS: 1.11

I have had a lot of trouble with the SD cards being recognised.The only one out of three that works
is the supplied Kingston 4GB card.Even this stopped being recognised until I gave it and the card slot
a clean with a spray cleaning agent and then inserting and removing the card several times.
So yes this may be the reason fot the slowish speeds compared with others and I donot know if it makes a difference
but the card was formatted Fat16 under Linux?

Quote
aussiephil
I'm comfortably seeing 640Kb uploads with the defualt supplied 4Gb MicroSD card. suspect this will jump a lot with a faster card

Firmware Name: RepRapFirmware for Duet
Firmware Version: 1.12a (2016-05-10)
Web Interface Version: HTML: 1.11, JS: 1.11

just got 570Kb with my stock SD card

---

RepRapPro Mendel 3 Tricolour
RepRapPro Fisher
-Carbon Arms
-Easy adjust Carriage+effector
-axis stiffness mods
HE3D -600 delta
-Duet 0.8.5
-PanelDue
-DC42 Height probe
-RobotDigg metal components
Simplyfy3D
RS Design Spark CAD

Using Firmware 1.12-dc42 I often get "Ajax Communication errors". Is this a known problem? I tried Firefox with Windows 10 as well as Google Chrome with Android.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

Quote
Treito
Using Firmware 1.12-dc42 I often get "Ajax Communication errors". Is this a known problem? I tried Firefox with Windows 10 as well as Google Chrome with Android.

No, it's not a known problem, although I have seen it occasionally. Please check that you are using firmware version 1.12a (not 1.12) and DWC 1.11. Is there any other information provided in the Ajax error message?

Another thing that could be useful when the error occurs is to connect Pronterface or similar via USB, send M122, and report the buffer usage stats.

Edited 1 time(s). Last edit at 05/23/2016 03:48AM 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 used Simplify3D. I recently got an timeout-error (opening the file directory), but it also happens during the print status and so on.
For the moment I cannot update the firmware because I am printing the next hour.

RECEIVED: Diagnostics
RECEIVED: Used output buffers: 1 of 32 (18 max)
RECEIVED: Platform Diagnostics:
RECEIVED: Memory usage:
RECEIVED: Program static ram used: 45208
RECEIVED: Dynamic ram used: 40256
RECEIVED: Recycled dynamic ram: 552
RECEIVED: Current stack ram used: 2712
RECEIVED: Maximum stack ram used: 5436
RECEIVED: Never used ram: 6852
RECEIVED: Last reset 11:58:22 ago, cause: software
RECEIVED: Last software reset code & available RAM: 0x0003, 6628
RECEIVED: Spinning module during software reset: GCodes
RECEIVED: Error status: 0
RECEIVED: Bed probe heights: -0.016 0.250 1.379 0.984 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
RECEIVED: Free file entries: 9
RECEIVED: Longest block write time: 0.0ms
RECEIVED: Slowest main loop (seconds): 0.054688; fastest: 0.000000
RECEIVED: Move Diagnostics:
RECEIVED: MaxReps: 4, StepErrors: 0
RECEIVED: Heat Diagnostics:
RECEIVED: Heater 0: I-accumulator = 0.0
RECEIVED: Heater 1: I-accumulator = 94.6
RECEIVED: GCodes Diagnostics:
RECEIVED: Move available? yes
RECEIVED: Stack pointer: 0 of 5
RECEIVED: macro is idle
RECEIVED: http is idle
RECEIVED: telnet is idle
RECEIVED: serial is doing "M122"
RECEIVED: aux is idle
RECEIVED: file is doing "G1 X40.562 Y73.445 E0.0163"
RECEIVED: Network Diagnostics:
RECEIVED: Free connections: 16 of 16
RECEIVED: Free transactions: 24 of 24
RECEIVED: Webserver Diagnostics:
RECEIVED: HTTP sessions: 0 of 8
RECEIVED: FTP connections: 0, state 0
RECEIVED: Telnet connections: 0, state 0

I am a little bit in sorrow. One of the Duet boards that failed and you got from me started with this problem.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

I updated to FW 1.12a and I got a communication error.

RECEIVED: ok
SENT: M122
RECEIVED: Diagnostics
RECEIVED: Used output buffers: 1 of 32 (20 max)
RECEIVED: Platform Diagnostics:
RECEIVED: Memory usage:
RECEIVED: Program static ram used: 45208
RECEIVED: Dynamic ram used: 40232
RECEIVED: Recycled dynamic ram: 576
RECEIVED: Current stack ram used: 2712
RECEIVED: Maximum stack ram used: 5444
RECEIVED: Never used ram: 6844
RECEIVED: Last reset 01:28:25 ago, cause: software
RECEIVED: Error status: 0
RECEIVED: Bed probe heights: 0.002 0.108 1.227 0.996 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
RECEIVED: Free file entries: 10
RECEIVED: Longest block write time: 42.3ms
RECEIVED: Slowest main loop (seconds): 0.220093; fastest: 0.000000
RECEIVED: Move Diagnostics:
RECEIVED: MaxReps: 4, StepErrors: 0
RECEIVED: Heat Diagnostics:
RECEIVED: Heater 0: I-accumulator = 0.0
RECEIVED: Heater 1: I-accumulator = 98.0
RECEIVED: GCodes Diagnostics:
RECEIVED: Move available? no
RECEIVED: Stack pointer: 0 of 5
RECEIVED: macro is idle
RECEIVED: http is idle
RECEIVED: telnet is idle
RECEIVED: serial is doing "M122"
RECEIVED: aux is idle
RECEIVED: file is idle
RECEIVED: Network Diagnostics:
RECEIVED: Free connections: 15 of 16
RECEIVED: Free transactions: 24 of 24
RECEIVED: Webserver Diagnostics:
RECEIVED: HTTP sessions: 0 of 8
RECEIVED: FTP connections: 1, state 2
RECEIVED: Telnet connections: 0, state 0
RECEIVED: ok
SENT: M105
RECEIVED: ok T:209.9 B:63.8

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.