New Trajectory Planner - Testers/programs wanted

well - I built a realtime version on the pentium 4 celeron (what I have been using for testing reatime builds) and it ran steve.ngc just fine.

I don't know what is wrong with my laptop sim build. I just tried a fresh pull and same thing.

sam

No clue what is wrong with my laptop.. I built simulator on a couple more machines - 10.04 and 12.04 (laptop is running 12.04) and all ran steve.ngc just fine.

Could it be a run-in-place issue? maybe the wrong version is being launched?

I had pulled your latest this morning and you must have fixed it.. 20265a9 runs perfectly (I have not pulled what you pushed today..) (I have both versions in separate directories and the previous pull fails. - g9ea88c1 )

rellenberg wrote: Could it be a run-in-place issue? maybe the wrong version is being launched?

This is still the experimental branch - up to date as of today. This is a realtime build running stepgens (500ipm 40i/s^2)

I am getting a



Just a heads up. It doesn't happen in a sim build.. or some other configs - here is the files

electronicsam.com/images/KandT/testing/steppercon/

sam

Ahh, good catch. I enabled some additional debug outputs, and that "error" is one of them. What that error means is that the trajectory planner has overshot slightly. However, the size of the error is quite small, so in practice it won't affect anything. This condition occurred in the original TP as well, but there was no message to say so. I'll disable that error flat in a future commit.

Cool - I have been running the experimental branch and have not seen an overage.. Very neat

I have a question (and maybe this is a bit vague and I can get more info later) I was running a program that someone had posted and it was running great at an acceleration of 500mm/sec^2. I was not seeing many fallbacks to parabolic blends. I upped the accelleration to 1000 and they started appearing more. Mainly on 90deg or sharper angles. Are parabolic blends faster at higher accelerations?

rellenberg wrote: Ahh, good catch. I enabled some additional debug outputs, and that "error" is one of them. What that error means is that the trajectory planner has overshot slightly. However, the size of the error is quite small, so in practice it won't affect anything. This condition occurred in the original TP as well, but there was no message to say so. I'll disable that error flat in a future commit.

The difference in performance shrinks the closer to 90 deg. you get. Also, as the line segments get shorter, the maximum speed does as well, since we have to hit each segment at least once. The combination of those two effects could mean more fallback.

One thing to try is disabling the fallback entirely, to see if it runs faster or slower. The estimate of parabolic vs. circular arc speed is a guess, so in some case it may fall back even when it would be better not to. It would be really nice to isolate this with a simple case. I have a test file called "long-kink.ngc" that might work for this. Basically, we want a long segment, then a short segment at an angle, then another long one again. Comparing the velocity profiles for parabolic vs. circular arc would show which was actually better.

I'm working on a tech demo of line-arc and arc-arc blends now, but I plan to revisit this after that's out of the way.

Can't wait to play with arc-line arc-arc... Again - great work!.

as far as my issue with falling back to parabolic blending.. I had been testing the sim mm-axis.ini in it it has

DEFAULT_ACCELERATION = 508
MAX_ACCELERATION = 1732

I have not researched it - but I thought default was like default velocity - but it uses it as the axis limit.. (and I don't know how it interacts...)

when I added the peak velocity and acc side panel - I notice it was only peaking at 508mm/s^2. (and doing parabolic blends on some of the corners)

I deleted the 2 lines (my other configs don't have them) and it ran with very little fallbacks..

sam

rellenberg wrote: The difference in performance shrinks the closer to 90 deg. you get. Also, as the line segments get shorter, the maximum speed does as well, since we have to hit each segment at least once. The combination of those two effects could mean more fallback.

One thing to try is disabling the fallback entirely, to see if it runs faster or slower. The estimate of parabolic vs. circular arc speed is a guess, so in some case it may fall back even when it would be better not to. It would be really nice to isolate this with a simple case. I have a test file called "long-kink.ngc" that might work for this. Basically, we want a long segment, then a short segment at an angle, then another long one again. Comparing the velocity profiles for parabolic vs. circular arc would show which was actually better.

I'm working on a tech demo of line-arc and arc-arc blends now, but I plan to revisit this after that's out of the way.

btw - I have been running a lot of programs through the experimental branch and have not had any overages. (awesome)

sam