Carousel Toolchanger

Hi folks.

Have anyone set up a carousel toolchanger driven by a 0-10V controlled servo-motor with encoder feedback?

I have a spare servo-axis on my machine and I want to use this to position the tool carousel.

I think I have the necessary signals (tool number in spindle, requested tool number, tool change request, etc.) to perform all the logic tasks in Classicladder, so I hope I don’t need to remap the M6 command.

Hi Andy.

Thank you for your reply.

I have read a bit about the carousel-component and it looks very good, but if I understand it correctly I can’t use it to drive an axis? My tool-carousel is configured as the C-axis on my machine.

But maybe I have misunderstood something?

Hawk83 wrote:

Hi Andy.

Thank you for your reply.

I have read a bit about the carousel-component and it looks very good, but if I understand it correctly I can’t use it to drive an axis? My tool-carousel is configured as the C-axis on my machine.

But maybe I have misunderstood something?

Correct.

Carousel.comp can drive (via other HAL components) motors, but not a named axis/joint.

Theoretically one could somehow connect carousel.comp's output to a named-axis' inputs, but LCNC would get 'confused' and not be able to keep track of the axis actual position.  Carousel would be moving the axis outside of the trajectory planner's knowledge.

So you generally either choose to use carousel.comp to manage the ATC/turret positioning, or you use an axis.  Both require some additional 'thing' to choreograph the full  tool change sequence.  That thing can be .ngc subroutines, or Classic Ladder, or some murky (to me) python programming.

Andy advised me some time ago to use carousel.comp instead of an unused axis to control my ATC if possible.  His point was that it's rarely necessary to have the ATC motion synchronized (at the same time) with other axis/joints.  You move the head up, then you do something else, then the ATC rotates, etc.  Tool changes tend to be sequential steps, not lots of concurrent motion.

There are plenty of successful examples of ATC's being implemented as an axis.  But without discussing with the author I can't think of a reason why ATC-as-axis is preferred over carousel.comp.  Maybe being able to have finer control (hardware dependent) of the actual motion (accel, velocity, etc.)?

[bonus]
Now that I think about it, just about anything is possible in LCNC.  It might be possible to use carousel to drive a named axis via the .ngc subroutines, but that seems like a horrible Rube Goldberg scheme.  I can't think of a scenario where that double-layer of complexity would be the most efficient configuration.

Hi.

Thank you for your reply.

The reason that I want to use an axis for controlling the tool-carousel is that I am retrofitting an existing machine and the axes are already wired and ready to go.

I have just started remapping the M6-command, but there are so many things about this that I don't understand and I haven't found a source that explains remapping in simple words and in a more step-by-step manner. I understand that almost every machine is different and that it is almost impossible to make a setup-description that fits every machine. But I miss a document that breaks the remap-topic a bit more into easily understandable bits.

I have read some of the LinuxCNC documentation on remapping, and although this is very good I am almost left with more questions than when I started because of the complexity.

Hawk83 wrote:

The reason that I want to use an axis for controlling the tool-carousel is that I am retrofitting an existing machine and the axes are already wired and ready to go.


 

I think there may be a disconnect between your understanding of the term "axis" and what "axis" means in LCNC.  Understandable, of course, as learning to speak LCNC is one of the stumbling points for new users (myself included).

In general terms, you (I suspect) think of an "axis" as a stepper or servo motor which is connected to some motion hardware (slide, table, rotary actuator, etc.).

In LCNC terms, "axis" can of course refer to the whole drive-motor-slide assembly... but for the purposes of configuring how LCNC controls motion, "axis" refers to a mechanical component set which produces linear or rotary motion that interacts with the motion interpreter (the part of LCNC which plans/executes motion).

linuxcnc.org/docs/devel/html/gcode/machining-center.html#_axes

An axis in LCNC can be, depending on configuration, one or more motors, hydraulic actuators, pneumatic actuators... anything which moves.  Not just a single servo motor.  For example, consider a gantry router with two motors - one on each side - of the gantry.  In the typical layout LCNC is controlling two motors at the same time, but you (the user & gcode programmer) only have one axis available to command.  For good reason you cannot (easily) program the left gantry motor to move independently of the right gantry motor.

So both gantry motors, as a pair, make up the "Y-axis" as far as the user is concerned.  The individual motors which are paired to make an axis are called "joints" in LCNC.  A "joint" cannot be (easily) commanded in LCNC - the motion interpreter is programmed to make the motor move in a certain way which will result in the "axis" moving as desired.

Another simple example:  In the above gantry, to move the "Y-axis" (whole gantry) "joint-1" must rotate clockwise, while "joint-2" must move counter-clockwise at the same time.  Joint-1 and Joint-2 are programmed to move differently, but the end result is appropriate "axis" motion.

linuxcnc.org/docs/devel/html/motion/kinematics.html

More complicated relationships between joints and axes exist  - think of robot arms, 3D printer "core-XY" systems, etc.

