Adding an ATC to my 4 axis( APSX Spyder) CNC Mill "router"

Hello All,

I will attempt to cram as much information into this post as possible to eliminate some back and forth.

I have an APSX Spyder CNC with 4th axis. The machine has a dedicated control using Linux CNC and a Mesa 7i92 controller. It does not come with an ATC.

apsx.com/desktop-cnc-machine

I have added a manual ATC that when the program pauses for a tool change I simply activate a manual pneumatic 3 way valve to release the previous tool and add the new tool.

I am looking to automate this process.

I am looking to make a router table tool change set up. With tool (1) in the spindle the machine would move to a set pocket location for tool (1) / open the pneumatic valve / drop the tool / move up and over to the next tool location/ open pneumatic valve / lower and pick up new tool / resume program.

I unfortunately have no idea how to accomplish this. I have a decent idea of what’s happening (thanks to this vide from Erik) but I don’t know where to start to execute the process. I have included the .hal and .ini files Please let me know where is the right place to start.

Again thanks to Erik - I now know I need to do the following . . .

• Remap the tool change command to route to a subroutine in my ini file
  Map my physical inputs and outputs to virtual "pins"
  Write a subroutine that performs the tool change

Any help and advice would be greatly appreciated.

Martino, thanks for reaching out from the video. I'm no expert but this seems like a straightforward task. I'll do my best here and the smarter members can correct where I have gone wrong.

From your writeup, I'm going to assume that you don't have a "moving carousel" but instead will have some number of tools that are in known locations. Is that correct? If it is true, then you don't need the carousel subroutine, just a remap and an "O Code" subroutine.

Here are the steps I see:

1) Add a Remap command to your .ini file for the Tool change command
2) Map physical I/O for clamp, unclamp and any sensors to "motion.digital-in-XX" and "motion.digital-out-XX" pins in a .hal file. Make sure to load that new .hal file in your .ini file.
3) Write the "o code" subroutine that performs the actual tool change. This will liberally use M64, M65 and M66 commands to read from and output to the physical I/O from step #2 above.

What I would need to know is what physical actuators and sensors need to be involved in the tool change process. There must be some clamp/unclamp system. Is there a sensor that tells you a tool is in the spindle? What are the I/O? With that I can write an example subroutine.

That's how I see the project. Any comments?

Erk

For step 1 above, you will need to add a remap command to the [RS274NGC] section of your .ini file. M6 is the relevant command to remap to a subroutine.

In this case, I called the subroutine "toolchange." That will now call a file named "toolchange.ngc" when you execute an M6 command.
Here's what that will look like:

[RS274NGC]

REMAP=M6 modalgroup=6 prolog=change_prolog ngc=toolchange epilog=change_epilog

You will also need to make a new .hal file to define all of your I/O for the toolchange. You could add the toolchange I/O to your current .hal file but it's better practice to make a new one so you better focus on that section and it will make debug easier. I would make a new file called "toolchange_binary.hal" where you map your physical I/O to motion.digital In and out pins. You will then read / actuate that physical I/O through M64, M65 and M66 commands in your "toolchange.ngc" subroutine that was called above.

To add this new .hal file to your .ini you would add this line:

[HAL]

# The run script first uses halcmd to execute any HALFILE
# files, and then to execute any individual HALCMD commands.
#

# list of hal config files to run through halcmd
# files are executed in the order in which they appear
HALFILE = toolchange_binary.hal

Once you define the I/O you have, I can make you example toolchange_binary.hal and toolchange.ngc files.

Erik

Thank you again - in advance of you help on this.

You are correct I do NOT have a moving carousel. It will be a static rack style tool holder.

For the physical actuator it will be a single out put pin of the MESA7i92 to a relay that will trigger a pneumatic valve to open when triggered. There is no spindle location necessary. The spindle stops when a tool change is called and the tools are conical.

For starters my machine "home" is at the upper right corner of my machine. the tools will be ten in a row at the bottom left of my machine. I would like when the next tool is called the sub routine would tell it to go all the up in the (z) G28 I believe. Move over to the pocket that is in the spindle rapid down a set distance. Move slower down the remaining (z) distance(.25). Open the valve - while the valve is open Move up (.25). close the valve. rapid up to (Z) home and move over to the next called tool.

I would like to have 10 tool holders in a line. Their locations will be...

T01 = x-3 , y14.5, z-3.25
T02 = x-3 , y13, z-3.25
T03 = x-3 , y11.5, z-3.25
T04 = x-3 , y10, z-3.25
T05 = x-3 , y8.5, z-3.25
T06 = x-3 , y7, z-3.25
T07 = x-3 , y5.5, z-3.25
T08 = x-3 , y4, z-3.25
T09 = x-3 , y2.5, z-3.25
T10 = x-3 , y1, z-3.25

If the (Z) can rapid down to -3 then travel the remaining .25 slower that would be best.

Let me know what if you require addition information.

I think this is enough information. I would consider installing inexpensive hall or optical sensors at each tool station. It's optional but if sensors exist to tell you if a tool is in a slot, you can verify that a slot is empty before trying to park a tool in that spot. Also, you can verify that the previous tools has been successfully returned to its slot before trying to load a new one.

In any case, you can start with no sensors and then add them if the system isn't reliable enough without them.

I'll write up a sample program for you using Andy's good suggestions.