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

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 This email address is being protected from spambots. You need JavaScript enabled to view it. 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 me 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.

Hi Joe,

The ASG-Position modes will definitely work with any SD-series ClearPath motor (as well as the MC-series). I talked to Matt Cmelko, and have an idea as to what the misunderstanding was, but first let me explain what I think you should do (which depends somewhat on your goals and the capabilities of the controller).

Before I start, let me say that I empathize with your confusion about homing! ClearPath is used in so many different types of machines and applications, there are many options to choose from. We have written—and rewritten—the homing sections of the manual many times in an attempt to make them as clear as possible, but it seems we may still have a way to go. If you have any specific ideas for improvement, we will gladly take them. In the meantime, I will do my best here to clearly explain what I think your options are.

The most functional HLFB (High Level FeedBack) mode to use for a CNC machine is generally “ASG-Position w/Measured Torque” (the Latched or non-Latched version). To clearly explain why, I need to provide a fair amount of background information first, so please bear with me for a minute.

ASG (All Systems Go), and its variants (e.g., ASG-Position, ASG-Position w/Measured Torque, etc.), all indicate when the servo is ready to accept a new move, more specifically: the servo is enabled, not in a shutdown state, there is no current command (i.e., steps) from the controller, and the servo is fully settled at its target position. Think NASA: “All systems go; we’re ready for launch.”

In the context of homing, ASG will tell you that homing has successfully completed, although the way it works is a little different from its normal (non-homing) operation. While the controller is homing ClearPath in the User Seeks Home mode (i.e., the controller is sending steps toward the home hardstop, but homing is not yet complete), ASG will be deasserted because ClearPath will be seeing a command from the controller. But, when ClearPath detects the hardstop and executes the home offset move, it will assert ASG to signal the successful homing even though the controller is still (most likely) sending steps—this is a special exception to the rule that ASG is deasserted whenever the controller is sending steps.

So, to home a ClearPath axis, you can simply have the controller send steps until ASG is asserted, and then you’re done. As you said, this is an elegant homing solution (especially with precision homing turned on). The only potential issue with this setup is that after homing, while the machine is in normal operation, some people want to know right away, even in the middle of a move, if there is a shutdown of the servo. But given that ASG is normally deasserted during moves because there are steps coming in from the controller, how do you tell whether ASG is deasserted due to the steps coming in or deasserted because of a shutdown?

This is where “ASG-Position w/Measured Torque” comes in. (I’ll call it “ASG-MT” for convenience.) ASG-Position w/Measured Torque, superimposes a PWM signal on top of the normal ASG-Position signal while the axis is moving. (See the user manual if it is unclear what I mean by a PWM signal being superimposed on ASG. There are some diagrams that should help clarify.) This PWM allows a user to get a real-time measurement of the torque being used during motion, but that is not our main goal here. Rather, if you use ASG-MT and the servo shuts down during the move, the PWM signal will stop. So, assuming your controller can detect PWM, it can tell when the servo shuts down.

To summarize, if your controller is compatible with ASG-MT (i.e., it can detect the presence of the PWM carrier frequency, which can be set to 45 Hz or 482 Hz), you can get feedback as to when homing is successfully completed and you can immediately detect when the servo shuts at any time. (Note that the controller only needs to detect the presence or absence of the PWM carrier, not actually measure the duty cycle, for this to work. But, as a bonus, if your controller can measure the PWM duty cycle, you can also know how much torque you are using while cutting. This could indicate a dull bit or a feed rate that is too fast, etc.)

If your controller can’t detect PWM on the HLFB output, then you have to forego knowing that the servo has shut down in the middle of a move. Alternatively, you could use a different HLFB mode, like “Servo On” to tell you whether the servo is enabled or not enabled (i.e., disabled or shut down). Then when you home, you will not get a explicit signal for homing completion, so your homing process is a little different: To home an axis, you must always send a command long enough to home from the location on your axis most distant from the hardstop. Then, at the end of this move command, if Servo On is still asserted, you implicitly know homing was successful. This procedure still gives you the elegance of getting a precise and reliable home reference without a sensor, but homing will always take the amount of time it takes to home from the farthest position. So, in summary, if your controller can’t detect PWM, you have to decide, do you want shorter average homing time or do you want to know if an axis shuts down in the middle of a move.

(When you talked with Matt, maybe he was trying to make the point that you can’t use ASG if you also want to know when an axis shuts down in the middle of a move?)

