Running a simulation to calculate printing time

I've been experimenting with a simulation mode in my firmware fork. The idea is to have the printer calculate all the moves as if it were printing, but at the last minute instead of actually doing the move it just adds the time the move will take to an accumulator. The aim is to get an accurate estimate of the time taken to print a gcode file, before printing starts.

In my tests, simulating a print of a PanelDue enclosure takes 1 minute 34 seconds. The actual print takes 2 hours 57 minutes according to the simulation.

Do Ormerod users consider the time taken to run the simulation acceptable? I doubt whether I will be able to speed it up much, if at all.

If yes, what should be the interface:

(a) by default, always run a simulation before printing. Ideally this would be while the bed is heating up, but that may be hard to achieve if the bed temperature command is part of the file being printed.

(b) run a simulation on demand

(c) both of the above

(d) something else entirely?

The simulation time doesn't take account of tool and bed heating times, or tool change times for multi-nozzle printers.

---

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

Its a good idea. I think on demand would be best.

Quote
dc42
I
(b) run a simulation on demand

on demand ...I think it's the best.

---

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]

Hi David

I think that it would be better if the slicer would calculate this information as the cpu running this is much beefier than the poor cortex-m.

I have taken a short look (haven't had to much time by now for that) at the firmware and i must say that the eventloop based approach does
not fit to well to the relative beefiness of the cortex. My idea would be to migrate to an scheduler (like freeRtos, mbed, ChibiOs) and let the
estimation run in a low priority task.

This would also enable even faster network interaction even when the device is printing and other goodness.

I would join this effort but first i would try to use QtCreator as IDE as i am always overwhelmed by the eclipse contex menu's.

Tim

Hi Tim,

The issue is that the slicer doesn't know enough about the machine (e.g. accelerations, maximum speeds, maximum instantaneous speed changes, and how the lookahead works) to calculate an accurate print time. Doing it in the web interface in Javascript is another possibility. Javascript can be quite fast now that browsers have built-in JIT compilers for Javascript.

Doing the simulation as a background task is a nice idea, however that would mean duplicating the Move class and the DDA ring. Unfortunately, there is very little free RAM now, so we would need to make some substantial RAM savings before that becomes practical. It would be possible to run the simulation using different code that doesn't need the DDA ring, but then there would be the problem of keeping the simulation code in step with the printing code.

If I were writing this firmware from scratch, then I would probably elect to use an RTOS. However, the current event loop works well enough at present, and I would prefer to keep the architecture in line with the official RRP firmware, to make merging changes from one fork to another easier.

Edited 1 time(s). Last edit at 01/29/2015 07:07AM 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 don't think it is a good idea to extend the overall process time to have a better estimate when it ends.....
I was also thinking that an slicr integration (put as an comment in the gcode to be displayed in the webinterface) of a gcode simulation would be better.
But that said - I really never cared about a better estimate of the end time.
So an option would be ok.

Hi Dave

Quote
dc42
The issue is that the slicer doesn't know enough about the machine (e.g. accelerations, maximum speeds, maximum instantaneous speed changes, and how the lookahead works) to calculate an accurate print time. Doing it in the web interface in Javascript is another possibility. Javascript can be quite fast now that browsers have built-in JIT compilers for Javascript.

Well, the whole 3d printing stuff is new to me, but i know embedded... Wouldn't it be possible to have printer profiles which allow the slicer to write down the estimations into the gcode file?

Quote
dc42
Doing the simulation as a background task is a nice idea, however that would mean duplicating the Move class and the DDA ring. Unfortunately, there is very little free RAM now, so we would need to make some substantial RAM savings before that becomes practical. It would be possible to run the simulation using different code that doesn't need the DDA ring, but then there would be the problem of keeping the simulation code in step with the printing code.

If i am right thats 96k of RAM which leaves not to much space for duplication. So i really would prefer to keep the printer as dumb as possible and use a host based solution.

Quote
dc42
If I were writing this firmware from scratch, then I would probably elect to use an RTOS. However, the current event loop works well enough at present, and I would prefer to keep the architecture in line with the official RRP firmware, to make merging changes from one fork to another easier.

Thats an good argument. But then after moving to QtCreator, i would try to tackle servo control first. That would be much less intrusive. Are there any PWM channels free to use on the duet?

All these puny resources makes me think that building up a linux based solution might be the more future proof solution anyway...
But the only solution i know if is beaglebone. And the Sitara has unfortunatly no FIQ support which would be really good for hard realtime motor control. The PRU's are nice but to tightly coupled with the platform for my liking.

Tim

My suggestion is the following:
Have the simulation run on demand on any file with an option on the "files" screen, and also have a checkbox to run a simulation automatically after a new file upload. The simulation result should then be stored as an added comment line in the file. This comment line can be looked for when displaying file information and by the progress screen when the file is printing. As an even better addition, have the simulation store the accumulated time at intervals in comment lines throughout the file (maybe every 5 minutes of printing time). The progress screen can then provide an accurate "time remaining" at all stages of a print by simply interpolating between the time markers in the file. (Modifying a file may need to be done by copying the old file & additions to a new file, then deleting the original file and renaming the new file).

The modified files can of course be copied from SD card to a PC for archiving so uploading a file to reprint will not require re-simulating unless the acceleration setting has been changed. (For that reason the acceleration setting used for simulation should also be stored in the file so that the simulation result is not used if the current setting is different).

Pantau - the overall process time will not usually be affected because the simulation would typically be run before the print is started while waiting for the bed to heat, and if my suggestion of storing the result in the file is followed it would in any case only need to be done once no matter how many times you intend to print the part.

As an aside, while I find the "last layer time" readout useful, the print time estimate based on layer time is so inaccurate that I take no notice of it, and IMO it could be removed from the web interface. The layer time graph is also of minimal interest to me and could be removed, but other people may find it useful.

Dave

Quote
tstone
Wouldn't it be possible to have printer profiles which allow the slicer to write down the estimations into the gcode file?

Yes, but the profile would get quite complicated, depending on how accurate you want the estimate to be. I think some slicers already put an estimated printing time into the gcode file.

Quote
tstone
If i am right thats 96k of RAM which leaves not to much space for duplication. So i really would prefer to keep the printer as dumb as possible and use a host based solution.

I expect there are savings to be made. Dumping the Arduino Due core ad writing direct to the underlying ARM libraries would save some RAM. I'd like to dump the Arduino core anyway, it's more of a hindrance than a help and it makes setting up the build environment much harder.

Quote
tstone
Are there any PWM channels free to use on the duet?

There are lots of spare expansion pins, and I expect some of them are PWM capable.

Quote
tstone
All these puny resources makes me think that building up a linux based solution might be the more future proof solution anyway...
But the only solution i know if is beaglebone. And the Sitara has unfortunatly no FIQ support which would be really good for hard realtime motor control. The PRU's are nice but to tightly coupled with the platform for my liking.

There is software to drive a 3D printer from a Rasperry Pi. But IMO using a dedicated embedded processor is the right solution anyway. It's easier to control the interrupt latency if you are using no operating system or a small RTOS than it is if you use a general purpose OS such as Linux. Also I like the fact that my printer is ready to use the moment I turn it on - no waiting for an OS to boot up.

---

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'd vote for on demand as 1m 30s could be irritating if enforced.

I wonder how much accuracy one would lose by going to a sampling strategy. E.g. 1 layer in 5 (or parameterised). The thinking being that most layers are like the one below.

How abouy doing the calculation locally in the webpage. Query the firmware for the needed variables first. Then the calculation can begin when starting the print and when calculation done the end time can be calculated by subtracting the already consumed print time.

Quote
fotomas
How abouy doing the calculation locally in the webpage. Query the firmware for the needed variables first. Then the calculation can begin when starting the print and when calculation done the end time can be calculated by subtracting the already consumed print time.

The calculations are extremely complex, and also need to be fed with & process every line of the G-code. Not really feasible to do in web-based javascript.

Dave

Quote
dmould
The calculations are extremely complex, and also need to be fed with & process every line of the G-code. Not really feasible to do in web-based javascript.

The complexity would mostly be in duplication of code, as all the code used by the firmware when printing would need to essentially be ported to Javascript and updated whenever the firmware changes (since the actual print time is dependent on just how the firmware acts on the gcode + printer parameters). However, it is entirely feasible to do in Javascript in a browser, and any modern desktop/laptop (that you would consider running a modern browser on) would probably be able to do in a few seconds what the duet can do in a minute and a half.

Quote
jstck

Quote
dmould
The calculations are extremely complex, and also need to be fed with & process every line of the G-code. Not really feasible to do in web-based javascript.

The complexity would mostly be in duplication of code, as all the code used by the firmware when printing would need to essentially be ported to Javascript and updated whenever the firmware changes (since the actual print time is dependent on just how the firmware acts on the gcode + printer parameters). However, it is entirely feasible to do in Javascript in a browser, and any modern desktop/laptop (that you would consider running a modern browser on) would probably be able to do in a few seconds what the duet can do in a minute and a half.

I was thinking mainly of the code translation complexity. I would also not want to rely on everyone having a version of Java on their PC that remains compatible with the translated code. You would have to feed both the Java code and the G-code from the Duet's web and G-code files back to the browser for processing, and given the present data transfer speed that could easily take longer to send than firmware processing - people would surely be aborting because the web page would take so long to load up all that Java code!

I'm also not so sure about the processing speed - my experience of complex applications written in Java is that they are extremely slow. A 3GHz CPU will process at the same speed as a 300MHz CPU if each line of code takes 10 times as many cycles to process.

If anyone were to go to all the trouble of translating (and maintaining) the firmware move code, I would suggest making a separate application that works on the G-code file on the PC, and have the results stored back in the G-code file before uploading to the printer (the application could be written in C or C++ which would make code translation easier, though of course not so portable).

Added to which web processing would not be of any use to David's LCD panel display, which I think will become a popular way of printing (I'm considering it myself).

