New Trajectory Planner - Testers/programs wanted

Sam,

The homing should be exactly the same as they are simple moves (no blending...)

First is normal homing with acceleration of 100.



Second is homing with acceleration of .05



Of course this just on a sim.

Rick G

sim homing does some funky stuff to 'simulate' home switches..

git.linuxcnc.org/gitweb?p=linuxcnc.git;a...56092b130d32;hb=HEAD

Using comp and ors - I think it is right until someone says it is wrong

sam

My homing works normal..

Just wanted to check in (late). I worked on this today and wanted to say thank you! I am seeing excellent motion. I might have missed this earlier, but my first spiral consists of basically quarter-round splines. The new trajectory planner pulses through the spiral somewhat speeding along the spline segment and then REALLY slowing down as it goes from one spline segment to the next. After I converted the spline spiral to polylines, it really sped up and, maybe more important to how I use LinuxCNC, the polyline was very consistant in speed.

Should I plan on converting my splines to polylines in order to take advantage of all this work?

In a hobby/business (more hobby) enviroment, how ignorant of me to want to use this 2.6-pre version fulltime?

Again - Thank you for all this.

Paul

Paul wrote:

In a hobby/business (more hobby) enviroment, how ignorant of me to want to use this 2.6-pre version fulltime?

I did have a problem with a 2.6-pre from master once after an update; crash on startup. That was when I decided to revert back to 2.5.3 and run 2.6-pre as RIP.
Normally I use 2.6-pre, but if I suspect problems I can always start 2.5.3. Switching is as easy as clicking a different icon on the desktop.

In my hobby environment 2.6-pre runs flawless, but I don't have a very complicated setup.

DaBit wrote:

In my hobby environment 2.6-pre runs flawless, but I don't have a very complicated setup.

Thanks DaBit. Have you seen issues with splines that don't seem to show up with polylines? Maybe this is coming from my CAM program?

What are the splines made up of? if they are a bunch of arcs that are not joined at perfect tangents - then yes - short line segments are going to run faster. could you give us a short example of the 2 programs (one as splines and one as polylines?) but I assume the above - splines are made up of arcs - polylines are made up of line sements.

To recap - so far the readahead works with
line-line segments
tangent line-arc segmetns
tangent arc-arc segments

Paul wrote:

DaBit wrote:

In my hobby environment 2.6-pre runs flawless, but I don't have a very complicated setup.

Thanks DaBit. Have you seen issues with splines that don't seem to show up with polylines? Maybe this is coming from my CAM program?

No, I haven't. But that must be CAM-related.

90% of my millng is done using handcrafted G-code using a mix of a few O-word calls for standard operations and some logic in G-code. Or just start a milling operation from a GladeVCP panel. Many parts I make are a variation of 'mill to size, make a few holes and pockets, and mill a contour'. As I said before: usually I am not doing complicated things. Although I want to do more 3D-contour milling, which is pretty slow with the current TP and a reasonably accurate G64 Px setting.

The only CAM-software I use is CamBam+, partially because it generates such a nice G-code (for a CAM-program, that is) using it's arc-fitting algorithms etc. and partially because I can afford it. Software like Deskproto generates plain stupid G-code which runs like sh*t on the original TP (my trial has expired, BTW). The code I have seen from Vectric products is even worse. Megabytes and megabytes of short G1 segments. The new TP should really shine on that. Unfortunately I don't own that either.

My spiral was made in Inkscape which was saved with thier version of an AutoCad R14 format. That's where the splines come from. I then converted the spiral to polyines.

Thanks...

PK

What is the problem?
I can open both spiral NGC's and run them. On a sim config at least; cannot run code on the real machine without actually powering it on.

Polyline code seems to be faster on the new TP, circular code on the current 2.5.3.