Probe Basic - ATC sim parameter question

First -  because I don't have the skill to create an ATC-as-axis configuration.  I have the config example from the dual-ATC ZX45, but I'm overwhelmed by the complexity of what the guy created.  None of your original ngc code remains - it's crazy what he cooked up.  My brain simply shut down after hours of trying to understand it all.

Second, because I don't want to build a geneva drive and get rid of my German-made planetary reducer.  With this hardware, a closed-loop stepper, and the recent enhancements to carousel.comp it's dead-nuts accurate and extremely smooth and controllable.

• No chance of getting off-pocket without an alarm (and e-stop in my case)
  • If you don't trust a closed-loop stepper for the ATC, you shouldn't trust it for an XYZ axis motor
• Very easy to slow it down for testing, and then speed it up for production use.
• Does not require pocket sensors when in 'counts' mode - a simple index pin/flag is all it needs.
• Does not go clunk-clunk-clunk and shake the enclosure 
  

The problem - so far - is that I have to send carousel.comp tool/pocket numbers via M68.  Whereas the fundamental Probe Basic scheme is to control a geneva drive with 'steps' from a known current position (pocket).

Basically, carousel.comp needs a destination, and PB works on increments; I have to reconcile the two.

I could end this struggle tomorrow (or in a couple days) if I could accept a maximum of 18 tools in the tool table like really old-school Fanuc-based mills (Fadal, etc).  That setup would be super-simple.  I'd dump all the existing PB logic and just let carousel.comp manage where to go.  You get T1 through T18 and that's it.  Manage your CAM so it only outputs 1-18, and manually edit the tool table.

But I don't really want that.

If someone wants to hand me a working ATC-as-axis config for a single tool changer I'd jump on it.  I'd also jump on a working PB + carousel config.

this could be done with subroutines, you just need to have a calculator to convert the pocket count into rotational motion distance. and then you would simply remove any feedback, not exactly my favorite way to do it, but it will work.

also my geneva wheel is very smooth, it is a two pin type and is very fast and is used in conjunction with a gear reducing motor drive albeit 3ph ac motor type.

just like i was explaining how to assign parameters from probe basic you could easily assign parameters to carousel motion via stepper output if using it as an axis.
if that is something you would prefer i don't mind helping you sort it as im sure many others will go the axis driven atc carousel route for simplicity.

That's a generous offer to help, thanks.

Whichever control method is used (axis vs. carousel.comp), the part I haven't internalized is how to overcome the limitation of tool = pocket for a non-random toolchanger.

I can see that you've created an array of persistent params in toolchange.ngc:

#1 = #5190
#2 = #5191
etc.

And the file comment indicates that #5190... represent tool numbers, and #1... represent pocket numbers.

toolchange.ngc starts off setting some parameters as above.  Then it calls M10, which is the 'intermediate' macro to calculate best direction.

M10, in turn, calls M13 (homing) and then either M11(ccw) or M12(cw).  Those are the macros which actually move the carousel.

But I'm still unclear (my limitation, not due to the code) on how the tool numbers are assigned to the parameters which represent pockets.  Does this happen at the end of the toolchange.ngc macro where you reverse the param writing?

#5190 = #1
#5191 = #2
etc.

I think I'm going to have to write out the toolchange.ngc sequence in English; maybe that'll help me.


Related thought...

M10, M11, M12, and M13 can all be abandoned if carousel.comp is used, since carousel takes care of all motion:

