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

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

It's an INI setting "VOLATILE_HOME"

linuxcnc.org/docs/2.8/html/config/ini-co...t__lt_num_gt_section

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.