New firmware 0.96a and web interface 1.05

I'm very pleased to release version 0.96a of my firmware fork as it brings some new cool features to our Ormerods. The following things have changed since version 0.89m:

Quote

Merged in most of RRP's new firmware features from 0.90-0.96 (thanks Adrian/RRP):
- G32 runs /sys/bed.g if it exists (file doesn't need be present with my fork though, if it isn't, the firmware will use the points specified by M557 just as older firmwares did)
- Ormerod 2 compatibility and different SD card images
- File progress during prints reported to web interface
- Duet v0.7 support (experimental)
- Network can be disabled (M552 S0)
Bug fix: Actual extruder positions are reported instead of internal ones used by the GCodes class
Improved code queuing and added more safety precautions
Updated README file to incorporate Network class and to mention my changes
Other minor changes

Note: If you use dc42's ultrasonic Z-probe, you will have to adjust your probe type from 3 to 4. This change was necessary to stay compatible with RRP's official firmware, which introduced probe type 3 for a modulated IR probe for the Duet v0.7.

Unfortunately RRP decided to invert the X-axis direction once more, but my fork does not adopt these changes. This means if you're already using dc42's 0.78 or my 0.89 fork, you won't have to touch your wiring again. However, if you're upgrading from the official RRP firmware (only Ormerod 1), you will have to either turn around your X-axis connector or put "M569 P0 S1" into your config.g file. My Ormerod 1 SD image has already been updated to deal with this and to stay compatible to RRP's instructions. Also, the "config.g" file in the SD-image/sys directory is no longer present. If you're setting up a formatted SD card, please copy "default.g" to "config.g" and then make your changes to that file.

Apart from this firmware release, I've improved the web interface quite a bit. The changes for version 1.05 include:

Quote

Vastly improved print progress:
- Made layer detection more rigid
- First layer height is automatically calculated
- Layer and filament estimation data is filled with averaged values on reconnect
- Implemented new estimation method based on fraction_printed property (if available)
- Progress bar reads fraction_read to indicate progress (if available)
- Removed redundant filament estimation variables
- Improved Print Status appearance in the JS code
- Layer chart shows actual layer number on the X axis after the first 100 layers
Reconnects are now completely implemented
Head control buttons (except for heat) are disabled whenever a print is in progress
Some controls on the Control tab are now centered

A screenshot of my latest web interface fork is attached. You may use it with either dc42's or my fork, it should work well with both of them.

Feedback is appreciated!

Edited 1 time(s). Last edit at 10/16/2014 03:57PM by zombiepantslol.

Hi zpl, good to see you are still working on this. You asked for feedback, so here is some!

Quote
zombiepantslol
Merged in most of RRP's new firmware features from 0.90-0.96 (thanks Adrian/RRP):
...
- Network can be disabled (M552 S0)

That seems an odd feature to include. If you don't want the network, don't connect it! I guess you could use it to disconnect the network during a print, but I can't see why you would want to.

Quote
zombiepantslol
Bug fix: Actual extruder positions are reported instead of internal ones used by the GCodes class

You may consider it a bug fix, but I don't. Soon after I introduced support for the M221 extrusion factor command, I deliberately had the web interface return the extrusion amounts before they were adjusted by the M221 percentage. That was so that the print progress based on filament usage calculations would not be affected by adjustment using M221. I don't have any other use for the reported extruder positions. So I don't think a returning the adjusted extrusion amounts is necessarily a good idea.

Quote
zombiepantslol
- Implemented new estimation method based on fraction_printed property (if available)
- Progress bar reads fraction_read to indicate progress (if available)

How does the accuracy of the estimated end time based on fraction read compare with the estimate based on filament extruded? Some gcode commands are for long straight lines that take some time to be executed. Others are for small arcs of circles and execute very quickly. And of course some don't involve extrusion at all. I can think of some shapes for which the %complete based on the amount of the file read could be very misleading, e.g. a solid cuboid base with a cylindrical pillar on top. So in my fork, I think I'll stick to basing the %complete on filament used (except where the filament needed cannot be determined), until I have evidence to the contrary.

