New firmware 0.65e-dc42 and web interface 0.90

I have just released firmware 0.65e-dc42 at [github.com] and web interface 0.90 at [github.com]. The sole purpose of this release is to include changes made by RepRapPro that were not already in my 0.59 series, in particular the preparatory support for multiple extruders.

There are some incompatible changes that you need to be aware of when upgrading to 0.65e-dc42 from an earlier dc42 version (or from RRP's 0.57a version):

* You must edit your config.g file. Replace the T0 command by T1.

* You must upgrade to web interface 0.90 at the same time, or you won't be able to control the extruder temperature. You can do this by first upgrading the firmware, then upload reprap.htm and reprap.js, then close the browser tab and open a new one.

* You must edit your custom gcode in slic3r. Change T0 to T1. Old gcode files with T0 in them will no longer work.

* If you have multiple Duet boards on the same network, then the selection of different MAC addresses is no longer automatic. Instead, you must set the MAC addresses using M540 commands in config.g.

I will post a list of differences between RRP 0.65e and 0.65e-dc42 when I have generated it.

Edited 1 time(s). Last edit at 06/05/2014 05:11PM 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].

Here is a list of the differences (the ones I can remember!) between my fork and RRP's master:

Additional functionality in 0.65e-dc42 release compared to RRP 0.65e:

* The Duet can serve all the files needed by the web interface

* All ADC readings are done in the tick ISR to avoid the processor having to wait for ADC conversions and provide faster thermistor and z-probe response. Z-probe modulation frequency is increased to 500Hz.

* Additional over-temperature protection is done in the tick ISR, and the watchdog timer resets the system if the tick interrupt fails.

* A software watchdog is used to reset the processor if it gets stuck in a spin loop. An error code is saved to flash memory to help diagnose the issue.

* Printing doesn't hang if the USB port is disconnected (or attached PC goes to sleep) during a print.

* The number of bits of temperature resolution is increased from 10 to 13 (i.e. 12-bit ADC + 1-bit oversampling) to increase the temperature resolution.

* Thermistor parameters and ADC corrections can be set (M305 command).

* M208 command allow you to set axis minimum positions (e.g. negative x-axis position) as well as maximum positions.

* G1 commands with S1 parameter (i.e. seeking for endstops) do not need to be followed by a G92 command to work properly.

* Long filename support for files on the SD card

* The limit of 42 files in the list of gcode files on the SD card returned to the web interface or Pronterface is removed (but there is still a limit of 1000 characters)

* M220 (set speed factor override) and M221 (set extrude factor override) commands are supported. (+)

* Option to invert cooling fan PWM

* Additional z-probe type 3 is supported, for boards that support more than one type of z-probe

* Separate G31 parameters can be saved for z-probe types 0, 1/2, and 3

* Various parameters (G31 values, IP address, MAC address, thermistor parameters, PID parameters) are saved to flash memory (note that these values do not survive a firmware upgrade)

* M111 S2 command added to show additional parameters such as bed compensation heights, last reset reason, up-time, and diagnostic error codes

* Absolute extruder moves work properly

* Software reset command added (M999)

* I believe some movement bugs are fixed. In particular, one acceleration bug is fixed or at least less severe, and my version does not seem to have a problem with high extruder speeds.

* When pausing a print from SD card, if the printer is executing a 'wait' command such as M116, control is returned to the web interface immediately, without waiting for the command to complete (which could take a long time).

Additional functionality in web interface 0.90 compared to RRP 0.65:

* Faster (>6Mbytes/min), more reliable file uploading, with reporting and graceful recovery if an upload fails.

* All web files and config files can also be uploaded.

* Temperature-setting buttons can be used during a print from SD card.

* More accurate (usually!) estimate of print completion time, based on filament consumption.

* The machine name is displayed.

* The filament requirement and object height are fetched automatically from the SD card file being printed, for use in estimating the completion time.

* Works with FireFox as well as Chrome.

* "Upload & Print" button (replaces direct web print button, uploads to the SD card first for more reliable printing).

* Extruder box reports total filament extruded, not the amount extruded in the last move.

* Additional status Halted is shown (if emergency stop has been used) as well as Ready and Active


(+) It looks like M221 may no longer work after the merge. Will fix in next release. It was a long and difficult merge, so I may have introduced other bugs too.

Edited 6 time(s). Last edit at 06/05/2014 05:45PM 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].

