Probe Basic - ATC sim parameter question

I'm most interested in using a non linuxcnc axis output to move a stepper motor for carousel motion, I'm fine with the rest of the macros being required and it being somewhat hybridized.

for the load tool not in carousel, I will be doing some extensive rewrites on the atc macros very soon which is what prompts my question, I would like to try and do both the "all macro" and "carousel comp/macro hybrid" edits in parallel while my mind will be saturated with the knowledge...lol I'm sure you can appreciate the benefit in that, its a good bit to keep track of and much easier when its all fresh in the brain.

The new data Base tool table feature is going to be a game changer for probe basic as it will add quite a bit of awesome functionality for those using atc's. the ability to have tool parameters stored and be accessible in the DB to be used in macros will make all the difference in what can be automated and simplified.

I am pretty excited to start work on it, just shoring up a few things in the shop before I can get to it. if you want to share what you have going on that would be a great start I'm sure!

Thanks Spumco!

Chris

Chris,

I'll fire up the mill later tonight and get a config dump for you.  And yes, I'm using a step/dir non-axis output to drive the ATC stepper.

Once you've had a look - it's complicated - I'll walk you through any of the atc-specific stuff that isn't clear.

Agree - the tool DB would be nice.  There are a number of features I'd really like to have that could be automated via a DB value:

• lathe front tool/back-tool backplot flips
• lathe main/sub spindle backplot flips
• multiple offsets for a multi-function tool like Siemens does
• Max RPM
• "Big" or 'Heavy" tools for carousels (nothing allowed next to oversized tools, or slow down carousel for high inertia)

yup exactly to the tool DB, it will be a game changer for sure! thanks in advance for the files and assistance!

Chris

Config attached.

The basic stuff you want for the ATC is in 02_atc.hal (shockingly ).

ATC control scheme basics:

• HAL
  • Carousel.comp set to INDEX mode
    • Requires 1 sensor per pocket, plus 1 per-rev sensor (home)
  • Spare Mesa stepgen (not an axis/joint) set to velocity mode
  • carousel.comp motor-vel pin connected to stepgen velocity command
  • Pocket request (for new tools) is connected to carousel.comp via motion.analog-out
  • Carousel enable pin connected to motion.digital-out
• INI
  • All stepgen & carousel.comp 'settings' are in a separate INI section
  • align-dc and decel-time pins are used for carousel's fine-alignment feature (carousel final-approach to sensor from same direction regardless of starting CW or CCW)
  • Some settings present in the attached INI are not needed, but are legacy/leftovers from when I was trying to use carousel.comp in COUNTS mode.  I think carousel.N.scale is one of these.
• Subroutines
  • All the subroutines are pretty well commented, but m10.ngc is the primary ATC rotation management sub
    • Instead of the original PB M10->M11/M12 logic, I simply pass the desired destination pocket from toolchange.ngc to m10.ngc
    • Inside m10 is an M68 E0 Q#<P> line, followed by an M64 Pn (carousel enable)
    • That's all there is to get carousel to drive the platter to the correct pocket.
  • Remaining logic in m10.ngc is strictly used to drive the PB screen widget
  • M11/M12 have been repurposed for using the built-in carousel jogging and keeping it synch'ed with the screen widget
    • I think this could be done better, but it's working and I had other fires to put out.  There's no verification of synch between carousel and the screen widget, nor any synch error handling.
  • M13 is for homing the carousel.  Again, the sub(s) use carousel.comp's built-in homing logic - no math required.

That's about it for the ATC stuff.  Lots of other things in the config, but those are just for all the complications I've added.

Let me know if you've got questions after digesting it for a bit.

-S

awesome, just downloaded and gonna take a look! thanks spumco, I am sure i will have a few questions.. lol

Minor clarification on my earlier post

I don't think it matters when carousel.comp is in INDEX mode, but the config above is for a step/dir motor (stepper in my case) run through a 5:1 reducer.

The basic connections should work for a geneva wheel mechanism, too, but I just wanted everyone to be aware that the carousel.comp parameters/settings will need to be adjusted for speed and the fine alignment speed/time.

Chris - if you're contemplating a GUI-facing ATC interface with a 'settings' page to pass values through to carousel.comp (like the probe page does), you'll need to:

• Include ALL the carousel.comp pins/parameters for all the encoding types, or
• Lock it down to INDEX mode, and the user is required to have both sensors

