New firmware 059d-dc42

I've released firmware 059d-dc42 at [github.com]. Changes in this release:

1. Reworked network layer to be more robust (hopefully!) in the presence of network errors. In particular, don't release transmit buffers if they might still be needed to retry sending data because the ACK got lost.

2. Fixed bug whereby the fileinfo command looked for the print height and filament used if the filename extension was .gcode or .gc or .gco but not if it was .g.

3. When the M25 (pause print) command is received, pause the current gcode. This means that if you ask to pause a print while a long-running command such as M116 (wait for temperatures) is executing, the pause now takes effect immediately without waiting for the command to complete. The command will be resumed if you cancel the pause. Note: pausing/resuming/cancelling a print doesn't always work properly if the printer is executing a macro at the time, e.g. a homing command or G32. I will fix this in a future release.

The existing version (0.80) of my variant of Matt's web interface is compatible with this firmware.

---

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,
finally today I disconnected the USB cables and now for upgrade I have to reconnect them.....
all day printing from Firefox.... I can now easily control all the printers....

really nice job!

Thanks
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've just had the web interface hang on me during a file upload after I changed settings in Chrome to enable another user interface language. It seems that this increased the size of the HTTP headers and in one data block this pushed the message length 2 bytes over the TCP MSS, which is causing the web server to return a 500 error response. I'll fix this later today. In the meantime, if anyone else has this problem, a workaround is to reduce the value of maxUploadBuffer near the start of reprap.js from 1500 to 900.

Edited 2 time(s). Last edit at 05/31/2014 05:39AM 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].

yeah, it freezes on uploads a fair bit, not really sure what the cause is though.

i find the good ole off and on again tactic resolves it, it seems that once it has decided no more uploads it will stay like that until its rebooted although it will still actually work for G.codes already on the sd card.

dc42, I've added experimental support for FTP and another TCP port for Telnet to this firmware release. It allows me to browse and download files from the Duet's SD card, but unfortunately upload isn't working well yet (except for small files) because I'm still messing around with LWIP and transactions (see my comment in conn_recv in Network.cpp). Anyway, I'm quite happy I've managed to get everything else working so far.

As always I've uploaded these changes to my GitHub repository and compiled an experimental binary so you can give it a try if you like. IMO, the networking code leaves some room for optimizations (especially with the new protocols being added), but I admit I haven't reviewed your changes for 0.59e yet. If I find any more time next week, I will add these changes to my development branch as well.

Zpl, one of the changes I had to make in 0.59e to get larger upload blocks working was to increase the number of network receive buffers in the Arduino core. It used to have 2kb of buffer space, and I was getting packet loss when the incoming http message exceeded 2k. I increased it to 4k to fix the problem. This could also be why you are having trouble uploading via ftp. I think you need at least as much buffer space as TCP window size. You may also need to increase the amount of pbuf space. Also, make sure that you don't spend too much time in ftp before returning control to reprap:pin so that lwip gets called often enough to process the incoming transactions.

---

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

This firmware is now superseded by version 0.59e-dc42. See [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].

Hi David,
I have loaded firmware 059d and interface 081.

Just to let you know they both seem to be working well. I do like the extra information on the Print Status screen e.g. filament needed and the generated by info.

Earlier I had a print of 2 items on the platter and each were printed individually and the print was completed when the information line said that it was only 26% of the way and had loads of layers left to print. This was not the case as the items were perfect.
This may well be a slic3r problem in not calculating the total filament correctly for multiple items.

The problem then became more critical in that the interface would not respond at all, it just sat there with no response and the heaters going full blast.
I pressed pause and reset came up so I pressed that but no response, the heaters still on because the system thought that the print had not finished and it appeared to be waiting for the next line from the g file

In the end I had to connect to usb and Pronterface to turn off the heaters and move the head. When the temp dropped I then turned the power off.

When I turned the power back on the chrome interface would not start, I just had the opps message.

This is just a heads up, I'll do some investigating tomorrow and see if I can figure out what is wrong with the calculations for multi items print.

Shouldn't the pause and reset override and stop the current print job and put the ormerod in the correct state to do another print?

---

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

Hi Paul,

Yes, pause followed by reset should change the status shown by the web interface from Active to Ready immediately, if you are using the new version. However, there may be a number of gcode moves already queued up, so it may go on printing for a while before it stops and response to gcodes sent by the web interface.

If the web interface doesn't respond after a reset, or in any other situation, you can just close the browser tab and open a new one. Any upload that was in progress will be cancelled cleanly.

btw I presume you are now using firmware 0.59e, not 0.59d as you said in your post.

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

David,
Thank you for the info.

The problem I had was with 059d firmware and 080 web interface. Perhaps I didn't explain it well enough. The web interface just stopped responding because I think it was waiting to carry on with the print job when in fact it had already completed. So the g file would have been at the end and finished but the web interface didn't recognise this and thought it had many layers and filament and time left to complete.

I have this at the end of the g file, could this have caused the no response problem?

M107
M104 S0 ; turn off temperature
G28 X0 ; home X axis
M84 ; disable motors

