New firmware 1.15 release candidate 3

Quote
dc42
1. What temperature did you set, before you saw it creep to 170C?

2. Are you measuring the temperature using a thermistor, thermocouple, or RTD?

If a heater gets into a fault state, you can reset it using M562 P# where # is the heater number. M0 will turn all heaters off.

UPDATE: I have just managed to reproduce heat creep on one of my printers by using a noisy thermistor channel. So now I will know when I have fixed it (or this particular cause of it).

1. Temperature starts creeping up immediately after bootup, without setting any temp. While I was testing (and temp was already creeping), I picked temp at random, just to check whether the hotend is still responsive.

2. I have Metal-J hotend from Robotdigg. They state 3950 1% Thermistor on their page. I have confirmed accuracy using multimeter, with K-type thermocouple - it was within 1C range.

Quote
minimum

Quote
dc42
1. What temperature did you set, before you saw it creep to 170C?

2. Are you measuring the temperature using a thermistor, thermocouple, or RTD?

If a heater gets into a fault state, you can reset it using M562 P# where # is the heater number. M0 will turn all heaters off.

UPDATE: I have just managed to reproduce heat creep on one of my printers by using a noisy thermistor channel. So now I will know when I have fixed it (or this particular cause of it).

1. Temperature starts creeping up immediately after bootup, without setting any temp. While I was testing (and temp was already creeping), I picked temp at random, just to check whether the hotend is still responsive.

2. I have Metal-J hotend from Robotdigg. They state 3950 1% Thermistor on their page. I have confirmed accuracy using multimeter, with K-type thermocouple - it was within 1C range.

I have the exact same issue, temp climbs to 180c after boot

I found and fixed the problem that was causing the temperature to creep up on the second extruder on one of my printers. I hadn't yet tuned that heater so I was using legacy PID parameters. When legacy PID parameters were used, the code was using a D constant much larger than the one provided. Coupled with the noise in the reading from that thermistor channel, this sometimes caused the D term to override the P term and command the heater on.

I have fixed this in release 1.15b, available at [github.com].

To those of you who have been trying my recent releases, thank you for your patience.

Edited 1 time(s). Last edit at 08/25/2016 05:50PM 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 found and fixed the problem that was causing the temperature to creep up the second extruders on one of my printers. I hadn't yet tuned that heater so I was using legacy PID parameters. When legacy PID parameters was used, the code was using a D constant much larger than the one provided. Coupled with the noise in the reading from that thermistor channel, this sometimes caused the D term to override the P term and command the heater on.

I have fixed this in release 1.15b, available at [github.com].

To those of you who have been trying my recent releases, thank you for your patience.

Upgraded to 1.15b and the heat creep is gone

I can also confirm that the heat creep has been fixed. Thanks dc42 and Chrishamm for the awesome work!

Now we just need an integrated stl and gcode viewer with live tracking in DWC haha.

Thanks both for confirming it is fixed.

---

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

Just looking at the reprap gcode wiki and I cannot find any mention about homing for the A,B,C Axes. I was hoping that I could just disable these?

Quote
DADIY
Since updating I see a couple of things I wouldn't expect -

After homing I see the warning symbol next to the printer name and the text -
The following axes are not homed: A, B, C

Also in settings -> machine properties it says -

Z-Probe
Type:
Two Switches (4)

But I have three switches.

Any tips how to tidy this up?

Edited 1 time(s). Last edit at 08/26/2016 02:51AM by DADIY.

---

DC42 Kossel 330mm x 2meters
My Thingiverse Creations

Creep is fixed.

I tried to use the new autotuning feature:
For test temp, I set 200C. Heats up nice and very smoothly until temp more or less stabilises at about 197.5-198C. After a short period I get message "Error: heating fault on heater 1, temperature rising much more slowly than the expected 0.0°C/sec" and heater faults.
I'm sure most of the problem is coming from my abnormally powerful heater (12V heater @ 15,1V).

For now I have played around almost an hour with heater, trying to reproduce the fault. So far unsuccessful.


Edit: Thank you David!

Edited 1 time(s). Last edit at 08/26/2016 03:39AM by minimum.

Just updated to 1.15b and the homing a,b,c axes issue has gone. But as soon as I try a print with the bed heater turned on to 70 I get the following logged even though the temperatures look fine, I print this file regularly and its almost always a success.

Also even though the heater was turned off the print continued causing a blockage of the nozzle trying to push plastic through a cooling nozzle.