I'll take a look at your other changes when I get time. I've been meaning to do something about first layer height for a while, but you have beaten me to it.

---

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 your feedback!

Quote
dc42

Quote
zombiepantslol
- Network can be disabled (M552 S0)

That seems an odd feature to include. If you don't want the network, don't connect it! I guess you could use it to disconnect the network during a print, but I can't see why you would want to.

Well yes, I partially agree. RRP implemented that one to speed up their firmware starts in case no ethernet cable is connected, but IIRC our forks aren't affected by this circumstance anyway. However, if anyone wants to disable networking with a LAN cable connected, e.g. because that printer is on a public network and someone tries to abuse it, this can be done with my fork and RRP's (experimental) firmware. It clearly isn't a must-have feature, but then I thought it would be good to stay in line with RRP's supported G-Codes.

Quote
dc42

Quote
zombiepantslol
Bug fix: Actual extruder positions are reported instead of internal ones used by the GCodes class

You may consider it a bug fix, but I don't. Soon after I introduced support for the M221 extrusion factor command, I deliberately had the web interface return the extrusion amounts before they were adjusted by the M221 percentage. That was so that the print progress based on filament usage calculations would not be affected by adjustment using M221. I don't have any other use for the reported extruder positions. So I don't think a returning the adjusted extrusion amounts is necessarily a good idea.

Good point, I honestly didn't think of that TBH, probably because I barely touch the extrusion sliders on the Print Status tab. On the other hand now that my web interface fork uses the fraction_read property to determine the print progress, the filament-based estimation has become secondary for my firmware fork. I still do consider this change as a bug fix, but you're right, this fix introduces another (potential) bug. Making the firmware report both the actual and theoretical extruder positions, ie. with and without the extrusion factor applied, might be a better approach to address this problem. This way it should be possible to get the filament estimation working at all times and yet report correct extruder positions to the web interface. I'll have a look at this when I start working on my next firmware release. And thanks for telling me, I wasn't aware of this.

Quote
dc42

Quote
zombiepantslol
- Implemented new estimation method based on fraction_printed property (if available)
- Progress bar reads fraction_read to indicate progress (if available)

How does the accuracy of the estimated end time based on fraction read compare with the estimate based on filament extruded? Some gcode commands are for long straight lines that take some time to be executed. Others are for small arcs of circles and execute very quickly. And of course some don't involve extrusion at all. I can think of some shapes for which the %complete based on the amount of the file read could be very misleading, e.g. a solid cuboid base with a cylindrical pillar on top.

In the middle of a simple, box-shaped print it's a bit off, but not much - maybe by two minutes or so. I guess this is caused by the delay the nozzle heater needs to reach its temperature as you already assumed, but it could be worse. I haven't checked how accurate this estimation is for a print started with a cold bed, but I figure this would affect this estimation quite a bit, at least if the file is very small. Yet I think the fraction_read value is a great indicator for the actual print progress, because it gives you an exact idea of the current file position and because it can be universally utilised. As for most parts I've printed with the new web interface so far (with plenty of small arcs) I found the file estimation to be quite accurate, although the filament estimation seems to work a bit better. I've attached another screenshot of the web interface while printing a more complex part (scaled down by 50%) and from what I can tell, all the estimated times look quite good. The file progress estimation is still within reasonable ranges, too.

Quote
dc42
I'll take a look at your other changes when I get time. I've been meaning to do something about first layer height for a while, but you have beaten me to it.

Heh, I hope you do! There are a couple improvements in my firmware fork which I don't want to miss again, for example being able to pause prints almost instantly and resetting failed prints without the need of having to home all axes again. I hope someday these changes will make it into your fork, too

Edited 1 time(s). Last edit at 10/17/2014 02:24PM by zombiepantslol.

I have loaded your firmware to test and so far all seems well.
The estimated print times for filament usage and File progress seem to be quite accurate

at print duration 20 mins
Layer time Filament File
4:10:12 28:04 43:11

