New Trajectory Planner - Testers/programs wanted

Paul,
This machine has been in operation for about 3 years with those acceleration settings.
Video of it working - Video

Sam,
I'll get the answers soon, sorry. i'm a bit tied up at the moment.

Anthony

I can duplicate this and it looks like it blows up here:

N8860 S100 (On start)
N8870 Y0.000
>> N8880 G02 X450.000 Y-0.500 I-0.500 J0.000
N8890 G01 X0.000

folowing error halscope plot:

ibin.co/1li1vC6KQ3SS

PCW wrote: I can duplicate this and it looks like it blows up here:

N8860 S100 (On start)
N8870 Y0.000
>> N8880 G02 X450.000 Y-0.500 I-0.500 J0.000
N8890 G01 X0.000

folowing error halscope plot:

ibin.co/1li1vC6KQ3SS

Does the velocity spike downwards after it spikes upwards? If so, that seems like a position discontinuity somewhere (like the end point of the straight move doesn't match the start point of the circular arc move). Are you running an RT or simulation build?

This is realtime

The ferror is ~-450

I can do a better scaled plot a bit later but its a madhouse here ATM

(Hmm would be nice if motion captured min and max ferrors for post mortems)

ok - it seems to have something to do with only having 2 axis. (X,Y)

I took the ini and hacked it enough to work with the constraint config. For me it happens twice in the program. also the XY plasma config runs considerably faster for some reason than the xyz config with the same acc/vel. Which seems a bit odd... we are talking to get the the first constraint violation - the XY config runs 53 seconds (end of r) and the xyz config runs at 1:12

something is a bit goofy..

Ok - tested a bit more.. It seems the reason the XYZ runs slower is that it takes into account the Z axis acc/vel (one or both) when doing XY moves. If I set the Z vel/acc very high both configs run about the same. (still no constraint violations with the XYZ config.

So I think there could be some performance improvement if axis that are not moving don't effect the motion. maybe

sam

Nice work! I have a fix in the works for this. The code that checks for the maximum axis accelerations didn't properly handle the case of having fewer than 3 axes. It seems to be a simple enough fix on the TP side, though I still have to look canon. I'll have it pushed to a test branch off of 2.7 in another day or two.