Simulations take too long
Some simulations take too long, up to 30 minutes while websites like http://gcodeanalyser.com/ took seconds.
I imagine that the simulation is running within Duet - that is nice to have whe I start the simulation from PanelDue or with a stand alone printer. But when using DWC would not be better to run the calculations locally?
Also, during simulation I tried to send some gcode commands, like set the bed temperature to better use this wait time or read the latest data from Duet3D Laser Filament Monitor. But the commands where only executed after the loooong simulation.
I like the feature very much - I've been taking notes of the simulations and they are always close to 1% from the real time of the print - but 20+ minutes for more complex prints is too much
tomasf last edited by
I agree. The feature is nice, but I rarely use it because it's so slow. I would gladly trade a bit of precision in the calculated time for a nice speedup.
wilriker last edited by
I would gladly trade a bit of precision in the calculated time for a nice speedup.
But precision is the main purpose of simulating it on the controller.
@wilriker The local computed simulation could emulate the perfect conditions to achieve this precision. the G-code Analyser web for example is within 5% that is very good - I imagine that the duet simulation would be even better.
wilriker last edited by
@brunofporto I am not sure if you understood what I tried to say:
Currently the simulation is as precise as it can get to the real thing because the controller basically prints the file. It will just not issue any commands to the peripherals but only track time. But it will apply all tweaks and improvements as well as all settings that are currently active.
Something like G-Code analyzer does something very similar because it lets you set all the things like speed, acceleration and jerk. But it does not know about any internal processing steps the actual controller does. That is why it is "only" within 5% of accuracy.
It is not impossible but creates a lot of overhead for development - and once they drift out of sync (out of whatever reason - might be just a bug) people will start complaining that the simulation is off by 10 minutes suddenly and so on.
But I agree that simulation should not be a blocking operation and should allow one to set temperatures and other things simultaneously.
Simulation typically runs at about 60x printing speed. It will take longer for complex shapes with many curved perimeters (e.g. a single wall hollow cylinder, for which every move is a curve) and less time for simple shapes (e.g. if the perimeters are mostly straight lines). How much slower do you find it than printing on your models?
@dc42 These last files are particularly heavy on this ( a Batman figure with even "textile textures"). The files are between 15mb to 20mb and the time to simulate is more like 10x faster (25 minutes to simulate a 250 minutes printing for example)
In general is not an issue as most of my prints are mechanical parts with lots of straight lines and I simulate them while heating the bed - so no time "lost".
But these last files are taking much more time than that
@dc42 Maybe have both worlds... Up to certain size of gcode it always simulate like it is now. But if bigger than a certain threshold than ask if the user want to calculate a less precise simulation "gcode analyzer alike".
@dc42 The latest example: 19m 06s of simulation and a predicted time of 4h 19m plus heating time.