ATC Project - Debug phase

Setting it up an ATC as an axis should be too difficult. It's just gcode for moving the axis. You would likely use the axis in position mode and just send ich to the correct angle. Individual offsets may be required. If I recall correctly, the tool change motion in probe basic is entirely based on macros:
github.com/kcjengr/probe_basic/tree/mast...be_basic/subroutines
This will take some digging though.

On the issue of speed. Given that carousel runs within the servo-thread (so usually at around 1kHz) and the tools should remain in their pockets during rotation (), I had not expected such a high speed anyways. To me the challenge is therefore rather more the indexing from both sides.

To the issue at hand and in correlation to my own thread:
What spumco outlines is about what I expected. I have no experience with C (and it'sdreadful shorthand operators), but from how I understand the state switch in the actual comp, the following steps would be required:
-Add additional pins for a slow speed (e.g. lowfwddc or a multiplier for the forward speed)
-in state 11: modify so that when sense(0) and sense(1) are triggered (i.e. homed) it is considered pre-home, then add a state 12 for a precision approach of an index (i.e. reverse until !(sense(0) &&sense(1)) and repeat forward motion with motor_vel=lowfwddc
-for regular pocket approach after homing: This is a bit less clear to me at the moment. I would expect the some idea to apply: Use regular motion towards index (aka full speed ahead), if current_position=mod_pocket: set flag: preposition
Change to state 12 for precision approach while considering the previous direction of travel (this may require another variable): if motor_fwd=1 --> reverse, slowly approach index; if motor_rev=1 --> deliberately overshoot index, then approach slowly

Doesn't sound too bad - did I miss something?

GuiHue - Thanks for the confirmation and comments.

I was able to convert my ATC motor to an A-axis this morning and everything seems to work OK (homing & positioning via MDI).  Nice and smooth - no ka-CHUNK, ka-CHUNK of a geneva mechanism.

And yes, the tool change motions in PB are done via .ngc files and remaps.

I could really use some help with the toolchange gcode, however.  I've been unable to find any examples of anything similar; some forum discussions, but no sample files or file snippets in a thread.

The angle is easy - I've got 18 pockets, so each pocket is +/- 20 degrees.  And there are plenty of examples on how to control the other motions (carousel in/out, Z up/down, clamp/unclamp), but I'm not remotely clear on how to:

• Assign a tool number to a pocket
• Check the current position (or tool, then infer the pocket #)
• Calculate the distance to the desired pocket in either direction
• Compare which direction is shortest
• Select shortest path
• Command move via shortest path
• Update current position & tool number
• Make sure the GUI responds to everything appropriately

Maybe someone has done something like this, or remembers a forum discussion I've been unable to find thus far?

Thx,
Ralph

OMG this is turning in to a really dumb build/failure diary...

So the new plan is to manage the ATC like a rack-style changer.  Just found a great example of a rack changer (thanks GuiHue!) and need to translate the X/Y/Z movements in to a B-axis command.

Just as important: plopes9000 (of the twin-ATC, 5-axis TCP RF45 fame) has confirmed that he's using a rack-style, V&W-axes scheme for his awesome ATCs.

Manual testing shows the carousel behaves nicely as an axis.  Big closed-loop stepper means it's not painfully slow, and I get the benefit of an alarm if steps are missed (one less thing to crashy-crashy).

Question - can I define the axis as U/V/W even if I don't have an A/B/C axis?  I've disabled my 4th/A-axis at the moment (actually, robbed the stepper off of it), but the ATC is defined as "A" for initial testing.  Would like to set it up as "W" eventually.

Comments always welcome, of course.

Thanks for still giving this some consideration Andy.

The pin/flag will completely overshoot the proxy at higher speeds. At lower speeds it will stop at different places in relation to the proxy's trigger field.  Not to say it changes every time; rather a change in speed means a change in resting location.

Same-same both directions. Overshoot in the other direction as well as varying rest points after the trigger-decel sequence.

I'm not fed up with carousel, but I simply don't see how it can be made to work reliably without major changes.  If we step back and think about a carousel - or any tool changer - it is fundamentally a positioning device.  Precise positions has to be accomplished either mechanically or via position-mode control.  Geneva wheels, Chiron baskets, and ratchet-pawl mechanisms do it mechanically.  Side-wheel & arm ATC's do it with a combo (servo the drum, mechanical arm).  A velocity mode motor coupled to a non-mechanically indexed device with variable inertia doesn't result in precise indexing.

Adding a latch-velocity sounds promising, but it seems like a bit of gamble - what happens if the flag goes past the sensor?  It's the same problem as with LCNC's homing sequence.

If you want to make carousel more universal, then adding a position-control mode would be the ticket.  If the user chose 'mode X', then that would expose pins to set steps/rev.  Degrees per pocket would be calculated by carousel.  Essentially, it would take the math & direction logic out of the .ngc file and move it backstage in carousel.

I'm not wedded to the tool-changer-as-axis, but I'm moving down that road now.  Finding an example has been frustrating, but I stumbled across one last night that looks promising.  The issue with converting a true rack-style ngc file is that there are a lot of moves that don't equate to a position-carousel, nor is there any pocket-to-position math for me to steal.

If you want to fiddle with a position-mode carousel test, I'm completely happy to have a go at testing anything you throw my way.

Expanding on my earlier suggestion for a position-mode carousel... looks like simple_tp.comp would be the ticket.  Someone smart could edit carousel to output a position value (based on number of pockets) and enable-out signal, which is then sent to simple_tp, and then to the stepgen position command.

 

Tommy - there are a bunch of threads with steppers & carousel ATC's.  Many dozens... I've read them all over the past week.  All of them, hours and hours.  'carousel' 'umbrella' 'ATC' 'toolchanger' 'tool-changer' etc.

But they all are for Geneva wheels, ratchet-and-pawl turrets, or they don't have any config details or descriptions on how the toolchange.ncg handles the positioning & direction calcs.

There is exactly ONE post, from a user who only made one post ever, with a config for positioning-mode carousel changer.  He did not use carousel.comp - he did it as a B-axis.  Thankfully, he linked to his github page and it's still  alive with a readable hal/ini/m6.ngc config.

needle_in_a_haystack

tommylight wrote:

See if there is anything useful, and please do not say no, just had to go through 20 pages of google results, at 50 results per page!
 

Yes!

It's a new enough thread that he hasn't reported back about success yet.  I suspect he got to the point I did - homing, jogging, and calling pockets up - but hasn't reported back.

Actually, it may be promising.  Reading Andy's description of his edits and some new pins/functions is interesting. 

This new mode requires that the number of counts (or steps) between pockets is set in the carousel.N.scale pin and the width (in counts) of the pockets should be set in the "carousel.N.width"

This is, I think, what I was inartfully describing in my earlier posts - controlling a stepper (or servo) in position mode and not velocity.  I'm going to try and download the comp and see if it works.

Thanks Tommy!