How to Use Servo Spindle as 'C' axis

I think you dont need to change the stepgens mode (it would always be in velocity mode)
you would just change the source of the stepgens velocity command (from spindle speed command in spindle mode to PID output in position mode)

I think the component that does this would be similar to the orient component. Switching to velocity mode is trivial.
switching to position (axis) mode requires at least that the integer turns part of the stepgen position feedback to PID be
removed via a local offset and then a move to the current axis position (assuming you want to switch to axis mode without re-homing)

Velocity and accel limits for this move can be done with the limit2 component.

Edit:

I don't think there's any issue with the stepgen position rolling over, since this is a 64 bit floating point number

Thanks you for the response.

I'm confused about 'modes'. I thought I had it figured out there is a velocity mode and a position mode . . mutually exclusive.

You have mentioned 'spindle mode' and 'position mode' both of which exist within a permanent 'velocity' mode.

Would you mind explaining the relationships here? I'm thinking that the method used by 'orient' would have significant advantages for the mill spindle, if for no other reason, then in very quickly orienting the drive dogs for the ATC.

To move beyond that application, I feel like I need a better grasp of the players, so I don't know specifically where to begin.

I think I need to apply 'orient' method to my brain, because I'm just not getting this.

Do 'spindle' and 'position' go together or 'velocity' and 'position'. How are 'position' mode data fed to 'velocity' mode if they are mutually exclusive?

The stepgen mode is a low level hal setting. It need not ever change from velocity mode
what changes is the signal that drives the velocity command.

In spindle mode (direct velocity mode) the wiring is like this

motion.spindle-speed-out -->xxxx.0.stepgen.03.velocity-cmd

In position (axis) mode the (simplified) wiring is like this:

joint.3.motor-pos-cmd --> pid.3.command
xxxx.03.stepgen.yy.position-fb --> joint.3.motor-pos-fb
pid.3.output-->xxxx.0.stepgen.03.velocity-cmd

This re-wiring can be done in a component or using one of the the existing mux components

Simpson36 wrote: The orient component certainly has possibilities, but as is stands, if I understand it correctly from reading the man page, it is limited to a sweep of a single revolution, so it would need to be modified so that an infinite number of steps and/or degrees could be specified.

A potential problem is, again if I understand it correctly, that Orient does not seem to have an axis associated with it. I.e . there seems no mechanism by which g-code could command indexing. ex.(G1 C250 Fxx).

I think that both these issues can be addressed by connecting the C axis (typically joint.5.motor-position-cmd) to the orient.N.angle pin.

PCW wrote: I don't think there's any issue with the stepgen position rolling over, since this is a 64 bit floating point number

It's actually a 64-bit integer step accumulator multiplied by a 32-bit scale. But it won't ever wrap in the expected life of the universe.

On the scale of tens of billions of spindle revolutions you eventually end up with sub-degree resolution.

Yeah, I was thinking of the loss of precision of the hal position (64 bit float)
a 32 bit float hal pin would go bad pretty quickly with large turn counts

Actually, I think the scale is double (64 bits).
But, the fact that total steps is kept as a 64-bit integer means that any spindle would wear out before wrapping the counts.

Thanks again for the info and especially the examples. That makes it SO much easier by providing a starting point.

I have used the mux component so I am familiar with it . . somewhat.

Assuming the inputs would be muxed using logical OR into xxxx.0.stepgen.03.velocity-cmd

Then I have one more question before digging into this. In my use of mux, I do not recal there being an explicit forced switch . . i.e. IN#1/IN#2 (or equiv).

Question: is there an explicit trigger for mux, if so I must have missed the instructions. Can someone point to them?

If there is NOT a switch for the mux, then is it safe to assume that the 'Spindle' and the 'C' would not be active at the same time and therefor safe to mux without explicit control of the mux?

What is driving that question is concern over potentially unwanted buffered data in the two inputs to the mux.

I will have other questions for sure, but this will get me going.

Thanks!

Simpson36 wrote: Question: is there an explicit trigger for mux,

Yes, the "sel" pin or pins choose which input is active.

linuxcnc.org/docs/2.7/html/man/man9/mux2.9.html

Is appropriate for choosing between two float values.

Perfect! Thanks!