at print time 32m
1:36:37 27:2 16:29

at print time 40m
36:50 16:57 10:22s

at print time 45
30:48 11:38 6:26

at print time 50m
23:33 4:31 3:05

at print time 54:07
3:25 2:26 1:21

at print end time 57:27

So it appears that the winner is File progress followed by Filament progress

Perhaps we should get rid of the Layer time estimate which is so in-accurate as to be of no use.

The filament progress seemed to be jumping at various times as if major recalculations were being performed. I don't remember this happening before this firmware update.

I really like being able to pause prints almost instantly and resetting failed prints without the need of having to home all axes again -- A great improvement.

Keep up the good work

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

Hi Paul, thanks for your positive feedback Interesting to see some statistics, but note the filament usage usually stabilises after the first 3% of filament have been printed. Then it will use per-layer data to estimate the remaining time - maybe I should implement something similar for the file progress estimation in my next web interface release.

Quote
zombiepantslol
Hi Paul, thanks for your positive feedback Interesting to see some statistics, but note the filament usage usually stabilises after the first 3% of filament have been printed. Then it will use per-layer data to estimate the remaining time - maybe I should implement something similar for the file progress estimation in my next web interface release.

I didn't explain very well. What was happening was that throughout the print the filament "estimated time remaining" was jumping by a few mins, previously I had not seen this. Previously I am sure that the readings were only adjusted by small amounts so you didn't really notice them during the time as it was counting down. The File progress didn't jump by such large amounts, in fact I didn't really see any adjustments to the time remaining.

---

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 really like being able to pause prints almost instantly and resetting failed prints without the need of having to home all axes again -- A great improvement.

The original version of Matt's firmware sends an M1 command when you reset a failed print, and I haven't changed that. Not only does this turn the motors off, it turns the heaters off too. I find both of these annoying, so I'm going to remove the M1 command in my next release.

I'm busy with other work right now, but when I get back to Ormerod firmware, my focus will be on modifying the Move code to pre-compensate for Bowden extruder elasticity. The changes will also pave the way for supporting Delta printers in the firmware, which users on other forums have been asking for.

---

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 don't know if this has to do with your firmware, but I changed from dc42 to your for testing purposes. Now it seams that the extruder does significantly put out less filament than before.

EDIT: I found the problem. Slic3r was configured with 3mm PLA instead of 1.75mm. Your firmware works a treat! Thank you very much

Edited 1 time(s). Last edit at 10/18/2014 07:11AM by DasBasti.

I've noticed that after running my setman.g file, whereby all axis are zeroed and the machine brought up to temperature, the Upload & Print is not working.
The web interface shows the temps as set in config file, the active head and bed temperatures are as set but the machine just sits there waiting.
If I pause and reset and then load the g file again, the correct temperatures are set for the bed and hot end, the head moves to the wait position and as soon as the temperatures reach the newly set figures the print starts.

With previous versions of the firmware, the machine has responded correctly after the setman.g has completed and as soon as the file Upload has completed, the printer starts.

Oh hang on!!! I've reverted to 1 nozzle at the moment but haven't changed the config.g file, so I guess the machine is waiting for nozzle 2 to reach temp, it is reading -273.1. but that can't be right, why would it perform correctly after a reset and the second load of the file?

A mystery
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

Hmm, that sounds odd. Can you please post the output of M122 at the time your print stalls and also the content of your setman.g file? I'll try to reproduce this issue later and fix it if I find out what's going on.

Quote
zombiepantslol
Hmm, that sounds odd. Can you please post the output of M122 at the time your print stalls and also the content of your setman.g file? I'll try to reproduce this issue later and fix it if I find out what's going on.

Thanks for the reply,

It was as I thought, I had set temperatures for the second nozzle in the setman.g file. So it is now resolved.
Thanks
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

Hi everybody,

with this firmware, my extruder is not moving anymore. Not forwards or backwards, not manually or when printing with gcode
Am I the only one with this? My Ormerod is not modified in any way and has only one extruder.

