Parser is before all the math.
I searched for how this xenovacivus person generates these plots and here he says he has a logic analyzer on the step & dir pins. Maybe that’s why he’s the only one posting those lovely plots.
Shoot
Double shoot. I am literally probing those very pins right now with the scope, DIR is easy enough, step I was pushing buttons trying to bet some sort of idea what the numbers were.
Turns out my scope is/can be a logic analyzer…just need to figure that out now. So Awesome and probably way over my pay grade.
That is more advanced than the scopes I’ve used! It would be sufficient to just dump the step and dir rising and falling timestamps to a file and let me post process them in python to plot them. But, if all you have is a hammer, everything looks like a nail.
I was wrong I do not have the LA version. Bummer. I did stare at the equations and planner for a while acting like I was learning something but wasn’t.
1 Like
Fake it 'till you make it!
2 Likes
And the corollary:
If you can’t impress them with knowledge, baffle them with bull sh!t.
1 Like
I messed with it some more last night. You have to set a dimension for the mm_per_segment. So I tried all the way down to 0.1mm. That certainly slowed it down. So not that means either, that screwed up the acceleration equations, or cpu could not keep up (buffer 50%) and it hit the low buffer slow down specified in the firmware.
Watching the machine run, I will have to do some of the tests again. I think the issue is actually going from an arc to a straight segment. It seems to reset the acceleration/jerk and jump to full speed.
Why can’t I just ignore this and turn of arcs? It looks better with arcs on, so I need to dig through some estlcam settings, must be a arc resolution setting?
I just flashed and ran it more than 45 times this afternoon. I tried a ton of different things. Nothing is perfect yet.
I found a cool trick though. Acceleration is not factored into any of the equations as far as I know it is just put in after. So if you slow it down to 50-100mm/s/s it still screws up but it is just in slow motion. So that eliminates the buffer as a variable as it has plenty of time to fill, SD card isn’t an issue same reason, and acceleration is not a factor either. Doesn’t eliminate the file itself (with and without arcs have issues).
So I will try it again tomorrow.
I tried with 0.1 mm segment length and I am seeing the buffer being depleted occasionally with the high speed torture test. I’m not sure if this is the only thing happening but it is at least one factor. The top two lines of the MAX7219 shows the queue fullness:
I also ran as slow as I could tolerate to minimize ringing to see if I could see the difference between the polygon at 0.3 and a smoother curve at 0.1 and I do see a difference. Whether it is worth it is a question I can’t answer but the coarser segments do make a difference. First image is 0.3 mm segment length and second image is 0.1 mm segment length.
I still think it makes sense to choose segment length based on feed rate so you can have the best of both: high resolution at low speed and avoid flooding the queue at high speed. It doesn’t sound hard. I’ll give it a shot.
1 Like
It appears to work. Fast torture test doesn’t deplete the queue and slow version has no polygons. I threw it over the fence for the Marlin folks to decide if they like it or not.
I used
#define SEC_PER_ARC_SEGMENT 0.020
(could probably be 0.010) and
#define MM_PER_ARC_SEGMENT .01
which is only used as a minimum segment length for extremely low feed rates.
4 Likes
And it’s already been merged!
Whoa, I wake up and check marlin hoping something arc, jerk, or otherwise motion related is in the bugfix…DANG!
So I was trying to tackle that problem in a different way. It did seem to work. I like the small letter arcs (think milling PCB traces) to be <=0.3mm/seg as well but running large circles at that size obviously slowed it to a crawl. So I used a number large enough to to work on the larger circles 1 seemed good, then use min seg per circle to divide that to something smaller when needed so 8 would take a 1mm diameter circle (those letter arcs) into .25mm segments.
That gives small segments on small arcs and larger segments on larger arcs.
So if you get that down to 0.1mm/seg you are not having issues on the larger arcs?
Wow that was fast.
In my test I had set MM_PER_ARC_SEGMENT to 0.01, super super fine, so it would be entirely driven by feed rate. The queue was never depleted at high speed, so it was choosing a larger segment, and it made smooth small arcs at low speed too. I had the min seg per circle disabled because I am pretty sure that was part of the problem in being sluggish. So effectively now speed takes precedence over resolution instead of the other way around.
Sweet, I will try and test it at lunch time!!!
So is it getting speed from the gcode setting or is it getting it as it accelerates?
Great work, Jamie. Great idea too.
Just thinking out loud (My mantra here), disabling arcs and using CAM for arcs is sort of similar to optimizations in C++. By precompiling the vertices of the arc, you are doing the expensive trigonometry functions on your beefy intel machine, and then letting the puny microcontroller just follow line segments. It will definitely have an effect on the size of the file, and the resources needed to process that file though. Anyway, I am glad this is improving, but I also think there could be an argument for not using arcs in gcode, at least in most cases.
1 Like
Since we’re thinking out loud… I would normally agree with you, but in this case, the micro-controller is also adjusting acceleration and speeds and suchlike, and if we’re going to segment the arc based on the speeds, then CAM-based solutions would be, at best, guesses, and the micro-controller is the place to actually do the calculations.
That is the odd part. I stopped using arcs and was trying to get nice firmware settings last night. I could not, and there are no setting to set resolution in estlcam.I think the resolution is too high in parts and choking it. So I went back to arcs to try and set the resolution in the firmware.
With the acceleration way down it is obvious something is wrong either way. The Z axis even gets a hitch in it’s step…I am pretty lost but I tried turning everything off and doing one at a time.
Turns out acceleration is not as integrated as I thought it seems to be applied after the fact, or at least the issue is before the accelerations get applied.