for my specific use case I think I would like to use the home switch to be able to home to the center of a pin that is inline with the pocket center (kind of like probing ridge center) and then use a preset amount of step counts per pocket based on the number of pockets in the carousel to divide it into that many moves for a full revolution of the platter. I am using a 2 pin geneva wheel so 1/2 rotation is one pocket. I would like to confine all of the hal into one file if possible to make implementation as easy as possible and have some options to be able to use the index method as well. kind of a one setup page allows all types and each type has a unique hal file that can be called from the ini. make it as modular and easy to use/setup as possible. ATC seems to be one of those things that scares most folks because of its complexity. I think having it made easier would be a good thing.

Lcvette wrote:

for my specific use case I think I would like to use the home switch to be able to home to the center of a pin that is inline with the pocket center (kind of like probing ridge center) and then use a preset amount of step counts per pocket based on the number of pockets in the carousel to divide it into that many moves for a full revolution of the platter. I am using a 2 pin geneva wheel so 1/2 rotation is one pocket. I would like to confine all of the hal into one file if possible to make implementation as easy as possible and have some options to be able to use the index method as well. kind of a one setup page allows all types and each type has a unique hal file that can be called from the ini. make it as modular and easy to use/setup as possible. ATC seems to be one of those things that scares most folks because of its complexity. I think having it made easier would be a good thing.
 

A word of caution on using a pin for homing...

When I first built my ATC, I used stainless pins with proximity sensors for both home and pocket flags.  After struggling with pocket alignment, I finally realized that round pins weren't really suitable as flags.  At least not with the geometry I used, where the pin was vertical (up from the platter) and the proxy was pointed at the pin circumference.

When the round pin went past the proxy, the slight variation in sensing distance (due to pin radius) was magnified further out at the pockets.  Result was inconsistent pocket alignment.  And slight changes in rotational speed made a huge difference in pocket alignment consistency.

I wound up ditching the pins and proxys and installed some optical fork sensors with 3D printed flags.  Despite the circular motion, since the flags have straight edges they trigger the sensors MUCH more consistently - and at any speed.


Regarding your plans for incorporating a GUI-based ATC config, I quite like that idea.  But I think you might consider just sticking with INDEX mode for carousel, and not trying to offer both INDEX and COUNTS modes.

In your case, you don't need to specify a preset number of step counts if you're using INDEX mode. In that mode, carousel.comp uses a velocity-mode stepgen and the motor is 'dumb'.  Carousel just looks for the pocket sensor and stops rotating the motor (and does a second fine-alignment if you've opted for that feature).

For a geneva wheel, a slight motor overshoot is a non-issue, and because carousel.comp is using per-pocket sensors, there's no cumulative error stacking up over multiple pockets.

On a direct-drive (with or without reducer) ATC like mine, overshoot is a problem... but the fine-alignment feature takes care of that. Again, no cumulative error.

For a slightly more complicated mechanical & electrical installation (need pocket sensors), it's much easier than COUNTS mode to configure.  And potentially more reliable, especially if someone chooses to use an open-loop stepper.

An open loop stepper in INDEX mode is fine - if the motor stalls, carousel.comp won't set the 'ready' pin high and a macro waiting for that pin will time out and throw an error.  In COUNTS mode, neither carousel.comp or LCNC have any idea that the open-loop stepper stalled and will probably crash the ATC.

I think you'll find that regardless of what kind of ATC a potential Probe Basic user has - or is building - if you simply set some ground rules it'd be easier for you and the end users in the long run:

• MOTORS
  • On/off controled AC or DC motor, or
  • Step/dir stepper or servo
• ATC Mechanism
  • Direct drive (reducer, belt, or direct-to-motor)
  • Geneva wheel
  • Worm drive (?)
• ATC Sensors
  • One home sensor
  • One per-pocket sensor
• ATC Movement
  • One retract sensor
  • One forward sensor
  • One retract output (valve or motor or something)
  • One forward output
• Drawbar
  • One drawbar engaged sensor
  • One drawbar output

Maybe something like that as a baseline config?

To clarify my comments on pocket sensors:

This didn't work (pins):
 

This works great (optical w/flags)
 

yeah that is not a good orientation method trying to pickup the curved body.  you would probe the top flat of the pin to give it a more square edge to have a strongly defined edge to trigger.  or better use a wedge/pie shaped block that gave the proximity sensor a flat square edge to sense.  this is how i have those setup on my machine as home and limit switches and they are actually quite repeatable in the sub 0.001" as seen in the video:

www.instagram.com/p/Bj3QarigT4q/?utm_sou...gsh=MzRlODBiNWFlZA==


I agree with your assessment that it is easier to keep up with things if you give people a narrow lane, but i did that with the current implementation and it was a bit short sighted i think (you are proof of that).  I would like to find an easy way to setup everything in a more modular way maybe.  i think your outline is a good starting point for sure! Thanks for taking the time to write it out!

Chris