Running a simulation to calculate printing time January 29, 2015 04:39AM |
Registered: 10 years ago Posts: 14,672 |
Re: Running a simulation to calculate printing time January 29, 2015 05:31AM |
Registered: 9 years ago Posts: 24 |
Re: Running a simulation to calculate printing time January 29, 2015 05:57AM |
Registered: 10 years ago Posts: 275 |
Quote
dc42
I
(b) run a simulation on demand
Re: Running a simulation to calculate printing time January 29, 2015 06:34AM |
Registered: 9 years ago Posts: 102 |
Re: Running a simulation to calculate printing time January 29, 2015 07:07AM |
Registered: 10 years ago Posts: 14,672 |
Re: Running a simulation to calculate printing time January 29, 2015 07:23AM |
Registered: 9 years ago Posts: 38 |
Re: Running a simulation to calculate printing time January 29, 2015 07:45AM |
Registered: 9 years ago Posts: 102 |
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
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.
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
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.
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?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.
Re: Running a simulation to calculate printing time January 29, 2015 08:08AM |
Registered: 10 years ago Posts: 2,472 |
Re: Running a simulation to calculate printing time January 29, 2015 08:11AM |
Registered: 10 years ago Posts: 14,672 |
Quote
tstone
Wouldn't it be possible to have printer profiles which allow the slicer to write down the estimations 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.
Quote
tstone
Are there any PWM channels free to use on the duet?
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.
Re: Running a simulation to calculate printing time January 29, 2015 09:58AM |
Registered: 10 years ago Posts: 209 |
Re: Running a simulation to calculate printing time January 29, 2015 10:43AM |
Registered: 9 years ago Posts: 191 |
Re: Running a simulation to calculate printing time January 29, 2015 10:58AM |
Registered: 10 years ago Posts: 2,472 |
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.
Re: Running a simulation to calculate printing time January 29, 2015 11:25AM |
Registered: 10 years ago Posts: 378 |
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.
Re: Running a simulation to calculate printing time January 29, 2015 12:17PM |
Registered: 10 years ago Posts: 2,472 |
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.
Re: Running a simulation to calculate printing time January 29, 2015 07:27PM |
Registered: 10 years ago Posts: 378 |
Re: Running a simulation to calculate printing time January 29, 2015 07:41PM |
Registered: 10 years ago Posts: 14,672 |
Re: Running a simulation to calculate printing time January 30, 2015 07:02AM |
Registered: 10 years ago Posts: 2,472 |
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).
Re: Running a simulation to calculate printing time February 01, 2015 03:50AM |
Registered: 11 years ago Posts: 103 |
Re: Running a simulation to calculate printing time February 01, 2015 07:16AM |
Registered: 10 years ago Posts: 2,472 |
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.
Re: Running a simulation to calculate printing time February 01, 2015 09:12AM |
Registered: 10 years ago Posts: 780 |