Probe Basic - ATC explanation?

I'm using PB and in the (mostly) final stages of building an ATC and could use some guidance.

Plenty of searching reveals there is a fairly common ATC scheme for LCNC which uses the carousel comp, but the one example of a Probe Basic ATC hal file snippet doesn't include anything about 'carousel.'

(hal section here) forum.linuxcnc.org/qtpyvcp/45150-probe-b...ton-functions#235254

I also see that there is a [PYTHON] section in the Probe Basic Config Conversion Doc which refers to python macros, as well as an [RS274NGC] section with M6-M26 remaps.

Despite my forum rating, I'm still very new at LCNC and confused about how the ATC function is implemented.  Is Probe Basic not using the carousel component and just doing some secret-sauce stuff behind the scenes with python?

If this is the case, how do I connect my hardware to Probe Basic through HAL?  I think I understand the ATC-in/out and pocket/index sensors, but I'm lost on connecting my stepper drive (for the carousel platter) to PB.  The one example appears to be using an on/off 'dumb' motor with a couple of relay outputs for CW/CCW.

I was halfway down the path of setting up a carousel.comp scheme when it dawned on me I might be wasting my time.

Anyone have a moment to spell it out for me?

Thanks,
Ralph
 

Its all handled via m6 remap and macros. No secret stuff, i set it up to be as easy to access and adjust for the users setup. You will find the macros M10 thru M26 and toolchange.ngc.

The one in the sim is setup to work with the simulation machine, but it should be enough to make some sense of what is happening. It's essentially just activating pins and looking for sensor input on input pins to move to the next step. Similar to a ladder logic but done in macro instead.

Hope that helps!! The best way to start is to make a flow chart of your existing atc setup including what IO is used to safety check each step and the following output command step etc.. then match it up to the macros. Should get you going!

Chris

Thanks for the encouragement Chris.

Problem is that I don't have an existing ATC setup...  Nothing to 'convert' if you get my drift.

I can work out a sequencing flow chart from other examples, but this has me stumped:

(from your hal example)
net atc-fwd                     <=  motion.digital-out-03
net atc-fwd                     =>  hm2_7i92.0.7i76.0.3.output-05
net atc-rev                     <=  motion.digital-out-04
net atc-rev                     =>  hm2_7i92.0.7i76.0.3.output-06

Since I don't have an existing ATC, I don't have a good idea how to connect a stepgen to the FWD and REV output signals.  If I had a DC motor with relays, it'd be cake.  Not so much for the stepper, nor do I understand where the speed & accel adjustments would be made.

Make sense?

In that regard you would need to make another axis in the ini config and use an axis command instead of index pulse counter. You could setup the move to be a math calculation output. Once calculated just use that newly calcd parameter in an axis move command. Probably other ways to do it, thats just off the top of my head. Either way adding it into the macro should be easy enough with a little thought. The rest i would imagine will be similar as far as output input etc. I would still be starting by creating a flowchart. If you dont have an atc yet then perhaps it would be easiest to make the atc to match the control. It is how most industrial machines are controlled verse an axis for the carousel. Very simple and easy to do. Just use a geneva wheel. It will make the alignment pretty fool proof and increase process reliability.

Lcvette wrote:

In that regard you would need to make another axis in the ini config and use an axis command instead of index pulse counter.
 
 

My ATC is complete, hardware-wise.  It uses a stepper and a 5:1 reducer to drive the platter.

So you're suggesting use a B- or C-axis scheme to drive the ATC... so that pocket N = B180 (or similar)?

You could setup the move to be a math calculation output. Once calculated just use that newly calcd parameter in an axis move command.

I think you've overestimated my experience...  I'm still at the copy-paste-tweak stage of creating an LCNC config.  I could easily duplicate my A-axis settings for an ATC axis, but editing a macro to do axis position to pocket number is a little beyond me without a concrete example.

All the examples I've found of ATC logic are based on the carousel comp - no axis involved.

Do you know of any examples of this configuration?

the first thing is to read through the macros and envision what is happening to get an understanding of the flow of things. next is to draw from that new understanding how to incorporate it with your hardware design. in its current flow the atc macros are already calculating how many positions to move and in which direction is the shortest route. it is accomplishing this by reading the pocket index pulses for its rotation, but in your situation you would instead change the motion from reading index pulses to commanding a direction and amount of rotation. i would simply remove from the macro the motion trigger but would still use an index pulse to count. i would then use the calculated direction to command the motion direction for your stepper output move and the number of index pulses (pocket count to move) to multiply a division of your pocket count from 360. in other words if its a 10 pocket platter each pocket change will require 36 degrees of rotation. if the command would need 5 pockets in the ccw direction to move to the next tool called then it would be 5 x 36 = 180deg ccw command and you would simply write this equation into the macro and have it output in an equation. G1 F10(desired speed) A(calculated parameter) -180.00, this would looik like G1F10A-180.00 and is output like a normal gcode command to that axis. much the same as the z move occurs for raising and lowering the head into the desired position to load or unload the tool from the spindle. don't make it more difficult than it is, simply write out your flowchart for desired function and make notes of what you need to happen at the desired points in the flow of function and then determine how to implement it in the macro. you can learn the various functions and equations available for macros in the RS274 manual here:

tsapps.nist.gov/publication/get_pdf.cfm?pub_id=823374

i would use an index pulse counter for reporting that the platter is in fact at the commanded location as a safety check before sending to into the spindle as atc crashes can be quite destructive.

if it were me i would abandon relying solely on the stepper and gear reduction to position the platter and switch the design to a geneva wheel, this ensures that your platter rotation will always be aligned and gives a large degree of error acceptability while maintaining correct platter to spindle alignment. this method is proven. i have seen many crashes with atc designs solely relying on the stepper to correctly position the platter as you are reliant on a rotational home position to set the starting point for everything. the stepper can loose steps causing a misalignment and you have to add a "range" to the index pulse to avoid the sensor not reporting which means that it isn't going to be correctly aligned and repeatable. its just an inferior design in my opinion that will open you up to process reliability issues going forward. if this is just a hobby then it may be ok, but i would not use that method for anything i wanted to rely on day in and day out. just my opinion though.

Thanks for the high-level explanation.  This is obvously going to require some thought on my end.

I think I may be using the carousel component and editing the remap once I/we sort out the carousel homing issue.