Hi Pyromaniac, which firmware version were you using before you upgraded to my fork? Do you run "T1" in your start G-code and/or config.g file? Also, at what temperature are you trying to extrude filament?

Hi zombiepantslol,

I've used 0.78c before. I didn't used the "T1" command anywhere. Maybe I know where the problem is: At the moment, I am waiting for spare parts and the extruder/hot-end can't heat up. The extruder is running empty without filament, but he DID this with the old firmware, and for testing purposes I've tried your firmware without the ability to heat up the nozzle. Is your firmware monitoring the extruder temperature and prevents it from extrusion when the temperature is out of range?

Yep, that is indeed correct. With my firmware fork, you need at least 90°C to retract and 160°C to extrude, but you can override this saftey protection by running "M302 P1".

Alright, it works, thanks! I was afraid that I've damaged something

Interesting work on the print time estimation. There are a number of strategies for getting really accurate times, but most need a script run on the gcode. This then needs to know in advance the actual machine settings (speeds, accelerations etc), so it can process the whole gcode, and either accurately predict how long the whole print will take, and append this to the gcode file so the firmware can pick it up, and/or append special gcodes in the file, which output the percentage done (this is what Makerbots do, I believe).

Marlin (the reprap firmware that runs on the Arduino Mega chips like Melzi and RAMPS) has always just reported the percentage of the file that has been read, and has always been roughly accurate. The only bit that tends to trip this up is the first layer, as it's printed slow; perhaps the best hands-off (ie not a script you run on the gcode) way of estimating would perhaps be to identify the first layer; compensate the estimation (ie assume it's running at half speed) up to the first layer change. It's interesting to see that other estimations are less accurate!

