How to Use Servo Spindle as 'C' axis

Simpson36 wrote: It is surprising that this capability has not been added as a standard feature of LinuxCNC.

I can't see how it could be added as a standard feature. Can you explain what you think that would mean?

Nevertheless, somehow I need to resolve this because hard tapping is not the only application. I need to orient the spindles to line up the tool holder drive dogs with an ATC swing arm.

You can do this with M19, but the HAL layer will always be hardware specific.

This ended up in my spam for some reason. Sorry fr late reply.

I have been 'under the hood' of LinuxCNC/PathPilot for only a few months so I may be harboring some incorrect ideas and please feel free to correct me.

I do not see how 'hardware specific' comes into play when LinuxCNC is sending the same Step/Dir or Analog to any drive, from any manuf. i.e the exact same signals would go to Mitsu, Yaskawa, Alan -Bradley, etc.
What is needed it an awareness that a drive (specifically Step/Dir in this case) can be either a spindle or a 'rotary axis'.

It may be that I am showing over confidence in LinuxCNC, but at this point I have to believe that if Vital systems can accomplish this in their motion controller for Mach3, then certainly LinuxCNC can at least do the same if not significantly more.

The notion that one channel can flip flop using different inputs just flies in the face of my real world experience with this topic because the 'tuning' for a spindle is so drastically different from that of a rotary axis.

My thought, and the result of my solutions as described earlier, is to use two separate channels, separately configurable and tune-able, and switch the OUTPUT to the drive.

Please know that it is not my intention to disparage any attempt at a new capability, but everything I have researched so far has taken the route of changing the INPUT to a single channel and outputting the result to the drive.

While I readily admit that I am no LinuxCNC expert, I probably have more experience at emulating true Mill/Turn on a bench mill than anyone. That experience tells me that you need two independently configurable and tune-able channels and swap the OUTPUT of each to the drive.

I do not have a lot of time to spend on this, so my solution will be tried and true hardware switching of the above mentioned TWO channels, and I already have that set up in LinuxCNC for the current project.

That being said, I am more than happy to collaborate with people much more familiar with LinuxCNC to see if this is doable in software.

Simpson36 wrote: I do not see how 'hardware specific' comes into play when LinuxCNC is sending the same Step/Dir or Analog to any drive, from any manuf. i.e the exact same signals would go to Mitsu, Yaskawa, Alan -Bradley, etc.

Perhaps I should have said "configuration specific"

LinuxCNC has quite a simple job between the G-code layer and the HAL layer. It's a complicated job to do it correctly, but basically the X-word Y-word etc positions converted to actuator positions are sent to HAL to be interpreted as position commands, as is the spindle speed.
Nothing in that layer really knows anything about the configuration of the machine on the other end.

It seems to me that the appropriate place to combine the spindle command and any specific axis is in the HAL layer where all the necessary information is available, and where a specific configuration can be configured.

What is needed it an awareness that a drive (specifically Step/Dir in this case) can be either a spindle or a 'rotary axis'.

Until you are in the HAL layer the system makes absolutely no distinction between step/dir , analog, digital or any other type of drive.

My thought, and the result of my solutions as described earlier, is to use two separate channels, separately configurable and tune-able, and switch the OUTPUT to the drive.

This is certainly the way that I have always suggested doing it with analogue-controlled servos. I don't know if it helps very much with step/dir servos as the loop with the important tuning difference between the modes is in the servo drive in that case.

I do not have a lot of time to spend on this, so my solution will be tried and true hardware switching of the above mentioned TWO channels, and I already have that set up in LinuxCNC for the current project.

The drawback of this approach is that you are switching in a layer that is unaware of the current axis position, so you will (probably) loose your absolute positioning when switching between spindle and rotary modes. This is why I think the switch should be in HAL, using either the "orient" component ( linuxcnc.org/docs/2.7/html/man/man9/orient.9.html ) or something rather like it.

The neatest place to make the mode-switches for a step/dir system would be in the stepgen itself. That knows it position, and has all the authority and feedback it needs to seamlessly switch between position and velocity. However if it was done there, it would be no help for analogue/PID or digitally controlled systems.

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 am still looking for a spindle solution for the long term. My method works very well for Mill/Turn, but has some undesirable behavior for the mill spindle. You are correct in that the registration is lost when switching from what I call 'Turn' mode to 'Index' mode on the 4th axis and this is also the case with the mill spindle. The solution has been home sensors if registering to a specific azimuth or to 'zero' is required. The homing method works very well for the 4th axis, but is problematic with the mill spindle due to the higher speed and smaller diameter available for a sensor. There is overshoot, so the spindle must be brought to some known speed before the sensor can be read.

The speed at which the process completes is not an issue for the 4th axis, but tool change times are extended significantly waiting for the spindle

The 'orient' component looks like it would solve the sensor overshoot problem and be much faster since the registration is known at any speed and would be therefor be immune to overshoot.

I can see in LinuxCNC where the 'count' is being accumulated.

Question: When the 'count' eventually rolls over, is the registration maintained in some way?

Another issue that you raised is that the 'tuning' is within the drive for step/dir which is true, but typically it is used as a MAX to prevent faulting, smoothing transitions and that type of thing. While industrial drives usually have not only configurable, but also switchable gains and other parameters, I think it is more common to have only maximums set at the drive and acceleration controlled by the CNC software.

So then another question arises; assuming some modification of the 'orient' component and therefor switching a stepgen between position and velocity, would acceleration be separately configurable for each mode, or would it need to be read and changed on the fly?

To ask a different way, is there one parameter for a step/gen that would be applied to position and velocity, or are there separate parameters for each?

Thanks for taking time to share your knowledge on LinuxCNC.

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?