Home designed and built 5C CNC lathe with ATC and C_Axis

Ok, a lot to digest, but this is very good info - thank you.

If I may, I need to ask my same question in a different way, given the last paragraphs in your post-
First, do I understand correctly :
Using your robotic arm as example, since the lathe 'joints' are excessively simple,
If you have a motor at the base of the arm (like a music record turntable with the arm sitting on the record) and you rotate that motor,the whole arm rotates about the axis of that motor. So if you jog that motor (joint..) the whole arm rotates, and the tool at the very end of the arm simple rotates around that joint's axis, in a radius equal to the tool tip distance from the joints vertical axis. Thats a joint jog or rotation I believe?

Now if you wish to move the tool tip from a point in 3D space to a new point in 3D space, you have to move ( probably) every joint in the arm to get the tool tip there, in a specific orientation, AND ALONG A SPECIFIC PATH - That is a coordinated move.

If I understand that correctly, then the two modes are actually very simple in concept. But what does that mean then in my simple lathe?

I do not see the same concept existing, since there is no coordinated move when jogging. I understand that if I jog X, then its the same as the jog of that Record Turntable your robot arm is sitting on - just X moves, even if only linearly. If I wish to move the tool tip from an X,Z point to a new one, I can do so by jogging X first till at new X, then Z till at new Z. Is That what is termed 'joint only' moves?

If I wish to get the tool there following a straight line between those two points I have to turn both X and Z handwheels in a coordinated manner so that the tool follows that straight line - That is what the kinematics would do to interpolate the X and Z stepgen pulses to move in a coordinated manner. ( coordinated jogging by hand was just to illustrate my understanding of the concept..)

As I have managed to get the jog to work on my setup after homing, with the HAL file as I posted, and without those HAL statements posted by Andy, what Mode am I actually jogging in? You indicate it is in coordinated mode, but if I jog, its only ONE axis that moves, which is 'joint mode'. So after thinking I understand joint and coordinated moves/jogging, I discover I actually don't!

After homing you are jogging in XZ space. Before homing you are moving the X and Z motors.

What makes this a little confusing is that, in your case, the two things are functionally identical because you have a machine with cartesian joints.

But the software is in two different states before and after homing.
(you might start to see a difference if you introduced backlash compensation, or screw error compensation)

So if you jog that motor (joint..) the whole arm rotates, and the tool at the very end of the arm simple rotates around that joint's axis, in a radius equal to the tool tip distance from the joints vertical axis. Thats a joint jog or rotation I believe?

Yes.

Now if you wish to move the tool tip from a point in 3D space to a new point in 3D space, you have to move ( probably) every joint in the arm to get the tool tip there, in a specific orientation, AND ALONG A SPECIFIC PATH - That is a coordinated move.

Maybe 'coordinated mode' is not the correct term so lets say 'axis-mode' because the coordination you mention actually comes from the motion planner. (I changed my last post to clarify)

As I have managed to get the jog to work on my setup after homing, with the HAL file as I posted, and without those HAL statements posted by Andy, what Mode am I actually jogging in? You indicate it is in coordinated mode, but if I jog, its only ONE axis that moves, which is 'joint mode'. So after thinking I understand joint and coordinated moves/jogging, I discover I actually don't!

It doesn't matter how many joints (motors) or axis move. You can jog multiple joints in joint-mode and/or jog multiple axis in 'axis-mode'

Hi NoJo,

I’m an engineer at Teknic, and I saw your post. In case it wasn’t already mentioned, you can use ClearPath’s “Precision Homing” feature in conjunction with the “User Seeks Home” option to allow your controller to control the homing instead of allowing ClearPath to home autonomously. The autonomous homing is a nice feature for many types of machines, but most CNC controllers will “expect” to handle the homing process, so you may find the User Seeks Home option easier to code for.

(In the context of this post, I will be talking about the ClearPath-SD series which takes step and direction input. Unfortunately I don’t know much about your specific controller, so my advice is for a generic step and direction host controller, but I think it should apply here.)

To reiterate, there are two “homing styles” in the ClearPath-SD series: “Automatic” and “User Seeks Home”. Both options use Teknic’s hardstop homing algorithm (which finds a home reference position without the need for a home sensor and associated wiring).