Dave

For one thing, Java has almost nothing to do with JavaScript, except some common root in basic syntax, and the misleading naming similarities. Even so, in a modern environment, neither is anywhere near as slow as 1/10th "native speed" (comparing to compiled C/C++ code), on tasks mainly relying on "raw numbercrunching" you would probably get somewhere around 50-95% the performance (and based on my experience, closer to the upper end of that band). Downloading the .js code from the Duet would probably not be a big deal (even if it might be lots of code, it would still be on the order of tens of kilobytes), but downloading the .gcode file might take a fair bit of time. Still, it would be faster than the processing on the Duet (assuming download speeds are comparable to upload).

I've just released version 1.00c of my firmware fork. As well as correcting a few minor issues (mostly concerned with delta printers), this includes experimental simulation code. I have a temporary interface using M37 to control the simulation:

* M37 S1 zeros the simulation time and starts simulation
* M37 S0 ends simulation
* M37 by itself reports the simulation on/off state and the number of seconds since the simulation time was zeroed.

So to run a simulation on a file, send M37 S1, then print the file. When it had finished, send M37 S0, and finally M37 to read the simulated print time.

---

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
For one thing, Java has almost nothing to do with JavaScript, except some common root in basic syntax, and the misleading naming similarities. Even so, in a modern environment, neither is anywhere near as slow as 1/10th "native speed" (comparing to compiled C/C++ code), on tasks mainly relying on "raw numbercrunching" you would probably get somewhere around 50-95% the performance (and based on my experience, closer to the upper end of that band). Downloading the .js code from the Duet would probably not be a big deal (even if it might be lots of code, it would still be on the order of tens of kilobytes), but downloading the .gcode file might take a fair bit of time. Still, it would be faster than the processing on the Duet (assuming download speeds are comparable to upload).

