G Code Generation for Camshaft grinding

TobiasKa wrote: Currently I'm configured two linear axes. Do you expect any better performance if the rotary axis is configured as a rotary axis?

No, I would expect worse performance with a rotary axis as the path-blending in angular-linear moves uses a single segment lookahead whilst linear-linear uses a many-segment lookahead.

Do you know if your axis acceleration limits programmed for the axes are anywhere near the physical/mechanical limits?

Ok, so I will stay with the "double linear" configuration.

I tried several acceleration values for the linear axis.
There I have not seen any improvement nor deterioration.

I have looked through the documentation, but I have not found any detailed information how the acceleration values are taken into account during a synchronized G01 movement.

Anyway I have just wrote down how I calculated the desired velocity of the system:


Maybe someone can point out where the flaw is in the calculation process?

Try putting G61 at startup linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g61-g61.1

TobiasKa wrote: Anyway I have just wrote down how I calculated the desired velocity of the system:

Attachment not found

Maybe someone can point out where the flaw is in the calculation process?

I don't think that there is anything wrong with the calculation, but I am unsure why you are doing it.

The INI file limits should match the machine capability, not be based on the desired speed. They are limits.

This might be useful reading:
linuxcnc.org/docs/2.7/html/user/user-con...#_trajectory_control

Note that in this context the "naive cam detector" is detecting G-code from naive CAM software (lots of short straight moves) and has nothing to do with mechanical cams.