20:38:51Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
20:38:47Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
20:38:41Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
20:38:36Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
20:38:32Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
20:38:26Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
20:38:20Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
20:37:46Error: heating fault on heater 1, temperature excursion too large
20:37:34M32 Working/dtk mk8.g
File Working/dtk mk8.g selected for printing
20:37:16Calibrated 6 factors using 10 points, deviation before 0.671 after 0.015

---

DC42 Kossel 330mm x 2meters
My Thingiverse Creations

Just a quick question - do I have to do anything with existing M305 commands in config.g before playing with M307 or do I leave them as they are?

---

Reality is in fact virtual.

In response to more than one post:

- The "temperature excursion too large" heater fault means that after heating to the correct temperature, the temperature subsequently departed more than 10C from the set temperature. This used to be 5C in the 1.15 release candidates but I increased it to 8C for the 1.15 release and 10C in 1.15b. The reason for this check is to detect faults such as the heater cartridge or thermistor falling out of the heater block - see this thread [forums.reprap.org]. It's not unusual for the hot end temperature to drop a few degrees when you turn on the print cooling fan, however I regard a drop of 10C as excessive because of the effect it will have on extrusion. @DADIY, can you try another print and observe exactly what is happening?

- It would make sense to stop or at least pause the print if a heater fault occurs. I'll add this to the work list for the next release. Any thoughts on what would be best? I think Smoothieware responds to a heater fault by executing an emergency stop, but perhaps that is a little too drastic?

- The M305 commands are not affected by the changes on version 1.15.

---

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 tried another few tests, on all the tests the hot end should be 220c and 70c for the bed.

Test 1 - Started print, temperatures came up and the hot end over shot to 265c then fault occurred.
Test 2 - Restarted printer, manually set temperatures before printing and just after starting to print the temperature dropped ~70c and fault occurred.
Test 3 - Same as test 2 but waited longer before starting print, but after the print starts temperature dropped - fault occurred.
Test 4 - Same as test 2 but waited even longer - Worked fine - no issues, started at 220c/70c bed and dropped to 205c after first layer as normal.


In the even of a fault I think the printer should stop and raise the head out of the material, temperature controlled fans etc should stay on.

---

DC42 Kossel 330mm x 2meters
My Thingiverse Creations

Hi DADIY,

Let's sort out that huge overshoot first. It looks like the heater model and/or the PID parameters are completely wrong for your hot end.

- Did you using auto tuning and then set the M307 parameter in config.g, or are you using M301 to set PID parameters in config.g?

- If you are using M307, what parameters are you using?

- If you are using M301, what parameters are you using, and did you adjust the I and D parameters as in the instructions for upgrading from previous versions?

Edited 2 time(s). Last edit at 08/28/2016 12:58PM 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'm using the M301 command to set the heater on duet 0.6.

I commented out the Fisher default and tweaked the numbers as per the instructions - this is in my config.g


;M301 H1 P12 I0.4 D80 W180 B300 ; Set tool 0 PID parameters
M301 H1 P12 I0.8 D40 W180 B300 ; Set tool 0 PID parameters for firmware 1.15+

The over shoot doesn't always happen, I just booted the printer from cold and set the temperature to 220c and it warmed up and stabilized nicely. I dont appear to have any loose connections to the thermistor.

Have you considered having a setting to disable the overheat protection?

---

DC42 Kossel 330mm x 2meters
My Thingiverse Creations

Please try the auto tuning. If you want to continue to use manual PID parameters after that, you can set the M301 T parameter to 255 divided by the gain reported after auto tuning.

---

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 had assumed that Autotune was only for the duetwifi as I'd only seen it documented in their forum .

I ran the following for auto tune (using P0.5 cancelled itself with a message to reduce P or increase S)
M303 H1 P0.4 S240

M307 H1 - reported
Heater 1 model: gain 451.5, time constant 52.9, dead time 3.8, max PWM 1.00, in use: yes, mode: PID
Setpoint change: P5.5, I0.10, D14.6
Load change: P5.5, I0.73, D14.6

Added to config.g
M307 H1 A451.5 C52.9 D3.8 B0

So far I have done one test and everything looked very smooth and no issues. I will let everything cool down and do another test later.

---

DC42 Kossel 330mm x 2meters
My Thingiverse Creations

Hello all, and thanks for all your work!

I'm experiencing some issues with the PanelDue and the heated bed since upgrading to 1.15b.