Yes, you may be correct. Maybe you could give it a go and see how it works, there are certainly lots of ways to skin a cat.

Dave

I find that I do not care too much about print time estimates. Once a print is underway I just leave the (cold) cellar. Once I get to the pint where I do no longer be present next to the printer to actually start a print I could imagine that having the possibility to run an estimate on demand may come in handy.

Quote
auser
I find that I do not care too much about print time estimates. Once a print is underway I just leave the (cold) cellar. Once I get to the pint where I do no longer be present next to the printer to actually start a print I could imagine that having the possibility to run an estimate on demand may come in handy.

I find it is often quite handy to know what time a print will finish so I know whether I have enough time to start the print and have it finish before I go out or go to bed. If I were more confident about leaving the printer on for long periods unattended it would be less important.

Dave

This is a great improvement, knowing how long the print will actually take will be very beneficial so that the day's tasks can be planned better.

It would be great if the actual time from the simulation was recorded in the file and the web control could then have a count down function to show time left to completion, which would be very accurate.
I have just completed a 2hr 2min print and 28 mins into the print the Estimated Time Left for Filament Usage was 28mins short, File Progress was 16 mins short and the Layer Time was 40 mins long.

So the M37 sequence could be incorporated into the new macro file processing system, which could be run,on demand, during bed warm up. Not sure how to write the result into the g file for processing by the web control though.

---

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