Support jerk

[eyal0]

There is a good explanation of how jerk works here: http://www.printrbottalk.com/forum/viewtopic.php?f=22&t=7040#p46145

It shouldn't be too hard to adjust calcmove.c for this.

[arhi]

I know how it works (the jerk) it's just that I don't own a single printer that uses jerk so I can't test the implementation hence I never tried to implement it

[eyal0]

Okay. Jerk is pretty complicated because it can have affects on the speed into the far past. I thought to try to solve it myself and test it myself.

[arhi]

it's not that complicated but the problem is "how is it implemented" in each firmware. the junction deviation thing I copied from the smoothieware code so for e.g. I know that for smoothieware it is 100% identical what gcodestat calculates and what is executed by smoothieware... the code for jerk is not that isolated in marlin and I didn't want to import half the marlin into this project in order to have jerk identical to how marlin does it (I seen few projects that do just that). I did implement jerk in the beginning according to the general idea how jerk works (what's explained on printbottalk too) and it was not identical in timing with marlin and error was greater then just using junction_deviation so I gave up :D hoping that when marlin moves to 2.x and they drop the flat structure and restructure the code a bit to make it make more sense I'd revisit their code and see if there's a simpler way to extract how exactly they do the jerk..

if you have time to try to implement and test jerk I'm happy to have it in gcodestat :D

[oysteinkrog]

No need, as Marlin now supports junction deviation etc, most people will probably switch to that, instead of jerk.

[eyal0]

You think that people will switch? Why? Is junction deviation better than jerk in practice?

[oysteinkrog]

Yes and yes :)

[arhi]

@oysteinkrog I would still love to have support for JERK if anyone (@eyal0 started doing it already :D ) would do it, but great if Marlin implements jdev too :)

@eyal0 yes, should be better (the way I understand them it's much much much much better), most real cnc firmware's / path finders switched to jdev while back, I doub't any commercial cnc uses jerk any more... will ppl switch, 99% of them never change firmware from whatever printer came with so I still believe having jerk support is something many will use

[eyal0]

I tested GCodeAnalyser, marlin-estimate, and gcodestat against 32 previous runs of my printer, grabbing the results from ~/.octoprint/uploads/.metadata.json. My results are below:

First, it seems like all the estimators are pretty good. R value of around 0.99. But the jerk-based estimators are closest to my Marlin. Maybe because gcodestat is using jdev and the printer is using jerk.

Why is it impossible to create a perfectly accurate estimate? Couldn't we just run Marlin or whichever firmware on a computer and let it pretend to send signals to motors, then see how long that takes?

[arhi]

it's hard to see the curve from the numbers :( .. maybe sharing the data (csv?) ? gcodestat on this graph is the jdev one? not your fork with jerk support?

the .99 is the reason I did not bother too much with jerk as jdev gets results that are very close .. but of course jerk is not same as jdev ... they are close 'cause jerk/jdev does not affect print speeds that much if used properly so you have under 1% of your print time spent in corners and that 1% difference between jdev and jerk can be 10% so we'r talking .1% difference to the total time.. still having proper jerk support makes sense..

perfectly accurate, well, after you found the plus to multiply bug in my code (thanks again for that) the time from gcodestat and from smoothieware is 100% accurate ... so if I preheat the bed and preheat the extruder and start the print the 4-5hour prints have "same" metadata as gcodestat .. few second errors I need to track down I think it's about Z movement or about XYA movement when XY is below threshold.. but it's so close it's irrelevant..

now when you "normally" start the print the heating is not something you can predict

also you can have some issues with streaming where you can lose some time, also if printing from sdcard you can have slow card reading getting issues there too... so you have pauses between gcode execution - can happen a lot with older version of simplify3d generated gcode for e.g...

but getting it inside few tens of seconds on a many hour print is close enough :)

[eyal0]

I see that RepRap has an M37 cost for entering simulation mode. I wonder if it would be possible to do the same with Marlin? There could be a gcode that converts the printer into simulation mode. That would disable all output to the motors. Then just run the gcode and wait until it's done and count how long it takes. I don't think that the stepper controllers provide any feedback to Marlin so we don't need them actually running to do a simulation. This could be tested by printing after disconnecting the wires between the board and the stepper controller.

This would still take just as long as printing, though. I think that the Marlin sends instructions to the stepper to do movements and uses delays between the movements. The delays happen here:

https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/HAL/Delay.h#L142

Maybe there could be a gcode to convert the delay to a counter that doesn't really do a delay but instead just adds up the amount of time that we would have wanted to wait, without actually waiting?

A different M37 command would cancel the simulation mode and report the number of total delays that were elided. We could add that number to the time between M37 and M37-cancel and get the total time to print.

I don't know how accurate this would be. I might have to adjust for the number of times that DELAY_NS or DELAY_MS is called because processing the counter has a delay in itself. It's also possible that there are many, many calls to DELAY_*, so many that just all the counting takes a really long time. Finally, this couldn't run while the the printer is busy printing. That might be a serious limitation. Maybe it's possible to run a Marlin simulation on the OctoPi and then it doesn't have to involve the printer?

[arhi]

This would still take just as long as printing, though.

yup, so since it will take the time, better to use it to make something, let printer print :D

Maybe there could be a gcode to convert the delay to a counter that doesn't really do a delay but instead just adds up the amount of time that we would have wanted to wait, without actually waiting?

there is a code out there to measure time to print something that imports the whole marlin project into itself and pushes the g-code trough marlin and extracts the time that way... have stumbled upon it while researching how to extract jerk code from marlin but did not inspect the code as having whole marlin project inside gcodestat made no sense to me... can't remember the name of the project but should be easy one to find - and someone told me it's bang on wrt time.

Marlin simulation on the OctoPi

octoprint can simulate a printer but it's rather "fast" and is more to test other stuff and not time..

[eyal0]

Looks like marlin-estimate, which I mentioned above, is basically trying to do the same thing as what I described. It didn't seem super precise compared to the scatterplot as seen above but maybe the issue is the variable heatup and cooldown time. Those can lead to differences of 5 or even 10 minutes! The samples that I took aren't under controlled conditions.

I will keep experiment with printing difference objects under controlled conditions and see if the R value is perhaps more consistent. If the only difference between estimate and actual is the starting temperature then I can use marlin-estimate and just account for the heat-up and cooldown in the plugin.

[arhi]

If the only difference between estimate and actual is the starting temperature

it's a big factor for sure, that's why I put the M117 codes in the code so while original 100% estimate is not taking account the heatup time the next one will happen after all the heating so the next M117 read from the file will be to the point :)