1. When first powering on my printer, the PanelDue display is stuck at "starting up" until I press the reset button on the PanelDue board. Then it displays normally.
2. When adjusting the bed temperature from the PanelDue display, the temperature never changes and DWC reports a fault with the bed temperature. When I set the bed temperature via DWC, the bed does heat up, but errors after a few minutes and never reaches full temp. When I receive the bed fault, the only way to clear it is using the emergency stop, or powering off and on the printer.

These issues only started to occur after upgrading to FW dc42-1.15b on the Duet board and converting to the autotune PID (M303/M307). Before then, I was running ver. dc42-1.14 on the Duet board and using M301 to control the temperatures.
I reverted back to M301 for the bed, but the issue still occurred. I'm double checking the bed wiring now to ensure good connectivity.

A copy of my current config.g is attached.
config.g

Any help is appreciated...

Rostock Max V2 with Diamond head
Duet 0.85 with Duex4-fw ver dc42 1.15b
PanelDue (7 inch)-fw ver 1.14
Duet Web Control ver 1.12

Edited 2 time(s). Last edit at 08/29/2016 08:12AM by CRPerryJr.

Quote
dc42
- It would make sense to stop or at least pause the print if a heater fault occurs. I'll add this to the work list for the next release. Any thoughts on what would be best? I think Smoothieware responds to a heater fault by executing an emergency stop, but perhaps that is a little too drastic?

Yes, please add that. As to what would be best, I wish I knew. Some kind of configurable option(s) would be preferable, to leave some choice/control to user

Quote
CRPerryJr
Hello all, and thanks for all your work!

I'm experiencing some issues with the PanelDue and the heated bed since upgrading to 1.15b.

1. When first powering on my printer, the PanelDue display is stuck at "starting up" until I press the reset button on the PanelDue board. Then it displays normally.
2. When adjusting the bed temperature from the PanelDue display, the temperature never changes and DWC reports a fault with the bed temperature. When I set the bed temperature via DWC, the bed does heat up, but errors after a few minutes and never reaches full temp. When I receive the bed fault, the only way to clear it is using the emergency stop, or powering off and on the printer.

These issues only started to occur after upgrading to FW dc42-1.15b on the Duet board and converting to the autotune PID (M303/M307). Before then, I was running ver. dc42-1.14 on the Duet board and using M301 to control the temperatures.
I reverted back to M301 for the bed, but the issue still occurred. I'm double checking the bed wiring now to ensure good connectivity.

A copy of my current config.g is attached.
[attachment 83183 config.g]

Any help is appreciated...

Rostock Max V2 with Diamond head
Duet 0.85 with Duex4-fw ver dc42 1.15b
PanelDue (7 inch)-fw ver 1.14
Duet Web Control ver 1.12

If you get a heater fault, you can clear it with the M562 command, e.g. M562 P1 will clear a fault on heater 1 (the first extruder).

When a heater fault occurs, an error message is produced. This will tell you what caused the fault. Go to the Console page or DWC of PanelDue to see the error message.

Edited 1 time(s). Last edit at 08/30/2016 06:06AM 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].

Thank you dc42 for your reply.

Do you have an idea why I am experiencing item #1 since upgrading to Duet FW 1.15b and Paneldue 1.14? Nothing has changed hardware-wise since first installation of Duet FW 1.11 and Paneldue 1.13 back in May. This only occurs at power on. Reboots do not reproduce the issue.

Thanks,

PS. I reverted back to Duet FW 1.14 and DWC 1.11 and returned to using M301 in my config.g and the issues above are no longer present.
config.g

Edited 3 time(s). Last edit at 08/29/2016 07:16PM by CRPerryJr.

After a number of prints the heater issue has been cured by using auto tuning, Also it would appear that the temperature is much more stable than before which has allowed me to reduce the temperature in my prints.

thanks DC42 for all you do

Quote
DADIY
I had assumed that Autotune was only for the duetwifi as I'd only seen it documented in their forum .

I ran the following for auto tune (using P0.5 cancelled itself with a message to reduce P or increase S)
M303 H1 P0.4 S240

M307 H1 - reported
Heater 1 model: gain 451.5, time constant 52.9, dead time 3.8, max PWM 1.00, in use: yes, mode: PID
Setpoint change: P5.5, I0.10, D14.6
Load change: P5.5, I0.73, D14.6

Added to config.g
M307 H1 A451.5 C52.9 D3.8 B0

So far I have done one test and everything looked very smooth and no issues. I will let everything cool down and do another test later.