Works great. thanks!

Same here. I compiled off source against Arduino 1.5.6 (with lib changes) and is working fine.

As mentioned one has to take care with existing gcode files. To avoid a lot of reslicing I just hand edited the T1 setting.

Thanks for the list dc, I can wave it under Adrian's nose! And get him to tick them off when he integrates them. He's still refining the movement code; there's another release he's pushed to the 'duet' branch.

Ian
RepRapPro tech support

Edited 1 time(s). Last edit at 06/04/2014 07:38PM by droftarts.

Quote
dc42
* You must edit your config.g file. Replace the T0 command by T1.

[notepad-plus-plus.org]
with this can be done easily..... and very quickly
also useful to modify sys files...

dc42 very nice work!!! ....
I'm still trying RepRapFirmware FIRMWARE_VERSION:0.59e-dc42 delighted on the network control...v081
Thanks a lot!

My best
Dario

---

Ormerod 187
Firmware Electronics: Duet 0.6
Firmware Version:1.18.1 (2017-04-07)
Web Interface Version:1.15a
Slic3r 1.2.9a and Simplify3D 4.0.0
[www.dropbox.com]

I just added an item that I forgot earlier to the list of changes in my firmware fork:

* When pausing a print from SD card, if the printer is executing a 'wait' command such as M116, control is returned to the web interface immediately, without waiting for the command to complete (which could take a long time).

---

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

Hi DC,

Just upgraded to 65e this morning and my homez is causing the duet to reboot. I narrowed it down to the M80 command I had at the beginning of the file.

EDIT: Just tried to print and it will not extrude, gone back to 59 and its working. Has something major changed that requires my config files or gcode to be modified?

EDIT2: DOH! I should have read the full post properly.

Quote
* You must edit your config.g file. Replace the T0 command by T1.

Regards,

Les

Edited 2 time(s). Last edit at 06/08/2014 03:39AM by Pointy.

---

Pointy's Things
Pointy's Blog

Quote
Pointy
Just upgraded to 65e this morning and my homez is causing the duet to reboot. I narrowed it down to the M80 command I had at the beginning of the file.

Hi Les,

Sorry, I can't reproduce that problem. I've put M80 at the start of my homez.g file, and z-homing still works ok. Can you post the homez.g file that causes 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].

Here you go...

;turn on 12v
;M80
; turn on extruder
M104 S190
; set to Relative Positioning
G91
; move up 5mm
G1 Z5 F2000
; set to Absolute Positioning
G90
; move to 100, 100
G1 X100 Y100 F2000
; wait for extruder to reach temperature
M109 S190
; move Z to -200 and trigger switch
G1 Z-200 F100 S1
; zero Z
G92 Z0
; move back up 0.5
G1 Z0.5 F200
; zero Z
G92 Z0

With the M80 commented out it works for me, I'll try it again later - have to pop out for a few hours. What's the command to get the last reset code?

Also the code doesn't work as it did before I upgraded, it used to move to the centre and then wait for temperature, now it doesn't move until the extruder hits the target temp.

Regards,

Les

---

Pointy's Things
Pointy's Blog

The command to get the last reset code is m111s2.

---

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

Strange, I can't replicate it now, but it definitely did it 3 times on the trot.

Regards,

Les

---

Pointy's Things
Pointy's Blog

Installed the new firmware and web interface this morning, amended config.sys and all gcodes to reflect T1 rather than T0, and it is working like a dream except for one worrying glitch...on all three (different) prints I've tried so far, when the bed comes up to temperature at the beginning of the print (bed is set to 65 for first layer and 60 thereafter) it doesn't stop heating up and the print does not start. If I pause the print, then tell it to resume it immediately cools back down and commences the print as if nothing had happened - any thoughts on the cause for this?

Hi MrCrispi, can you post the first 50 or so lines of the gcode file you are trying to print?

---

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
Hi MrCrispi, can you post the first 50 or so lines of the gcode file you are trying to print?

Voila (Note: this is just one of three different files, all exhibiting the same issue...I expect all my files will do the same, so issue must be in the slicing or config file somewhere...):

; generated by Slic3r 1.0.0RC2 on 2014-06-07 at 23:21:54

