Print times fix

[arhi]

This is very important. I am working with a large format printer (1mx1mx1m) and the difference between knowing a 50hr build will be more like a 70hr build is very important.

then using a 3rd party analyzer like http://www.gcodeanalyser.com/ should be an important step in your workflow. there's more then time that this analyzer (or some other) will provide, and it gets you very accurate report. dunno how you are sending your prints to the printer and what type of stats you keep (for e.g. I use octoprint and it stores metadata about prints so you can see exactly how long some print took) but you can shoot up some g-codes from the history that you know how long they took to print and compare with what analyzer will give you.

[ASpurway]

Or it should be included in the software that has a print time estimator in it and needs to take into account additional settings. I know I can go to another system but why should I? Since it is available on other (free) services, should it not be a tool that Simplify has internally? Whats the point of Simplify estimating print time if it can be off by 50%?

Additionally, I don't really want to upload my files to a cloud service where I am unsure of the security of these systems (I mean I do because I have to but I don't want to). It is less secure and not all files can be uploaded as they are not owned by me.

[arhi]

of course, it should be in the s3d, I was just giving you the workaround ...

[ASpurway]

Fair enough. I do appreciate the problem solving. I just didn't want it to be the end all solution and that no development on simplify's end is required.

[arhi]

I had few free hours and I integrated my solution with S3D
https://github.com/arhi/gcodestat

video and files available (or will be): https://forum.simplify3d.com/viewtopic. ... 310#p36422

[mischl]

thanks to arhi for this!!!

very useful and really accurate!

I have tried different prints between 20 and 110 minutes and the delta is within a few seconds, where S3D is a few minutes.

one possible improvement: adding the heat up time as a constant could be an advantage, perhaps...

[arhi]

glad that you like it, adding a constant time is simple will add that in next batch of changes

[arhi]

one possible improvement: adding the heat up time as a constant could be an advantage, perhaps...

https://github.com/arhi/gcodestat/releases/tag/0.2

add --heatup_time=## (in seconds) or -t ##

example to add 15sec heatup time, read file test.gcode, output test_:

Code: Select all

gcodestat.exe -g e:\temp\file.gcode -o e:\temp\brisi_m117.gcode -s 5 --heatup_time 15 --acceleration 1000

[arhi]

https://github.com/arhi/gcodestat/releases/tag/0.4

* added -w or --alert option so you don't have to use system msg but it directly display the message box with info about total time (works only only windows for now)
* added --api_key and --api_url so it can directly upload to octoprint (libcurl.dll included in the release, if you are compiling on linux/osx just have libcurl installed or curl-dev or curl-devel depending on your distro)