Implementing a tool changer, is ClassicLadder the way to go?

My router table will have a tool changer. This will involve a number of inputs and outputs. I have a Mesa 7i76e card.

Is ClassicLadder the way to implement this? For example, I don't want to actuate a tool change (either via gcode or manual push button) unless pneumatic pressure is high enough.

That would also depend on the toolchanger, but I try to do as much as possible in half or using the carousel component written by Andy.
Pressure sensor can be wired and programmed in half to launch a rocket, if you want it to, so yes it can be programmed not to enable the machine while there is no pressure or the pressure is low, or enable the machine but stop it if a tool change is required, or print a warning on screen for any of the mentioned instances.

Sorry, what's "half"?

he meant HAl.

Classicladder is perfectly fine for tool changers.
Making a custom HAL component is more convenient if you like programming.
Using the carousel component would be advisable if that fits your toolchanger type as it's already built and reasonably tested.

Chris M

cmorley wrote: he meant HAl.

Chris M

Chris, you are definitely multi lingual. I had no Idea what that meant when translated from Kosovian!

Jet, I think it would depend on what language you are more comfortable with. Me I'm a C coder and while I have written some useful stuff in Python, I much prefer C and just love the whole .comp architecture!

That would depend on what type of toolchanger and whether or not you have to move an axis or not during the toolchange.

I'm much more comfortable in C/C++ than Python. I looked a bit at the classicloader, but am not sure about it yet.

My tool changer won't be a carousel, but rather a row(s) of tools at the end of the router bed (I had the bed made extra long to accommodate this). I may build a dust cover for them that would have to retract for tool changes. It may be opened by the gantry moving to the extreme end of the bed, or may have its own servo or pneumatics, I haven't decided yet.

The BT30 tool holders will slot into the rack, be released by the spindle, it will move up and over to the next tool.

So, I don't know if the carousel component would work for that.

I wrote my atc routine into G code / O code subroutine.

It used M64/65/66 to read inputs and write to engage relays. It checked what tool position you were in, then then did the math for shortest distance to the desired tool.

It works quite well. This was on a Brother atc, which is in some ways simpler than most because it is mostly controlled by Z movement.

My router is going to be set up exactly like yours though and I will be doing it the same way. I wont have my spindle though for a few more months.

My toolchange.ngc is here.

forum.linuxcnc.org/30-cnc-machines/32276...ure?start=270#102282

I'm thinking it should still be pretty applicable as a method for the tray now that I've thought about it. I have no movement code in there, but that's all pretty basic - make an array of tool locations, then issues g0/g1 commands to get to the desired positions.

- goto staging point
- varA = what tool do I have
- varB = what tool do I want
- goto pos varA
- release tool
- goto pos varB
- collect tool
- return to staging point

Read your tool release/clamp sensors at the right times, maybe put sensors on the tray or just one on the spindle clamp for "in position" signals for safety (not so important if you have a full closed loop machine)

The one thing I never got worked out is travel zones. If your tray doesn't move, you don't want to hit it in normal use, so you need your soft limits to "change" in cutting mode and tool change mode.

Half=hal

Bloody autocorrect !!!