gearsawe wrote:And are your values for XY movements the same for Z?
this was a "quick test" made while back to see if I can get proper print time at all so I have "hardcoded" values I use in smoothieware and I only support acceleration and junction deviation (smoothieware does not use jerk like marlin for e.g.)... but it's not a biggy to update the application to support jerk too... I have same values for all three axes in this code but it's tops 30min to have different X, Y and Z (attm I have XY one variable and Z other but they all have same value hardcoded) ... also there should be support for M codes that change acceleration and jerk and junction deviation settings on the fly - I don't support those here neither... as I said it was just an exercise to see if it's complicated to get proper time and well it's not..
gearsawe wrote:
In my case Z retraction is slightly different accelerations and jerk.
in most cases Z uses different jerk/accel settings the XY it's normal and expected. anyhow even if you don't account for Z moves, the total Z moves in your print take few seconds, on a few hour print those few seconds total time are irrelevant, so having precise Z move measurement is not too important, but anyhow, it's not a big issue to add separate z settings too ... if I decide to put some more hours on that project I'll do that and put it on github.. especially as recently I added "z hop" option for retraction so Z is not that insignificant any more
gearsawe wrote:
The only reason I ask for a "Wizard" options is not every printer out there has these settings or has settings that are accessible.
[/quote]
well I was planning to allow this code to "read the config file" for smoothieware and auto setup values from there as an option... most of other ones don't have "config file" so would not work for them but one should know what accel/jerk settings one set to the printer. Also most slicers allow you to configure accel/jerk direcly and will send those as G-code at the begining or you can generate that G-code yourself... if I put some time into this I do plan to parse those mcodes
(M201, M203, M204, M205) .. so in theory your "start g-code" should have these and the parser will work properly without any wizard
... anyhow it's all in the realm of theory as "few hours" for me is something I can only imagine these days as I got a second kid few days ago and time became very relative again
gcodestat integrates with Simplify3D and allow you to
Calculate print time accurately (acceleration, max speed, junction deviation all taken into consideration)
Embed M117 codes into G-Code
Upload your G-Code directly to Octoprint
open source and unlicence