Updated firmware 0.58d-dc42 and web interface 0.73

Hi Kim,
Are you sure you have the correct setting in config and slic3r. The latest firmware 058e and interface 074 from dc42 is the best yet and resolves a lot of issues that were present in earlier releases.
Are you sure you have not altered something to overcome previous problems?
After all a lot of people are using the latest software.
If you like, post your settings and I'll compare them to mine.

Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Quote
Le-Seaw
okay

and what is P for the heatbed?
3?

so the new must then M305 P? T100000 R1000 B4066 H14 L-11
and the thermistor in hotend is 10 too low.

The P parameter is (like all heater parameters) 0 for the bed and 1 for the first extruder. I'll clarify this in the wiki.

You don't need to specify the T, R and B parameters if you are using the standard values.

---

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

thx
and i use not the standard
i had my own heatbed with kaptonheater and alu/pei bed.

@dc42

I just noticed that the messages "SD Printing" and "Not SD Printing" are only displayed every second when theh "Watch temperature" box is ticked.
Also, when printing from SD, I have no filament size and print duration time, when not printing from SD card I have both.

Hi Sardi, thanks for your feedback.

Quote
Sardi

pronterfacex.jpg

EDIT: Also, when its not printing, instead SD Printing, it goes "Not SD Printing" every second.

