Jogging at a certain angle (lathe mode)?

Hi,

I wonder is it possible to jog at a certain angle with linuxcnc in lathe mode?
That would be a nice feature in order to avoid the compound on a cross slide for prototyping.

I guess the pendant signals would have to go through some user comp which would re-calculates the absolute coordinates.
Did anyone do some work in that area already?

it should be fairly easy to implement I think, calculating cos and sine at a particular angle and forwarding the adjusted values

This might be helpful for study.
github.com/LinuxCNC/linuxcnc/blob/master...c/motion/simple_tp.c
github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/axis.c

well simple_tp does single axis jogging only, so one option would be to inject the jog data into the trajectory planner command path eg. by using tpAddLine and setting the motion_state to EMCMOT_MOTION_COORD.

I still don't have enough overview about that linuxcnc code, but so far jogging at a certain angle works for me (I use 45° hardcoded at the moment).

X/Z of the pendant should be used for regular jogging
A/B for simulated cross-slide moves (A jog distance, B jog angle)

I still have some problems syncing the keyboard jog position with the pendant jog position but I guess I'll figure that out today.

MRx wrote:

X/Z of the pendant should be used for regular jogging
A/B for simulated cross-slide moves (A jog distance, B jog angle)

This is a neat idea, I like it!

Perhaps you could write a hal component to set the axis.L.jog-scale(s) according to the required angle? So if your overall jog scale is set to 0.1 mm/count for instance, and your angle is set to 30°, the component would set axis.z.jog-scale to 0.1×sin(30) and axis.x.jog-scale to 0.1×cos(30).

The component could easily be made to have its own "count" input pin for setting the required angle. Not sure how to display the set angle though, I guess using a custom gladeVCP panel?

(Trying to modify the motion code or motion planner to do this seems a bit heavy-handed IMO... and not easy to get right!)

The problem there is the jogs are not coordinated - particularity if they have different acceleration rates.

Wold we need a multi axis simpe tp ?

Maybe just adapt the existing infrastructure and re-use MOTION_COORD (that was my initial approach and worked to some degree ..)

Simple_TP serves its purpose well / independent Axis jogging. Possibly feeding simple_tp with correct parameters should work too (eg. use the slowest axis acceleration as reference instead of independent parameters).
Using simple_tp was my first approach but resulted in a jerky movement at that time I did not check for using common acceleration parameters.

I would think you would need to rewite simple tp for multiple coordinated axes.
But as you inferred the TP is exactly that.
I don't know why the TP is not used for jogging - that would be an interesting question to get answered. My guess is because it was easier.

cmorley wrote:

I don't know why the TP is not used for jogging - that would be an interesting question to get answered. My guess is because it was easier.

Full trajectory planning and jogging needs different kinds of planning: TP needs to be able to (pre-)blend segments, while simple_tp needs to be able to re-plan in realtime, handling nonzero initial conditions (acc, vel).

Well I assumed the TP would need additional code to do jogging.
The two jobs are not that far apart. setting an MDI G1 X1 f1 and then aborting is very similar to a keyboard jog.

The Fanuc control on the Schaublin 125-CCN has something like that implemented, so you can set an angle and then use the jog wheel to move along the angle.