---

DC42 Kossel 330mm x 2meters
My Thingiverse Creations

Quote
CRPerryJr
Thank you dc42 for your reply.

Do you have an idea why I am experiencing item #1 since upgrading to Duet FW 1.15b and Paneldue 1.14? Nothing has changed hardware-wise since first installation of Duet FW 1.11 and Paneldue 1.13 back in May. This only occurs at power on. Reboots do not reproduce the issue.

I can only think that it is something to do with the extra 0.5 second startup delay in 1.15b. However, I don't understand why you don't get a successful connection. The initial request from PanelDue may be coming too soon for the Duet to response to it, but it should respond to the retries. Please can you try 1.15b again, with a PC connected via USB running Pronterface or another host, and send M111 S1 P3 to enable gcode debugging. Then see if you get any "aux:" gcode messages echoed.

PS - also, when PanelDue is displaying "Starting up", do the temperatures and other parameters look sensible, and can you still switch to other pages using the buttons at the bottom?

Edited 1 time(s). Last edit at 08/30/2016 06:18AM 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].

Is there any chance of adding more functionality to the webcam integration? For instance, RTSP, username/password input, etc? Right now I have to connect to it using my phone ip viewer because I have my ip cam password protected.

Quote
Masterjuggler
Is there any chance of adding more functionality to the webcam integration? For instance, RTSP, username/password input, etc? Right now I have to connect to it using my phone ip viewer because I have my ip cam password protected.

We'd love to support a camera window using RTSP. Unfortunately, last year Google removed the NPAPI support from Chrome that allowed the VLC plugin to display an RTSP stream. Currently it appears to be more or less impossible to display RTSP content in Chrome without using a separate server process to receive the RTSP stream. I haven't fully investigated whether it is possible under Firefox or Edge.

---

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

dc42 is right, I would add support for it if there was a native way to implement it, but no browser seems to support RTSP and no vendor I know is planning on adding support for it.

Instead of RTSP I guess it would be possible to use a webm stream instead (using a video tag) but I haven't checked if that might work at all.

Yeah, a video element would be the modern way to do it. The content can then be HLS/DASH/whatever the client supports.

Found a typo:

Quote

14:55.21 M303
Heater 1 tuning succeeded, use M207 H1 to see result

Should be M307

Updating reprap wiki regarding autotuning releated topics would be nice too

Quote
dc42

Quote
CRPerryJr
Thank you dc42 for your reply.

Do you have an idea why I am experiencing item #1 since upgrading to Duet FW 1.15b and Paneldue 1.14? Nothing has changed hardware-wise since first installation of Duet FW 1.11 and Paneldue 1.13 back in May. This only occurs at power on. Reboots do not reproduce the issue.

I can only think that it is something to do with the extra 0.5 second startup delay in 1.15b. However, I don't understand why you don't get a successful connection. The initial request from PanelDue may be coming too soon for the Duet to response to it, but it should respond to the retries. Please can you try 1.15b again, with a PC connected via USB running Pronterface or another host, and send M111 S1 P3 to enable gcode debugging. Then see if you get any "aux:" gcode messages echoed.

PS - also, when PanelDue is displaying "Starting up", do the temperatures and other parameters look sensible, and can you still switch to other pages using the buttons at the bottom?

Same problem here with my 7" screen but not my 4.3". when it is locked on "Starting Up" none of the buttons work and the parameters are at 0. I will try and connect via USB and get more info.

I am working on a new PanelDue firmware release that fixes the startup issue that is sometimes seen with RRF 1.15.

---

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'm seeing what I believe is a glitch with the new temperature monitoring code.

My typical print startup routine is:

Preheat the bed
Preheat the hotend to 170C
Auto Calibrate the bed
Bring the hotend to printer temperature and print.

I goofed and managed to knock the bed off my FSR sensors before the normal routine and killed power immediately when I saw the auto calibrate failing.

After powering back up, the PanelDue was showing temperatures in a purple/dark red color and I could not set the temperatures manually, nor would it respond to gcode for temperature changes until the bed and the hotend had cooled down closer to ambient temperatures.

I suspect it sees what it believes is an elevated temperature at startup and throws an error? Can it monitor for a few seconds and look for a drop and clear the error at startup?

I've got a lot of thermal mass in my heated bed, so it takes about 30 minutes to get back down to ambient temps to restart the print job. AND, I will be more careful next time, but it's a behavior that may confuse others.

Thanks!