I still need to understand how the calculations are done for multiple items on the plater because it clearly isn't working right at the moment. However if only one item is on the plater then the time estimate is reasonably accurate, certainly good enough for my needs.

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
appjaws1
I still need to understand how the calculations are done for multiple items on the plater because it clearly isn't working right at the moment. However if only one item is on the plater then the time estimate is reasonably accurate, certainly good enough for my needs.
Paul

If I understand David's code correctly, there are now two ways he estimates time. One is to look at the average time taken to print each layer to date and extrapolate to find the time needed to print the rest of the layers, and the other is to look at the time taken to consume the amount of filament to date and extrapolate to find the time it will take to use the total filament at the same rate.

The first method is unlikely to be accurate if you have several different parts on the build plate, because the parts are likely to be different heights so the time to print each layer will change drastically as each part completes. The second method should however still be reasonably accurate - but that method is only available if the code was able to determine the total filament length, which it gets from a comment field in Slic3r's G code but is unavailable from other slicing application outputs (e.g. Cura). I may be wrong, but I think it also requires that the G code file be uploaded to the SD card via the web interface?

Dave
(#106)

Quote
dmould
If I understand David's code correctly, there are now two ways he estimates time. One is to look at the average time taken to print each layer to date and extrapolate to find the time needed to print the rest of the layers, and the other is to look at the time taken to consume the amount of filament to date and extrapolate to find the time it will take to use the total filament at the same rate.

The first method is unlikely to be accurate if you have several different parts on the build plate, because the parts are likely to be different heights so the time to print each layer will change drastically as each part completes. The second method should however still be reasonably accurate - but that method is only available if the code was able to determine the total filament length, which it gets from a comment field in Slic3r's G code but is unavailable from other slicing application outputs (e.g. Cura). I may be wrong, but I think it also requires that the G code file be uploaded to the SD card via the web interface?

Correct on all counts, except that you don't need to load the file via the web interface for it to read the filament comment at the end of the file - the firmware does that. Cura is in principle capable of generating a filament used comment, but in practice variable substitution doesn't seem to work in the version of Cura I tried a couple of weeks ago.

I propose to amend the end time estimates to provide just two:

1. Estimate based on object height, using average of last 5 layers (or all layers completed so far if <5);

2. Estimate based on remaining filament, and the average rate at which filament was consumed while printing the last 5 layers (or all layers completed if <5).

Edited 2 time(s). Last edit at 06/04/2014 10:05AM 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 must remember to quote first, I have just lost the message.

David,

I was totally wrong in my previous post about the inaccuracy when printing a plater of multiple items. I have done more testing and all seems well and as accurate as we are likely to get it.

Quote
dc42

I propose to amend the end time estimates to provide just two:

1. Estimate based on object height, using average of last 5 layers (or all layers completed so far if <5);

2. Estimate based on remaining filament, and the average rate at which filament was consumed while printing the last 5 layers (or all layers completed if <5).

How would your option 1 cope with multiple height items on the plater when the used has selected to print one object at a time ? I believe at the moment the Object height box displays the height of the last item in the g file.
To be useful the program would need to identify the height of all items and give the total..

The layer information does change when an item on the plater has finished and the next one starts, so maybe the total number of layers and thus the total object height could be worked out for multiple items on a plater when the used has selected to print one object at a time.

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
appjaws1
How would your option 1 cope with multiple height items on the plater when the used has selected to print one object at a time ? I believe at the moment the Object height box displays the height of the last item in the g file.
To be useful the program would need to identify the height of all items and give the total..

The layer information does change when an item on the plater has finished and the next one starts, so maybe the total number of layers and thus the total object height could be worked out for multiple items on a plater when the used has selected to print one object at a time.

Paul

This is new to me! I was completely unaware that there was a selection that allowed you to print one object one at a time - which menu is it in? How do you ensure that the objects are spaced sufficiently far apart that a part of the extruder assembly does not hit a completed part after the nozzle descends to print a succeeding part? What is the advantage of printing objects in such a manner?

Dave
(#106)

Quote
appjaws1
How would your option 1 cope with multiple height items on the plater when the used has selected to print one object at a time ? I believe at the moment the Object height box displays the height of the last item in the g file.
To be useful the program would need to identify the height of all items and give the total.

The layer information does change when an item on the plater has finished and the next one starts, so maybe the total number of layers and thus the total object height could be worked out for multiple items on a plater when the used has selected to print one object at a time.

Option 1 would not work well if the user has selected to print the plater one item at a time, until the last item was being printed. However, I think this is an unusual thing to do, except perhaps for you! Dealing with this properly is not easy because the whole file would have to be scanned for G1 Z commands.

---

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 have been talking about individual parts on a plater all this time, I obviously didn't explain where I was coming from properly.

If I have a number of items to print I always put them on the same plater and print one at a time. This ensures that each object is printed completely and if for some reason the printer malfunctions later in the print at least you would have some of the items printed correctly.

The option is on the Print Settings Tab - Output options.

I have mine ticked for Complete individual parts and for the extruder clearance I am using Radius 40, Height 40 This works for me but I am sure that these measurements could be reduced. I need to do some experimenting.

I think a lot of users use this method, it is one of the advantages of slic3r over other slicers.

Using this option, the filament usage method of working out the time works well, do we really need another method?

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