1. Looks like Pronterface must be sending the M27 command (which is deprecated according to the firmware source code) at regular intervals, because that is the only command that generates the "SD printing" and "Not SD printing" responses, and the web interface never sends that command (I've checked). But I don't understand why it is only showing it with the new firmware and the web interface connected.

2. You should not be getting network connection error messages every second. What is your networking set-up - is the Duet connected to the PC via cables, wireless, powerline or what? Are you familiar with Wireshark, and if so, can you post a Wireshark capture of the network traffic to the Duet when attempting the initial connection after a reset?

It looks like I need to do some more testing with Pronterface as the main user interface. Most of my testing is done using the web interface. I often connect Pronterface, but usually only to monitor whether the firmware is generating any error messages. I've never seen it repeatedly say "SD card printing" or "Not SD card printing".

---

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
1. Looks like Pronterface must be sending the M27 command (which is deprecated according to the firmware source code) at regular intervals, because that is the only command that generates the "SD printing" and "Not SD printing" responses, and the web interface never sends that command (I've checked). But I don't understand why it is only showing it with the new firmware and the web interface connected.

I tested the connections and software a bit. The msg "SD printing" and "Not printing" are shown every second when the "Watch" box is ticked, but they are not relative to web interface (it is curently closed and I am printing via Pronterface).

However, the msg "Network connection error, code -11, Network ConnectionError: didn't find hs" comes up every second ONLY when the web interface is open (does not need to be active/connected), and the "Watch" box does not need to be ticked.

Also, temperatures wise - when I print from pronterface, the temperatures freeze untill they reach the designated temperature, after that they work normaly. (I can still check the rising of temperature on web interface, no freeze there).

Quote
dc42
2. You should not be getting network connection error messages every second. What is your networking set-up - is the Duet connected to the PC via cables, wireless, powerline or what? Are you familiar with Wireshark, and if so, can you post a Wireshark capture of the network traffic to the Duet when attempting the initial connection after a reset?

My duet is conected directly to my laptop via ethernet cable and usb cable.
Wireshark photo in attachment. First time using it, hope thats what you need

Quote
dc42
It looks like I need to do some more testing with Pronterface as the main user interface. Most of my testing is done using the web interface. I often connect Pronterface, but usually only to monitor whether the firmware is generating any error messages. I've never seen it repeatedly say "SD card printing" or "Not SD card printing".

I also preffer the Web interface, but since the SD upload button got a mind of its own, I decided to use Pronterface for the time beeing.

Edited 2 time(s). Last edit at 05/02/2014 03:31PM by Sardi.

I've released firmware 0.57f. This fixes a problem whereby if a network error occurred during the initial web interface connection when one of the web files was being sent, the file would not be closed, resulting in an open file slot being used up. I've also added the number of free open file slots to the M111 S2 report. It should generally be 10 when the printer is idle and 9 when it is SD printing. It will also be 9 after SD printing has been paused, even if the reset command has been sent, but will go back to 10 when you have successfully printed another file from the SD card. This is a consequence of the strange choice of commands implemented in gcode. Surprisingly, there is no facility in the gcode command set to stop and abandon a print (other than emergency stop), only to pause a print. You can truly abandon a print only by asking to print a another file.

Believe it or not, when commanded to write to an SD card file, there was no checking at all in the firmware whether the command to create the file had succeeded. It would report "Writing to file xxx" regardless. I've fixed that, however additional work is needed before the web interface can abandon writing it the file creation failed.

I've tested printing of short files direct from Pronterface, and I've also tested uploading files to SD card via Pronterface. It all works fine for me. I used the patched version of Pronterface. I haven't tested with the unpatched version, because that never did work very well.

Edited 1 time(s). Last edit at 05/02/2014 03:56PM 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
dmould

Quote
ormerod168
In Pronterface, with any firmware I have used, monitoring of temperatures stops the moment I start a SD print, it doesn't bother me, to monitor anything you have lost control over don't make any sense

And fair enough, If I wanted to change any ingredients (slicing) I should have done so before putting the cake in the oven (send to print)

Erik

I've always found that Pronterface only stops updating temperatures while the Duet is waiting on an M116 command (at the very time you would be interested in seeing the progress!). If "watch" is ticked, then monitoring is resumed after printing resumes (i.e. temperatures attained)

Yes your are correct - I just (Duh!) found out there is life after M116

Quote

.. and you do still have some control - I can set a new temperature for bed or hotend from Pronterface in the normal way at any time during a print, which is handy when you want to experiment with how different temperatures affect the quality on the fly, or change the temperature at specific parts of a print (I find bridges work better at a lower temperature than I usually print at). The web interface does not allow you to change temperatures during a print using the buttons, but you can still change the temperature mid-print by sending the appropriate command in the G code window.

Dave
(#106)

Great! - thank you for clearing that up for me, comes to think of it, I remember reading this and that about changing temperatures on the fly but did not think more about it, I just closed pronterface down after print start as it was my understanding that it had lost all control by then

Will try it thank you, could be very usefull as I often have problems with pointy bits e.g. the x-motor bracket with the extended probe thing, last print was a near meltdown, was able to save it with a breeze of compressor air

Erik

Hello DC/guys.

I originally posted this in the 58a thread by mistake, oops.

This is my first post, so here goes.

Thanks to DC and others for making our Ormerod experience better.

I've had my Ormerod for a couple of months now and it's my first 3D printer. I've done a few mods of my own design, which I need to find time to share.

I've been upgrading my firmware with DC's last 3 revisions and have liked the improvements. I can't use the web interface because I think I have a faulty Ethernet port on my Duet. I'm currently on 58e and seem to be having issues printing curves and circles with Cura output gcode. It's really jerky in X Y, starting and stopping the extruder and leaving big blobs. Slic3r code is better, the X Y motion is smooth but extrusion is still a bit rough.

I've been using Cura for a while now as it gives much cleaner prints in general, not sure if this is anything to do with the firmware, anyone else facing similar issues?

Update

I've just tried to print an old proven file sliced in Cura and this displays the same behavior on smaller circles.

Thanks.

Edited 1 time(s). Last edit at 05/04/2014 11:33AM by Yella3D.

Edit: Got it...

Edited 1 time(s). Last edit at 05/05/2014 11:39AM by djar.

Hi Yell3D,

Are you printing from the SD card, or direct from Pronterface? If you are printing direct from Pronterface, which build of Pronterface are you using? The original precompiled one can't send data to the Duet fast enough, and this causes jerkiness of the sort you report. It shouldn't be any worse with 0.58e than with earlier versions, but let me know if you think it is.

If you are getting the problem when printing form SD card, please can you zip up and post your gcode file, so that I can try to reproduce the problem.

I did a patch to the RRP version of Pronterface, to avoid the jerkiness when printing direct from Pronterface and get much better SD card upload speeds. The patch is described here [forums.reprap.org].

---

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

Hello DC42.

I'm printing from the SD card, So it's not a data transfer issue.

G code supplied. This file was really bad about 50% of the circular portion, all layers. I've just sent the first half of the code.

Thanks in advance for your time on this.

Keep up the good work!

Update

It's funny, when I look in repetier at 2 sliced files, it looks as though Slic3r has more of a polygon for small holes, whereas Cura makes them look round. could this have anything to do with it? see attached screenshot. Slic3r on the left.

Edited 1 time(s). Last edit at 05/04/2014 12:09PM by Yella3D.

I'll try that print. A couple of questions:

1. Do you think the jerky movement is worse with firmware 0.58e than with whatever version you were running before?

2. Do you still have the M111 S1 command in config.g? If so, try removing it.

Jerky printing usually means that gcodes are not being fed to the printer fast enough. The small, well-rounded circles generated by Cura require a lot more gcodes than the polygons that slic3r appears to have generated for your model. So yes, that could explain the difference.

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

Yella3D, I'm printing that part but it's done several layers already without getting to the holes. Can you generate a small example that displays the problem?

EDIT: Don't bother, I've located the problem. It's to do with the change I made to avoid the long wait before you can connect Pronterface when no network cable is connected. Previously, I tested fast printing with the network cable disconnected, but not with the network cable never connected since reset. What I'm finding is that if I boot up with no network cable connected and try to print a lot of small fast movements, the print is jerky. Once I connect a network cable, the print goes smoothly again, and remains smooth even after I disconnect the network cable.

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

Hi I wonder if it hard to change the thermistor type in the firmware I have a new hot end that I would like to use, [files.e3d-online.com]
And it use a different thermistor Semitec 104GT2.
/Joar

It is easy to change the thermistor type in the latest firmware. See the documentation of the M305 command at [reprap.org].

---

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

Yella3D,

Please can you try firmware 0.59beta from [dl.dropboxusercontent.com]. This should fix the problem of jerky printing from SD card when the print contains lots of fast moves and no network cable has been connected since last reset.

Kim, you might want to try this version too. You didn't describe the issues you were having well enough for me to investigate, but I think you may have mentioned mention jerky printing, and perhaps you don't have a network cable connected..

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

Hi dc42.

Thanks again.

I will try the beta version later today and report back

Hi DC42

I have just uploaded your latest firmware (thanks for all your hard work) but when i now try to upload a file to the sd card the printer starts to print the file straight away and the web page shows the file upload progress bar but the rest of the page is greyed out. I have firmware version 058f and web page 0.74. I am running windows 7. The file upload worked fine before this upgrade.

Once again thanks for your work on getting this project so far, i for one would have given up long ago if had not been for the software improvements.

Regards

Jim

Hi 3djim, sorry to hear you are having problems with 058f. I presume you are using the "SD upload drop" button on the "Gcode file" tab of the interface. Please can you do the following test:

1. Close the browser tab.

2. Reset the Duet.

3. Connect Pronterface.

4. Send M111 S0 (in case you still have M111 S1 in config.sys).

5. In the browser, open a tab to the Duet, and press Connect.

6. Check Pronterface for any error messages.

7. Send M111 S2 in Pronterface and see how many free open file entries it reports. It should be 10.

8. Try to upload a small file (e.g. circle.g) via the web interface. Note any messages that Pronterface displays, and whether it tries to print the file.

9. If that worked properly (i.e. it didn't print the file immediately), repeat step 8 with a larger file.

Edited 1 time(s). Last edit at 05/05/2014 04:01AM 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].

Hi DC42

The steps all carried out correctly when uploading a small file. no error messages. When i try to upload the larger file i get error message Gcode buffer overflow

Hope this helps

Hi DC42

I have just tried to print another file from the sd card and get the following message on pronterface - Can't open 0:/gcodes/cup%20axle%20clip%20MK2.g to read from. Error code:4

Although the printer does print the file correctly

Thank, Jim. Did the larger gcode file upload correctly, without printing immediately? The "Gcode buffer overflow" message probably means that there was a very long comment line in the file somewhere - if you are using Cura then I believe it adds such a line on the end. Can you open the file in a text editor and check? The upload mechanism will truncate the line, which is harmless if it is a comment.

The other error message suggests that the firmware is not correctly decoding filenames that contain embedded spaces. When the files that you were only trying to upload started printing immediately, did the filenames contain embedded spaces?

---

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 file open error message was caused by the file info command from the web interface failing. So the file printed, but the object height and total filament info was not available. I've fixed this in 0.59beta2 which is here [dl.dropboxusercontent.com].

I still can't find any way of getting the SD card upload to fail (i.e. printing it instead of uploading it). It sounds like it is failing to create the file you are trying to upload. I can think of a number of possible causes:

* Running out of open file slots. That's why I made the number of open file slots visible in the M111 S2 response. However, in version 0.58f or 0.59beta, I can't find any way of getting the firmware to lose open file slots.

* Corrupt SD card. You can check this by plugging the SD card into a Windows PC and running chkdsk on it.

* SD card not working reliably with the Duet, perhaps because it is too slow

* Some bug I don't know about causing the file system library to fail to create files

So all I can suggest is that you have Pronterface connected before trying to do an SD card upload, and check the number of free open file slots before uploading (should be 10, or 9 if you interrupted the previous SD card print). Then if it starts printing instead of uploading, check Pronterface for error messages.

One day I'll finish adding error recovery so that the web interface can check that the file creation succeeded before sending the data, but I haven't time to do that this week.

Edited 1 time(s). Last edit at 05/05/2014 07:16AM 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].

Hi DC42

Thanks for the replys to my ealier posts. Sorry for not getting back sooner but i am at work so have to fit 3d printing between other jobs. I have updated to 0.59beta and the file upload seams to be going ok. the total height and filament problem has been going on for a few days it did work ok and the estimated times were all working but for some reason they stopped, although the printer still feeds back the machine position info etc. I use Slicer for all my file creation since day 1 and this seams to work well for me so why it shoulld suddenly stop giving the filament info i am not sure. Thanks for all your help.

Regards

Jim

Hi Dc42.

I've just tried the beta firmware, all seems to be good now.

Thanks again.

I will update you if I face any other issues.

Yelle3d, thanks for your feedback.

I've put 0.59beta2 live at [github.com]. Changes since 058f are:

* Fixed problem whereby gcode files printed from SD card that used lots of small fast moves in sequence would print jerkily if a network cable had not been connected since reset.

* Fixed problem whereby object height and filament required were not retrieved from the SD card file to be printed (and hence estimated completion time was not calculated) if the filename contained spaces.

* Added support for deprecated M190 command, because slic3r appears to generate it sometimes.

* Added support for M564 command to allow movement without limits, copied from RepRapPro dev branch.

Edited 1 time(s). Last edit at 05/05/2014 01:57PM 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
Joar107
Hi I wonder if it hard to change the thermistor type in the firmware I have a new hot end that I would like to use, [files.e3d-online.com]
And it use a different thermistor Semitec 104GT2.
/Joar

@dc42

is this the correct line for this thermistor?

M305 P1 T100000 R1000 B4390

Thanks in advance/Joar

That would be correct for the 104GTA-2 thermistor. The B parameter for the 104GT-2 should be 4267.

---

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
That would be correct for the 104GTA-2 thermistor. The B parameter for the 104GT-2 should be 4267.

Thanks, I will correct it and try again:9

/Joar