QTPlasmaC with fourth axis - rotary

Aciera wrote:

@phil as a sanity check: Are you able to actually have a simulation go at 20'000mm/min?

Not even close...
With max acceleration of 50000 and max velocity of 12000 the very best I could get on the standard code was 10500. The last corner was only 4380. These numbers are from motion.current-vel using hal sampler.
The result is attached, column 1 is joint.3.vel-cmd and column 2 is motion.current-vel.
 

 

Ok, Just found out that I have to run this simulation on a pc with an RT kernel otherwise the maximum velocity gets capped.

Is that on a virtual machine?

No, on physical PCs. The usual sim stuff I do on my everyday non-RT machine. But with this I noticed that no matter what (crazy) numbers I put into the ini file all moves, even if it involved just the X axis, maxed out well below 10m/min. Since I moved the testing to the PC running an RT kernel I can now simulate moves with 100m/min without a problem.
I'm not yet sure if this has any implications on my results regarding coordinated 4axis speed.

Is it the same sim config or is it possible the “slow” machine has the max velocity restricted in the [TRAJ] section.

Aw jeez, you called it. x)
So, never mind. I had better spent my time looking for my glasses.

There are so many variables to keep track of. This has been an interesting experiment, I hope someone figures out how to get some decent look ahead for all axes in the not too distant future.

Now I can also see the jerky movement that I was expecting:
 

It's sure a lot faster than it was before

So I would think the question to ask then is it useable as is or not?

The problem seems to be that you would need insane acceleration values to reach feedrates of 20m/min with the one line look ahead. And of course the shorter the segments the higher the acceleration would need to be.
It's like driving on a road in fog, because you can't see what lies ahead you can only go so fast so you can react to changes. The thicker the fog the slower you go. Unless you could brake/speed up instantly, of course.
So, as I see it at least, this is beyond what LinuxCNC can do in its current state.