As a side note, if you decide to use “Servo On” and give up the explicit “homing successful” signal, you could go back to the idea of “Automatic Homing” and just wait a set amount of time after enabling the servo for the homing to complete (i.e., the time it would take to home from the most distant point), and then if Servo On is still asserted, you know homing has completed successfully.

With regard to your question about whether to home every time you disable and re-enable, it depends: if the axis can move at all while disabled (this is pretty common), you would probably want to re-home after each re-enable. That said, in the User Seeks Home mode, even if you’ve set up ClearPath to home on every enable, you can “cancel” homing if you want to for some reason, by sending one step in each direction right after the re-enable. This is because, remember, from ClearPath’s perspective, in User Seeks Home mode, the re-enable just activates the hardstop detection algorithm. ClearPath then waits for you to send it toward the hardstop. Sending one step in each direction (first toward the hardstop) deactivates the hardstop detection algorithm and puts ClearPath in its normal operating mode.

I realize this is a lot of information to absorb. There are a lot of feedback and homing options in order to handle a wide variety of machines and applications. Hopefully, with this information here, the manual will be easier to understand. But if you need any help, please feel free to call us. We have a team of engineers, any of whom will be happy to help you figure out what is best for your application.

Best regards,
Trent

The lathe axes are finally moving and set up. Took forever to understand the really convoluted explanations in the manuals as to how to set up limit/home/shared sensors etc.
Anyway, finally sorted and it all works - homes and observes all soft limits as well.
The spindle, also a step/dir driven servo, is also working, but the RPM readout and setup also falls in the convoluted descriptions category...

In pncconf, the spindle setup page has all the usual setups - spindle gearing, motor steps/rev, max rpm, accel, etc.
It also has entry for the spindle encoder and requires this to be entered as 'Encoder lines'. The help file explains this as the number of lines on the encoder, NOT the number of edges seen by the system. My encoder is a 1024 line, 4096 edges, A and B channel, with Reference pulse channel as well.
So I enter 1024 in the Encoder Lines field. Pncconf uses this value in a data field - shows it as edges = 1024 X4 ( = 4096)
However, the RPM readout in response to an M03 S1000 shows 250rpm - nicely one quarter.

When I change the number of edges from 4096 to 1024 ( Note- NOT the number of lines - the number of edges!) then the RPM reads correctly - 1000rpm.
I verified that the spindle is actually at 1000rpm with a 'scope on the encoder index pulse - 16.6hz. If I leave pncconf to work out its own idea of number of edges, ie, lines X4, and change Encoder Lines to 256, the readout is also correct. What Gives???
This hack cannot remain - it will surely ruin any attempt at threading...
What is also confusing is that I understood that the RPM calc takes as sensor input the Encoder Ref pulse ( 1 pulse/rev), NOT the A or B channel edges. If true, then why does the encoder number of lines have any effect on RPM?

Not an easy road getting a simple lathe implemented!

The main pncconf spindle page shows the number of encoder counts per turn
(not lines) This is the value written to the ini file

If you popup the "Calculate Scale" menu. it uses encoder lines
(so it does the 4X for quadrature for you)

Thanks You - I am fully aware of that - perhaps my post was not clear, so I will try to be more explicit...

To re-iterate -
My Encoder is a 1024 LINE, ABI channel encoder, so 4096 edges.

In Pncconf setup>

• Spindle Motor section>
  - among parameters shown here (for my settings) are-
  Encoder scale = 4096 ( comes from the CALC SCALE Menu - is 1024 X4)
  Step Scale 8000
  Max Velocity = 2500rpm
  etc, etc

• This all comes from the CALCULATE SCALE Menu page which shows:
  Spindle Drive Motor Pulley/teeth = 80:80
  No Gear Ratios enabled/selected
  uStep Multiplier = 20
  motor steps/rev = 400
  etc, etc

• THEN the important bit:
  ENCODER SCALE
  ENCODER LINES PER REV = 1024 (X4)

( RED parameters are values I entered)

In the resultant INI file it shows ENCODER COUNT as 4096.

If I run L_CNC with this setup, the RPM UNDERREADS by 4X
If in the CALC SCALE Menu I set ENCODER LINES PER REV = 256 (X4) - ( ie, Encoder Scale is now 1024 in INI file)
Then the RPM reads correctly.


EDIT - Just to re-iterate as well - I verify actual RPM using an oscilloscope, looking at the encoder index pulse

That means your encoder has 256 lines or you are running the encoder counter
in up/down counter mode rather that quadrature counter mode.

You can verify this by looking an the encoder counts (with halmeter or hal how)
and rotating the spindle one turn by hand.