; layer_height = 0.24
; perimeters = 2
; top_solid_layers = 3
; bottom_solid_layers = 3
; fill_density = 0.1
; perimeter_speed = 20
; infill_speed = 20
; travel_speed = 60
; nozzle_diameter = 0.5
; filament_diameter = 1.75
; extrusion_multiplier = 0.90
; perimeters extrusion width = 0.50mm
; infill extrusion width = 0.87mm
; solid infill extrusion width = 0.85mm
; top infill extrusion width = 0.85mm
; first layer extrusion width = 0.48mm

G21 ; set units to millimeters
M104 S195 ; set temperature
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
M140 S65; Set bed temperature
G1 Z5 F200 ; lift nozzle
G1 X40 Y50 F2000; Go to wait for warm position
M116; Wait for all temperatures
G10 P0 S190 R0 ; Set extruder temperature
T1; Select extruder
M116; Wait for all temperatures
M109 S195 ; wait for temperature to be reached
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
G1 Z0.240 F3600.000
G1 F1800.000 E-2.50000
G1 X59.360 Y59.360 F3600.000
G1 E2.50000 F1800.000
G1 X60.450 Y58.410 E0.06288 F600.000
G1 X64.080 Y55.630 E0.19885
G1 X65.270 Y54.840 E0.06212
G1 X66.550 Y54.210 E0.06205
G1 X70.770 Y52.460 E0.19869
G1 X71.780 Y52.100 E0.04663
G1 X72.820 Y51.830 E0.04673
G1 X73.610 Y51.700 E0.03482
G1 X78.080 Y51.120 E0.19603
G1 X79.490 Y51.030 E0.06145

I believe the problem is the line:

G10 P0 S190 R0 ; Set extruder temperature

It should use P1 instead of P0. Does that command come from the custom gcode?

Edited 1 time(s). Last edit at 06/08/2014 02:43PM 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
dc42
I believe the problem is the line:

G10 P0 S190 R0 ; Set extruder temperature

It should use P1 instead of P0. Does that command come from the custom gcode?

Thanks @DC as ever for all your insight - Yes it does, and I can easily change it on my next print to check it out, but intrigued as to why an extruder setting would now affect the bed temp. as it has been like this for a long while and the extruder temp is still working fine?

Quote
MrCrispi
Thanks @DC as ever for all your insight - Yes it does, and I can easily change it on my next print to check it out, but intrigued as to why an extruder setting would now affect the bed temp. as it has been like this for a long while and the extruder temp is still working fine?

Heater 0 is the bed heater, so your G10 command was commanding the bed to 190C. This is how RRP's 0.65e firmware behaves, and my fork has inherited that behaviour after the merge. But I'm not so sure it is a good idea, so maybe I should make a change to treat P0 as an error in the G10 command.

---

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

The modified firmware and the web-interface are really great. But I have found some bugs. Probably because my settings are not smooth yet. If I abort a print (web-interface), I press "pause" and then "reset". The bed stays on, but that is not the big problem. After fixing whatever problem and selecting the same g-code file the duet reboots. Normally this should happen as soon as I press "reset", I think so. But this behaviour has been with the original firmware, too.

According to the documentation you should add "G31 Z1.8 P650" (values may vary) to your config.g. Unfortunately I did not see this using the old firmware. But after adding this parameter after installing your fw I was not able to home the x-axis anymore. I had to change the parameter to "G31 Z3.0 P364" in my case. But why does calibrating the z-axis (or the proximity sensor) influates the homing of the x-axis?

Yup - that cured it...

Brilliant sleuthing as ever @DC - many thanks...don't know what we'd do without you...

Edited 1 time(s). Last edit at 06/08/2014 04:37PM by MrCrispi.

Quote
TreitoI
press "pause" and then "reset". The bed stays on, but that is not the big problem. After fixing whatever problem and selecting the same g-code file the duet reboots. Normally this should happen as soon as I press "reset", I think so. But this behaviour has been with the original firmware, too.

Strange, I have done this lots of times, and never seen that. The bed stays on after pressing Pause, but goes off after Reset. And the Duet doesn't reboot when I try to re-print the same .g file. Next time it reboots by itself, please select the message log tab, send m111s2, and let me know what the last reset reason and last software reset code reported in the reply are.

Quote

According to the documentation you should add "G31 Z1.8 P650" (values may vary) to your config.g. Unfortunately I did not see this using the old firmware. But after adding this parameter after installing your fw I was not able to home the x-axis anymore. I had to change the parameter to "G31 Z3.0 P364" in my case. But why does calibrating the z-axis (or the proximity sensor) influates the homing of the x-axis?