I have kept asking Adrian to put Marlin-style estimation in the firmware, which apparently he has on the 'dev' branch now (in the web interface only; he's working on adding it to USB too, which reports 0% done all the time) - assuming this would be relatively trivial to do and inaccurate, but at least it would be something; now it turns out it's the most accurate! Thanks for testing!

Ian
RepRapPro tech support

I usually run my first layer at half speed, but also double height, so they cancel out and the estimate remains accurate!

Dave

None of the estimated time are correct until the very end of the print.
What we need is an accurate estimate at the start of the print, yesterday I printed a print that took over 5 hours.
The estimated end times are as follows:-
At 1:01:00 into the print: Layer Time = 17:12 Filament = 16:29 File = 19:36
At 2:26:00 into the print: Layer Time = 18:06 Filament = 17:14 File = 18:32
At 3:10:00 into the print: Layer Time = 16:45 Filament = 16:41 File = 17:59
At 5:12:00 into the print: Layer Time = 16:46 Filament = 16:35 File = 16:48

As you can see the filament is the most accurate at the start of the print and remains quite close to the final finish time but the File estimate is way off for the first 4 hours or so.
So much depends on the shape of the printed item that it is hard to know how to improve the estimates without major processing of the gcode file.
I wonder how difficult it would be to take the speed of the extruder into account, throughout the file. I think this is all that would be needed to provide a really accurate estimate.

Any thoughts?
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

Paul - did you miss the hours off the print times? And was it a 2 colour print (ie, lots of heating up and cooling down time)?

Ian
RepRapPro tech support

Quote
appjaws1
As you can see the filament is the most accurate at the start of the print and remains quite close to the final finish time but the File estimate is way off for the first 4 hours or so.
So much depends on the shape of the printed item that it is hard to know how to improve the estimates without major processing of the gcode file.
I wonder how difficult it would be to take the speed of the extruder into account, throughout the file. I think this is all that would be needed to provide a really accurate estimate.

Any thoughts?

May I ask what your finished object looks like? Ian has mentioned some good points, do any of them apply to your print? I understand the file-based estimation can be a bit off, because it's only a rough estimation based on the file progress and the print time. Yet I'm surprised the filament-based estimation didn't work for you, because that one usually takes layer times and filament consumption per layer into account. Can you open up a second tab/window next time you print something similar as soon as the first few layers are done? This may improve your estimations a bit...

Quote
droftarts
Paul - did you miss the hours off the print times? And was it a 2 colour print (ie, lots of heating up and cooling down time)?

Ian
RepRapPro tech support

No the hours are as shown but I didn't include the seconds for the estimated times. and the print was single colour

Quote
zombiepantslol
May I ask what your finished object looks like? Ian has mentioned some good points, do any of them apply to your print? I understand the file-based estimation can be a bit off, because it's only a rough estimation based on the file progress and the print time. Yet I'm surprised the filament-based estimation didn't work for you, because that one usually takes layer times and filament consumption per layer into account. Can you open up a second tab/window next time you print something similar as soon as the first few layers are done? This may improve your estimations a bit...

The print consisted of 5, tall separate items on the plate so there would have been a fair bit of travelling between the items which is why the filament based estimate would be so wrong at various times throughout the print but having said that the filament estimation was still the most accurate.
I suppose we need to be able to calculate the non-print time and add that to the filament estimate.
I wonder if a script could be run to do all of the calculations and then report the correct finish time to the web interface and then, the web interface could show the percentage completed, as a check on progress.

another print today produced the following:
At 00:09:00 into the print: Layer Time = 15:10:00 Filament = 14:40:00 File = 15:02:00
At 00:34:00 into the print: Layer Time = 15:02:00 Filament = 14:50:00 File = 14:46:00

again the Filament estimate was the most accurate.

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

I think you are giving the estimated finish time of day rather than the HMS to go. Which doesn't help us because you don't give the time of day that it actually finished!

Dave

Quote
dmould
I think you are giving the estimated finish time of day rather than the HMS to go. Which doesn't help us because you don't give the time of day that it actually finished!

Dave

Yes you are right. I should have given the actual end time. It invariably ends somewhere between the Filament and the File time near the end of the print.
My main objective was to illustrate the errors at the beginning and show how each estimate was amended over time. If we can resolve the errors at the start of the print then the end time could be relied on, At the moment the File estimate could be over an hour out (depending on the print) so I tend to take the filament estimate as the most accurate.

I don't see why we have 3 methods of calculating the estimated end time, it just confuses the issue. We should pick the most accurate one and try and improve the calculation so that it can be relied on regardless of size or complexity of print.

Thanks for your interest
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
We should pick the most accurate one and try and improve the calculation so that it can be relied on regardless of size or complexity of print.

The thing is, there are situations where each method will be "the worst", so just saying one in particular the most accurate one is far from straightforward. Best option to give a single value would probably be a weighted average (where the weights can be changed by the operator).

Quote
appjaws1
I don't see why we have 3 methods of calculating the estimated end time, it just confuses the issue.
Paul

I agree. I reduced the number of estimates of end time from 4 to 2 in my fork of the web interface a few versions ago. I also changed the progress bar to be based on filament consumption (when filament required is available) because it was the most accurate. Just because the RRP dev version is using file progress to measure percent complete doesn't mean we should copy that, if filament consumption is generally more accurate.

---

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
jstck

The thing is, there are situations where each method will be "the worst", so just saying one in particular the most accurate one is far from straightforward. Best option to give a single value would probably be a weighted average (where the weights can be changed by the operator).

I agree, the issue is far from straightforward, that is why I suggested that perhaps we need to process the whole gcode file taking into consideration filament speed and time of non printing movements. To use a weighted average as a single value would produce more inaccuracy in the filament estimate, not improve it.

Quote
dc42
I agree. I reduced the number of estimates of end time from 4 to 2 in my fork of the web interface a few versions ago. I also changed the progress bar to be based on filament consumption (when filament required is available) because it was the most accurate. Just because the RRP dev version is using file progress to measure percent complete doesn't mean we should copy that, if filament consumption is generally more accurate.

You made great improvements to this problem in your fork, the filament consumption works really well, although at the end of a print I always have some filament usage left to be used. I agree that the filament estimate is the most accurate but I feel that it should be more accurate at the beginning of the print to be more useful.

What would be involved to achieve a more accurate estimate?

This is in no way a criticism of your and zombiepantslol's firmware, we are very grateful for both of your efforts to improve the Ormerod.

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
jstck
The thing is, there are situations where each method will be "the worst", so just saying one in particular the most accurate one is far from straightforward. Best option to give a single value would probably be a weighted average (where the weights can be changed by the operator).

I agree. My idea is that all the print estimation times are only approximate values, thus I want to have three estimations based on different factors. I cannot say I was unsatisfied with the filament progress being calculated on the filament used, so I may actually revert to that one and use file progress only as a fallback solution. There are so many different objects we can print, but for some shapes layer-based estimation works great, while for other ones filament-based and/or file-based estimations work better.

Quote
dc42
Just because the RRP dev version is using file progress to measure percent complete doesn't mean we should copy that, if filament consumption is generally more accurate

Not necessarily, yes. But at least with my firmware fork the web interface can utilise this factor quite well, because it will report 99.99% if the file has been completely read, but if there are any pending codes left in the code queue, too. But both v1.05 and v1.06, which I'm about to release, will be compatible to your fork. However v1.06 of my web interface fork will also use the raw (unmodified) extruder positions (if available) to improve filament-based estimation. so extrusion factors won't affect it any more and both the theoretical (unchanged) and actual extruder positions can be viewed on the web interface.

Quote
appjaws
What would be involved to achieve a more accurate estimate?

I've got two ideas to get an ideal estimation working, but I'm not sure whether I will implement these yet:

1) Some slicers like Cura (although this feature is still broken in the latest release) generate an approximate print duration in the G-Code file. The firmware could parse and report this value to the web interface, and the web interface would only require a simple count-down to be implemented.
2) Set the print start time as soon as the extruder position becomes greater than zero and not when a file is queued to be printed. This would require a few changes in the web interface and in the firmware, but I think that should be doable.

