How to Use Servo Spindle as 'C' axis

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!