The Automatic mode will initiate homing (and begin to move) as soon as you enable the servo, which is convenient for many types of machines, but the homing parameters (e.g., velocity and acceleration) are set within ClearPath and thus not under control of the host. Also, the host can only control the start of the homing sequence by enabling the motor, i.e., you can’t enable the motor and then later choose to home (without first toggling the Enable line).

The User Seeks Home style offers you more control over the homing process while still taking advantage of ClearPath’s hardstop homing feature. In this homing style, when you enable the motor, the hardstop detection algorithm becomes active (waiting to detect a hardstop, and limiting the torque to a lower torque limit, if desired), but no motion will occur without a command from the host.

When the host is ready to home, it sends the motor toward the hardstop (using the step and direction signals) while looking for ClearPath to assert the HLFB signal. When HLFB is asserted (meaning that ClearPath has detected the hardstop and moved to the offset position as set within ClearPath by the user), the user sends one or more steps in the direction away from the hardstop to “confirm” that it has seen HLFB assert. This turns off hardstop detection and restores the normal torque limit.

If you want to cancel homing for some reason (e.g., you already know where the axis is), sending one (or more) steps in each direction will cancel homing (i.e., turn off the hardstop detection and the homing torque limit). This also means you can jog the axis in one direction before beginning your homing sequence. (Jogging in both directions would deactivate the hardstop detection.) You can reactivate the hardstop detection by toggling the Enable line assuming you’ve set up ClearPath to home on every enable (as opposed to only homing on the first Enable after power-up).

So, with a generic step and direction controller, you can use the User Seeks Home style to have full control over your homing requirements. If you have firmware version 2.0 (which it sounds like you do), you can also use Precision Homing which allows for very accurate homing even if the hardstop changes a bit over time or temperature. Here is a video clip (start at 3:34) that explains Precision Homing (it’s in a video about the MC-series, so don’t get confused; it works the same in the SD-series): .

Please feel free to contact Teknic at support@teknic.com or call us at 585-784-7454.

Best regards,
Trent T. – Teknic Servo Systems Engineer

Hi Trent.
Thanks for jumping in here. I would like to be clear on this issue if you please..I purchased my Clearpath motors in Dec 2020, and had discussed this mode with Matt Cmelko the beginning of Jan this year - My motors are CPM-SDSK-3441S-RLN / CPM-SDSK-3432S types, so plain 'stepper-killer's' .
In my discussion with Matt I understood that the HLFB signal would not work with these motors, ie, sd-SK type motors, but works on MCVC and MCPV types. that is, with motors capable of positioning modes, with the HLFB set to ASG-Position or ASG-Position Latched.

I accepted that since the SDSK motors have no concept of 'positioning' - they simply accept step and direction signals.
Are you saying that the ASG mode WILL work with SDSK motors for the homing function?
I did find the various topics on homing, in the Clearpath MC/SD ( rev-3.08) user manual a little confusing on this!

The most concise appears to be on page 186 - MANUAL HARD STOP HOMING SEQUENCE..
Your post, as does that paragraph, implies this mode is applicable to step/dir SD motors.

If so, that will certainly provide an elegant homing solution!

This statement of yours is important -

If you want to cancel homing for some reason (e.g., you already know where the axis is), sending one (or more) steps in each direction will cancel homing (i.e., turn off the hardstop detection and the homing torque limit). This also means you can jog the axis in one direction before beginning your homing sequence. (Jogging in both directions would deactivate the hardstop detection.) You can reactivate the hardstop detection by toggling the Enable line assuming you’ve set up ClearPath to home on every enable (as opposed to only homing on the first Enable after power-up).

In linux CNC when the controller 'ON' icon/button on the screen is activated, the controller activates the motor's enable signal inputs. clicking the icon 'OFF' disables the motors again - I don't know how linuxCNC handles this - perhaps someone can chip in here - does one have to home every time you turn the machine off then on again ( via that on-screen icon) ?
If so, then the motors must be set up to do homing every time the controller is turned on again - presume homing each time is required as the controller would not know if the motor positions had shifted while in OFF mode...

Trent, if you could just confirm[strike] me[/strike] my 'new' understanding please, and also to confirm that I should set HLFB to ASG-Position Latched mode?

Thank you.
Joe

does one have to home every time you turn the machine off then on again ( via that on-screen icon) ?

You can configure that either way. By default you don't have to rehome.