The Duet uses the G31 threshold when detecting the x-axis homing tab as well as when z-homing. Put a piece of white paper or white tape on top of the x-homing tab, that should fix it.

Edited 3 time(s). Last edit at 06/08/2014 03:44PM 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
dc42
The Duet uses the G31 threshold when detecting the x-axis homing tab as well as when z-homing. Put a piece of white paper or white tape on top of the x-homing tab, that should fix it.

My idea was that either the firmware uses the default value for homing the x-axis or you can edit this value, for example 636 for the z-axis and 364 for the x-axis.
I can send you a log, but now I am "wasting" the rest of the delivered white PLA for a filament holder. It is a strange bug. restarting the gcode-file ends in the following behaviour: 1. Heating up the bed. 2. Homing all axes. 3. Now the extruder should be heated up, but at this point there is the reset.

By the way I like your information of how many PLA was already used during printing. Unfortunately I have no clue how many PLA is left on the delivered spool. Maybe a setting override would be nice. I am going to exchange the Ormerod parts with ABS printed parts. But I cannot use the original gcode-files without either modifying them or even reslice them.

Quote
Treito

Quote
dc42
The Duet uses the G31 threshold when detecting the x-axis homing tab as well as when z-homing. Put a piece of white paper or white tape on top of the x-homing tab, that should fix it.

My idea was that either the firmware uses the default value for homing the x-axis or you can edit this value, for example 636 for the z-axis and 364 for the x-axis.

I agree, it would be better to allow separate G31 P values to be set for the X and Z axis. However, white tape on the x-homing tab usually does the trick. Alternatively, use a higher z-homing height, hence lower G31 P value (although that will increase the sensitivity to ambient IR).

Edited 2 time(s). Last edit at 06/08/2014 04:30PM 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].

Ciao a tutti, ho caricato il firmware 065e (ultimissimo) e anche update arduino (ultimissimo) seguendo tutte le procedure, ma continuo ad avere problemi con la mia Ormerod: non legge la SD e lanciando il comando M503 continua a dirmi Can't open 0:\sys\config.g to read from. Error code:1
Configuration file not found.

E' giorni che provo, ma nulla di fatto.
Grazie

Traslate (google, sorry):
Hello everyone, I have uploaded the firmware 065th (very last) and also update Arduino (newest) following all the procedures, but I still have problems with my Ormerod: does not read the SD card and running the command M503 keeps telling me: Can not open 0: \ sys \ config.g to read from. Error code: 1
Configuration file not found.

And 'days that I feel, but nothing.
thanks

Quote
simosartori76

Hello everyone, I have uploaded the firmware 065th (very last) and also update Arduino (newest) following all the procedures, but I still have problems with my Ormerod: does not read the SD card and running the command M503 keeps telling me: Can not open 0: \ sys \ config.g to read from. Error code: 1
Configuration file not found.

Are you using the original SD card supplied by RepRapPro? If yes, is it Kingston Memory branded card? If it is not, then that SD card is no good and you need to buy a better one. Lots of users (including me) had this problem. Look for a 4Gb Class 10 SDHC card.

---

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
Pointy
Strange, I can't replicate it now, but it definitely did it 3 times on the trot.

Regards,

Les

Was the M80 command actually turning on the 12V power when it was previously off? If so, then the reset may have been caused by a hardware glitch, especially if the USB cable was connected. If it happens again, then the last reset reason and last software reset code reported by m111s2 may help to track down 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].

Hi dc42

Great firmware and excellent control software, we can now see exactly what's going on. Thank you and iamburny's for all your ongoing hard work, it's very much appreciated.

The Omerod is a great little printer and the kit an excellent way of learning about 3D printing. I'm glad I chose it.

Thanks again

RayC40

WELL DONE! PERFECT!
I changed the SD and the RepRap now works!
Thank you!

The progress bar hung after the last big print. See attached picture.

14:58:11 Program static ram used: 42044 Dynamic ram used: 38476 Recycled dynamic ram: 1400 Current stack ram used: 1288 Maximum stack ram used: 2280 Never used ram: 14104 Last reset 00:01:34 ago, cause: watchdog Last software reset code & available RAM: 0x0000, 16160 Error status: 0 Bed probe heights: 0.000 0.000 0.000 0.000 Free file entries: 10

Regarding the reset problem.