New Trajectory Planner - Testers/programs wanted

I realize many machines are different (i.e. gantry weight, motor size, etc), but I believe a MAX_ACCELERATION of 2000 would lock up my X axis. I'm not near it at the moment to check for sure. Also, would someone else's lower MAX_LINEAR_VELOCITY setting while testing help mask issues Quadro is having.

This is a metric machine so this is 2000 mm/S^2, not too bad, roughly 1/5G
2000 Inches/S^2 would be scary...

My machine is metric. Anything over 1000 mm/S^2 on my X axis and fast moves start shaking the table a bit.

That being said - he is running steppers so probably not closing the loop in linuxcnc.. He should not be getting following errors..

Paul wrote:

My machine is metric. Anything over 1000 mm/S^2 on my X axis and fast moves start shaking the table a bit.

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.