Well, these may be some good features for 0.96c and v1.07, but I haven't checked yet if Slic3r and S3D generate an estimated print duration.

Edited 1 time(s). Last edit at 10/22/2014 05:23AM by zombiepantslol.

Quote
zombiepantslol

I've got two ideas to get an ideal estimation working, but I'm not sure whether I will implement these yet:

1) Some slicers like Cura (although this feature is still broken in the latest release) generate an approximate print duration in the G-Code file. The firmware could parse and report this value to the web interface, and the web interface would only require a simple count-down to be implemented.
2) Set the print start time as soon as the extruder position becomes greater than zero and not when a file is queued to be printed. This would require a few changes in the web interface and in the firmware, but I think that should be doable.

Well, these may be some good features for 0.96c and v1.07, but I haven't checked yet if Slic3r and S3D generate an estimated print duration.

Simplyfy3d does report an estimate of build time 4 lines from the end of the gcode file "; Build time: 90.99 min (1.52 hr)"
I hope to report the accuracy of this later today

I can't see any reference in slic3r to build, finish or completed time.

Setting the start time as soon as the extruder position becomes greater than zero is a good idea but it will only correct for the small amount of waiting time between issuing the start print and the actual start. I think the bigger issue is the non printing time during the print. My print the other day involved a lot of movement which I am sure was the major factor in the estimate in-accuracy. My current print is only 1 object so non printing moves are at a minimum, I'll keep an eye on the estimate progress

Is there any way to calculate non printing 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

In theory it should be possible to give a very accurate estimate of the print time, if you have the gcode, any in-printer settings (such as firmware limits on speed and acceleration), and estimates of any "wait for warm-up" commands (which generally only happen once at the very start). If you go through each move and calculate how long it will take and sum that up, how far does that really differ from actual print time, and if it does, what is causing it? Such a calculation might be possible to churn through in printer firmware, but I'm not sure how useful that possible extra precision is really worth to me. In all honesty, not very. The current estimates (with their flaws) have always been sufficient for my needs at least.

Edited 1 time(s). Last edit at 10/22/2014 08:11AM by jstck.