Which brings us to your ATC and "axis".  The motor you intend to use to move the carousel may be a servo (or stepper) physically connected exactly the same as the motors which move the tool (or table) around, but there is no requirement in LCNC to control that ATC motor as an "axis."  LCNC can control a limited number of axes (9), but it can also control a huge number of other 'things' - like motors - that aren't part of the motion interpreter.

So you can have a step & direction motor (or analog, or Ethercat, or serial, or...) that LCNC can command... but that isn't part of the cartesian motion system.  Pumps, vacuums, rotating disco balls - all are motors which which have nothing to do with coordinated XYZ motion of a CNC machine.

Your ATC platter motor can be just like a pump - except the HAL component 'carousel.comp' can position the platter accurately.  For a step-dir controlled motor, LCNC needs carousel.comp, as well as a separate stepgen.comp HAL component.  Carousel figures out the speed, distance, and direction, and send the appropriate commands to stepgen.comp, which then outputs (via the Mesa or parallel port) to the motor drive.

You can't program the ATC to accomplish a gcode move like "G1 C126.1 F3600", but carousel.comp will accurately index the ATC platter when the tool change command is configured properly.

So in LCNC terms, what you have are motors which are wired up and ready to go... and you can choose via your configuration whether they are controlled as joints/axes or via some other method (carousel).

That's enough LCNC jargon for now.  Try to digest, read the LCNC manual as much as you can stand, and we'll chat more when the next set of questions occur to you.

Running an ATC as a rotary axis (A,B,C) used to be the easiest workaround to get it working and, as already pointed out, a lot of people have configured their tool changers like that.
The flaw with this approach is that the operator could actually send motion commands to the ATC motor through Gcode/MDI whether intentionally or unintentionally.
Personally I would always prefer using the 'carousel' component for an ATC.

Hi again.

I understand the general concept of motion controlled/interpolated axes and how they work. But I can’t clearly see how all the different components/functions/addons in LinuxCNC work together and share different kinds of parameters, variables, bits, etc.

As the machine is setup now, the tool carousel motor is configured as Joint 3/C-axis and can be commanded manually by jogging, by MDI-commands and also by a G-code program. In other words, a fully functioning axis that can be interpolated with the rest of the axes on the machine.

The servo-drive is controlled by a +/- 10V analog signal and is giving encoder feedback til LinuxCNC.

I have setup the encoder-scaling in the servo-drive so that the servo-drive sends 3600 encoder-pulses per revolution of the carousel back to LinuxCNC.

My tool-carousel can hold 8 tools, so the 3600 pulses per revolution is easily divided by 8 to get 450 pulses per tool-pocket advancement.

Now… I know this setup is completely overkill for driving a tool-carousel, both in terms of accuracy and motion controllability, but as this is how the machine is setup, I was hoping I could use the tool-carousel as is.

So to adjust my questions:

-Can the tool-carousel be controlled (relatively easily) from carousel.comp with this setup? i.e. with +/- 10V analog signal and encoder feedback?
-If not, what would be an easy way of rearranging the setup so that I can get this to work? Do I need to rewire and reconfigure the servo-drive so that I can move/jog it at a constant speed by HAL-pins?

Hope this clarified my project a bit.

Thanks for all the replies folks. I really appreciate it.

Update…

I have been thinking and reading some more and I think that if I can find a way to access the system variables #<_current_tool> and #<_selected_tool> from within a G/O-Code subroutine, I think I can find a way to do this.

If I haven’t overlooked something important, a subroutine to return the current tool from the spindle to its pocket and retrieving the requested tool from its pocket and inserting it into the spindle shouldn’t be too diffucult, since all the tool-carousel moves, except the carousel rotation, are controlled by pneumatic cylinders. All the tools in the carousel have fixed pockets, so it is relatively easy to keep track of their positions.

I might be totally wrong here, but I will give it a go and see if I can make it work.

I will keep you posted.

And if you have any hints, tips, tricks or suggestions regarding this, please let me know.

Have a nice day folks.

I think it's time for you to do some (more) research.

First... there's an excellent vid on YT from Erik Salo (sp?) about configuring a tool changer.  His explanation and demonstration of the digital in/out hal pins is excellent.  Even if your configuration will be different (not using carousel.comp), it's still a very good introduction of all the things which have to be choreographed.

Second, there are many, many examples of tool-changer configuration files - including gcode subroutines - on the forum.  Yes, the forum editor is horrible, and the search tool is a bit lacking, but I'd suggest digging through posts as much as you can stand.  Once you've found a handful of configurations & subroutine examples to digest, go through them and make yourself notes in narrative form exactly what the author was trying to achieve.  Pay particular attention to what signals were passed between what 'things', and how that was accomplished.

That should give you an idea of the steps & sequence you need to really get started your own config.

As another resource, the Probe Basic GUI includes an ATC simulator - which also has various subroutines and so forth to review and digest.  No need to install the GUI if you don't want - just download the relevant files from github.  The PB tool changer scheme does not use carousel.comp, nor does it treat the platter as an axis.  All of the 'go-to-this-pocket' logic is contained within the subroutines, and the whole thing is designed to work with geneva-wheel mechanisms and 'dumb' motors.