New firmware 1.15 release candidate 3

I noticed that after uploading too many gcode files, the printer would disconnect from DWC when trying to view the list of uploaded files. Upload & print worked fine, I just couldn't view the list of previously uploaded files.

I am unsure if this is a function of sheer number of files or size of the gcode folder on the sd card, but after moving the card to my computer to manually delete files, I now have no issue through DWC. It's on firmware 1.15b and DWC 1.12.

I've got a backlog of stuff to print at the moment, but if I get some downtime I'll experiment to see if I can reproduce the issue.

Quote
joestefano

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.

This is believed fixed in the new PanelDue 1.15 beta firmware - see [forums.reprap.org]. It was caused by a combination of RRF returning very large temperature values just after startup, and the GNU implementation of the strtod function crashing or hanging when it tried to parse them.

---

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
Masterjuggler
I noticed that after uploading too many gcode files, the printer would disconnect from DWC when trying to view the list of uploaded files. Upload & print worked fine, I just couldn't view the list of previously uploaded files.

I am unsure if this is a function of sheer number of files or size of the gcode folder on the sd card, but after moving the card to my computer to manually delete files, I now have no issue through DWC. It's on firmware 1.15b and DWC 1.12.

I've got a backlog of stuff to print at the moment, but if I get some downtime I'll experiment to see if I can reproduce the issue.

Chrishamm may have a better idea of what is going on. You can use subfolders of /gcodes to make large numbers of files more manageable.

---

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
minimum
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!

Assuming there is no actual fault, the "temperature rising more slowly than expected" message along with the undershoot you are seeing means that the gain of your heater is lower than the value in your M307 command. Try auto tuning it again, or just reduce the A parameter in the M307 command by about 25%.

---

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
gen2eng
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!

Please try firmware 1.15c if you haven't already. It fixes the issue of an incorrect temperature reading at startup on some machines.

---

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

Updated to 1.15c and I'm still getting the purple temp and unable to change. I'm still using 1.14 PanelDue firmware with a 0.8.5 board.

Quote
gen2eng
Updated to 1.15c and I'm still getting the purple temp and unable to change. I'm still using 1.14 PanelDue firmware with a 0.8.5 board.

1. If the PanelDue is completely unresponsive to touch when this happens, please update the PanelDue firmware to 1.15beta3.

2. If the temperature fault happens when you try to heat to operating temperature, please auto tune the heater as described at [duet3d.com].

HTH David

---

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 would like to give a little feedback after testing the 1.15c for a couple of days, mostly regarding smoothness of movement and jerks.

I notice that on small radius circles, the movement is now really smooth, but at the same time, it seems to me that the controller does not take into account any sudden direction changes or jerks which are setup in the config. I am printing at 50mm/s and small 3mm diameter circles are printed at the maximum speed, even if that 3mm diameter circle represents a sudden direction change on the axis ! This really puts quite a lot of stress into the printer and I can see that it has enough force to deflect the table on which the printer sits. The printer itself is rigid enough not to cause printing issues, but due to it's heavy components, I would like to reduce those strong jerks.

On curves that are larger, the movement still doesn't seem smooth, like it is pausing for a few milliseconds and than continuing.

Are these known issues or this is how every controller works ? I have no further experience with any other controller except duet.

The firmware honours the acceleration and jerk settings you configure in config.g. If you feel that there is too much stress on the printer at direction changes, try reducing the acceleration and/or jerk settings.

Ideally we would only need an acceleration setting and no jerk would be allowed. Unfortunately, circles and curves in gcode generated from STL files are made up of sequences of short straight line segments. If no jerk was allowed, then the print head would have to come to a standstill between each pair of line segments because of the direction change, and printing curves would be very slow. So the jerk setting needs to be high enough so that curves are printed at a reasonable speed.

Regarding pausing while printing large curves, this was a known problem in older firmware when printing at high speeds. I was able to print my test curves smoothly at 100mm/sec but not at 200mm/sec. This is fixed in 1.15.

You may stil get pausing if you print from a PC over USB instead of from SD card, especially if your PC software is not configured to use driver-level flow control.

HTH David

---

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 firmware honours the acceleration and jerk settings you configure in config.g. If you feel that there is too much stress on the printer at direction changes, try reducing the acceleration and/or jerk settings.

Ideally we would only need an acceleration setting and no jerk would be allowed. Unfortunately, circles and curves in gcode generated from STL files are made up of sequences of short straight line segments. If no jerk was allowed, then the print head would have to come to a standstill between each pair of line segments because of the direction change, and printing curves would be very slow. So the jerk setting needs to be high enough so that curves are printed at a reasonable speed.

Regarding pausing while printing large curves, this was a known problem in older firmware when printing at high speeds. I was able to print my test curves smoothly at 100mm/sec but not at 200mm/sec. This is fixed in 1.15.

You may stil get pausing if you print from a PC over USB instead of from SD card, especially if your PC software is not configured to use driver-level flow control.

HTH David

I am printing from SD card, never had any issues. Those pauses are not easily seen with the naked eye, just by the sound of it (like grinding something) and the surface quality seems not to suffer in any way. It's not a big issue, just wanted to give some feedback, maybe it could be improved in the future.

Now, regarding the jerks on small radius circles ... my M566 has X1000 Y1000, it slows down quite nicely on sharp corners and infills.It never jolts like it does on the small circles. I have uploaded a video... let me know what you think : [youtu.be]

I guess the issue may be that with a small circle, you get multiple jerks in quick succession. But try reducing the jerk. I use 600 for X and Y. If you are generating your gcode using slic3r, you could also reduce the speed setting for 'small.perimeters'.

Edited 1 time(s). Last edit at 09/23/2016 07:14AM 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].