M10 P[#<open_pocket>] (which then calls M13, M11 and/or M12) is changed to 

M68 En Q#<open_pocket> (sets destination pocket in carousel)
M64 Pn (enables carousel and starts motion)

Same thing for M10 P#<next_pocket>; all the M10, M11, M12, M13 can go away.

The only reason a separate homing macro would be needed is if the ATC widget needs to be moved to pocket 1 since carousel automatically homes itself to pocket 1 on first enable and sets carousel.N.homed = true for error checking.

Further thinking...

If I'm going to spend time working out a customized Probe Basic ATC config, it might be more helpful to future users to at least try and use carousel.comp.  Using that scheme is much more hardware agnostic than ATC-as-axis or the existing PB ATC sim coding, and it would be easier to create a config accompanied by a fairly simple matrix that aids users in matching their hardware to config options.

• ATC-as-axis cannot use a Geneva drive (well, maybe it can with some weird steps/rev settings)
• Existing sim cannot use a non-Geneva drive (without modification)
• Carousel.comp can use
  • Geneva drive with AC or DC motor and relays
  • Geneva drive with stepper or servo
  • Non-geneva drive (reducer, belt, direct) with stepper or servo
  • Non-geneva drive with AC or DC motor and relays
  • Ratchet & pawl type that reverses against a stop
  • Seven different pocket sensing schemes - from grey encoders to a single index

Lcvette wrote:

also my geneva wheel is very smooth, it is a two pin type and is very fast and is used in conjunction with a gear reducing motor drive albeit 3ph ac motor type.


 

I was jokingly referring to geneva drives I've seen on beat-up machines.  I'm aware that they can be nice, precise mechanisms and I'm sure what you've got is quite nice.  No offense intended.

But they can also act like Rube Goldberg things when they're worn out or improperly built and almost comical to watch them at work.

The only actual downside I know of with a geneva mechanism is the instant accel and decel (jerk) when the pins engage the slots - but I'm not a mechanical engineer and can't quantify or evaluate the effects of that quirk.

toolchange.ngc starts off setting some parameters as above.  Then it calls M10, which is the 'intermediate' macro to calculate best direction.

M10, in turn, calls M13 (homing) and then either M11(ccw) or M12(cw).  Those are the macros which actually move the carousel.

But I'm still unclear (my limitation, not due to the code) on how the tool numbers are assigned to the parameters which represent pockets.  Does this happen at the end of the toolchange.ngc macro where you reverse the param writing?

#5190 = #1
#5191 = #2
etc.

M13 happens at startup only, and must be done if your carousel has basic sensors for home and index... ie it needs to identify the home pocket so it can then count from there and track what pocket it is on going forward. after initial homing it is just like any axis, it knows where it is until restart.

when you store a tool from the spindle to the carousel, it runs through the predefined numbered parameters in the var file #5190 - #5201 looking for the first unoccupied parameter, when it finds that open parameter it proceeds to command movement to that associated pocket.  once the toolchange sequence has completed successfully it writes the tool number to that var file parameter for future use.

this is run in the random mode, so as i mentioned previously, if you remove a tool from pocket 3, and then call a tool located in pocket 5, when it goes to store that tool again it will store it in pocket 3 instead of pocket 5 which it previously occupied.  the tool number is rewritten in the newly occupied pocket.

that make more sense?

as for the compatibility, you could run macros the same as carousel.comp, it can run a stepper as a non axis, but it needs to have a way to control it as simply predefined speed and then direction would be as simple as changing which output is triggered.switched pulse generators are quite cheap and easy to wire.  using macros just requires some imagination, but can do everything the comp does including using analog and digital IO, thats super easy.

Related thought...

M10, M11, M12, and M13 can all be abandoned if carousel.comp is used, since carousel takes care of all motion:

M10 P[#<open_pocket>] (which then calls M13, M11 and/or M12) is changed to 

M68 En Q#<open_pocket> (sets destination pocket in carousel)
M64 Pn (enables carousel and starts motion)

homing cannot be abandoned unless you have some way to track absolute position very expensive for those type sensors or encoders and adds much more complexity.  abandoning a few macros hardly seems like its any sort of a benefit.  using comp you also need to go through all of probe basics other subroutines and ensure you are not overlapping any of the limited use M68 E# positions or there will be some conflicts.

M10 can be made to call M13 but it was safer in my opinion to require homing and also was required to populate the visual graphic in probe basic with the pockets and tool numbers that are currently stored.

M10 will only call M11 or M12 depending on which direction it deems the shortest path to the next pocket.  

if carousel comp drives a stepper with predefined position that is about the only benefit of it that i could see is it wouldn't need an axis.  how is it driving the stepper by the way? i have not looked.

 

Yep, tons.  Major help.

In addition to using absolute encoders with/without a pocket strobe, carousel can now home to a single index pin.  Andy's also added a slow search feature for both homing and pocket sensors; carousel moves to the sensor flag, backs off, and then does a slow search like normal axis homing.  It also goes past the pin when rotating in the opposite direction - the slow search is always in the same direction for accuracy even with bidirectional ATCs.

In my case I have two proxys (one above the other), with pins/flags mounted on the tool forks. One pin is longer than the others and triggers the index proxy. Carousel homes to the long pin, and after that reads the other proxy for pocket sensors.

Carousel drives steppers/servos using a software stepgen - no joint/axis.  And the stepgen can be in velocity mode or position mode.

In velocity mode and  it acts just like any other 'dumb' motor and uses the pocket pins or an encoder.  This would be suitable if you had a geneva wheel or some other physical mechanism that automatically aligns the pockets, or an encoder.

In stepgen position mode, and carousel 'counts' mode, carousel will move the motor a certain number of steps per pocket as you would expect.  There is an initial homing sequence on first enable and after that it simply moves the right number of steps to a particular pocket based on number of pockets and the pocket:steps ratio set in carousel.N.scale.

Carousel counts mode can use pocket pins with slow search (as a verification), or it can use the single index (homing) pin and from then on it needs no further feedback.  This last would be super-dodgy on an open-loop stepper, but for a servo or closed-loop with appropriate alarm feedback it works great.

Of course, in all modes the stepgen speed /accel is adjustable; that's been really nice for testing, BTW.  Speed is (I think) adjustable for all motor and carousel modes except for AC/DC motors with on/off relays.  Any motor using a stepgen or a pwmgen can be adjusted, both in the stepgen/pwmgen and inside the carousel.comp settings.

I don't think a relay-type motor arrangement can effectively use the slow-search function, however. But if you're using a geneva wheel and dumb motor, you don't need the pin search.

Something occurred to me right after Andy added the slow-search is that uneven pocket spacing is no longer a problem.  In index mode carousel will simply rotate (any motor type in velocity mode) and count the pocket sensors, then do a slow search back to the right pocket flag.  If a user is unable to fabricate a disc/carousel with precise pocket spacing carousel.comp doesn't care as long as the pocket flags are aligned to the tool forks.

You could literally eyeball the pocket locations as long as they're all at the same radius. No need for a big mill or a complicated indexing jig to build the disc - a compass to lay out the pocket hole radius and a hand drill would be good enough.

An edge-case example would be to build a carousel disc with a couple of dedicated wider-spaced pockets for oversize tools. If you know you're going to have a 4" face mill in the ATC all the time you can have a single pocket (or more) with spacing just wide enough for that tool.  The rest of the pockets could be spaced for 2" tools.  You get the benefit of increased tool density (more pockets) with no need to empty the leading and trailing pockets to accomodate a face mill, saw, or boring head.

Andy's done a great job updating the comp MAN entry with the new modes & features; the explanations there are probably better than I can convey.

In the standard PB subroutines, M10 does call M13, as do M11 and M12.

m10.ngc:
O110 if [#5171 NE 1]
     M13
O110 endif

m11.ngc:
O100 if [#5171 NE 1]
    (print, atc not homed, homing)
    M13
O100 endif

EDIT - not going to mess up the formatting above, but meant to write:

In motor velocity mode and carousel index mode it acts just like any other 'dumb' motor and uses the pocket pin sensors.  In motor velocity mode and carousel grey/binary/bcd mode it uses the encoder feedback along with optional pocket strobes.

Getting back to the parameters discussion/questions...

M6 (toolchange.ngc) does a few checks/calcs:

• O100
  • checks all pockets for putting spindle tool away, and writes #<next_pocket> = #15
  • checks if next pocket is empty, and writes #<open_pocket> = #15
  • Decrements #15 to do both checks through the whole ATC
• O120
  • If, after the above calcs are done, #<next_pocket> = 0, aborts as the desired tool isn't in the ATC
• O180
  • If tool in spindle is > 0
    • If no open pocket, abort
    • If open pocket, move carousel to an open pocket using M10 P[#<open_pocket>] (P being the argspec pass-through)
    • Put tool in spindle away in open pocket
• O200
  • If selected tool > 0
    • Move carousel to selected tool pocket using M10 P[#<next_pocket>
      Install the tool in spindle
  • Update #25 to = #<next_pocket>
  • Empty the parameter representing the now-empty pocket
  • Update tool in spindle

The two keys I'm looking at here are the calculated & updated #<open_pocket> and #<next_pocket>.  Those values are passed to M10 through the remap argspec:

#<steps> = [#5170 - #<p>]  (#5170 representing the current pocket number)

for use in calculating how many steps to move the carousel.  M10 then goes on to use the calculated steps to figure out shortest-path direction, and passes that on to M11 or M12 which actually move the correct number of steps.

It just occurred to me that if I get rid of the 'steps' calculation that the direct pocket number can be passed directly to carousel.N.pocket-number through motion.analog-out-nn.  Such as:

o<m10> sub
M68 En Q#<P>  (sets destination pocket)
M64 Pn  (starts carousel motion)

This should result in carousel moving to the correct pocket, whether we want an open pocket (to put a tool away), or the next pocket (to load the desired new tool).

All the remaining shortest-path calcs in M10, and steps-to-move math in M11 or M12, would be superfluous for carousel.comp.

If this works the only remaining trick will be to synchronize the atc widget, since that relies on steps, not an absolute pocket number.

So... brain working overtime... I keep the shortest-path calcs and steps to move in M10 & M11/M12, but those are only used for the widget.

Carousel.comp gets told an absolute pocket number
ATC widget gets told steps to move (which should work out to the same pocket)

This seems too easy to work...

Yep, this will work.  Testing is promising, just have to work out why the carousel isn't turning on/off at the right times.

Lcvette - question:

Parameter #5189 is used in a number of the toolchange macros:

(toolchange.ngc)
O110 if [#[5189 + #15] EQ #100]

(m11.ngc)
o130 while [#1 LT 12]
    #1 = [#1+1]
    #2 = #[5189+#1]

And a few other places.

But the G-code section of the LCNC manual indicates #5189 is the G30 home for axis-W:

5181-5189 - "G30" Home for X, Y, Z, A, B, C, U, V & W. Persistent.

Was #5189 selected as a persistent parameter that was unlikely to ever be needed, or some other reason?

Or am I misunderstanding something?

yes #5189 was just a numbered variable used to store data in the macro, i just went in and change it to #5190 and made the pocket numbers 5191-5202, and tested and saw no ill effects (did not expect too) and the numbering is more fitting as it matches up to the actual pocket numbers. those numbers used are user definable and in many cases for larger carousels, the user will need to find new persistent variable spots for more carousel pockets. this was not my making but the atc remap subroutines from the forum, was just lucky i never had a G30 offset stored for W axis... good catch! keep going its nice having more eyes finding things at the scrutiny level you are employing!