Another "what do I need" thread. Vmc retrofit

thewho wrote:

Normal operation (tool in spindle and free slot in the carousel) of the tool changer is:

1. Move Z up to desired height
2. Check if tool in spindle
3. Verify that carousel is in the right slot
4. Verify that slot is empty
5. Move ATC arm out to spindle
6. Verify that it's in position
7. Release drawbar
8. Verify that it moved
9. Move Z up.

As the sequence requires Z movements at various points in the cycle it might be best to do this as a G-code subroutine. It isn't easy to move the machine Axes from HAL or ladder. (There are ways, but I would not call them elegant).

So your sequence above would look a bit like:

And so on.

Eventually you could re-map this G-code subroutine to operate when the M6 command is given. This Actually might be good to do from the start, as the sample remaps have code to pass the tool number into a G-code parameter #<tool>. In fact I don't think that (abort, ...) works unless you have set up the subroutine as a re-map.

Remapping docs: (A lot to read, but you would only use a sub-set) www.linuxcnc.org/docs/html/remap/structure.html

thewho wrote:

That seems A LOT easier than the whole hal thing
I still don't know how it works but that seems like something I might be able to learn

I have been thinking about this a bit more, and it might actually be easier in Python than in G-code.

(Just because G-code is a rather poor programming language, and interacting with HAL signals is easier in Python).

I was talking with Chris M on IRC last night and he showed me an example of a Python script that creates HAL pins that signals from ATC switches etc can be connected to, and that can be called as a remap.

The default tool-changer is HAL_manualtoolchange. That is just a Python script that sits there waiting for the tool-change pins to change state, then pops up a dialog box.
I need to test if a toolchanger can operate in the same mode. I suspect that actually it can't, because the motion queue is halted during a normal tool change. The remapping function gets round this using cleverness.

This is hal_manualtoolchange:

git.linuxcnc.org/gitweb?p=linuxcnc.git;a...7bb203f3260d12eb016c

Which looks complicated at first glance, but a lot of that is the overhead of the two dialog boxes. Basically lines 53-58 create the HAL pins that connect the tool number, pocket number and change request to LinuxCNC.
Then the loop 80-89 waits for the tool-change pin to go high, and then calls the do_change function.

Do you know what it takes to move your carousel, and how the system knows which tool is presented to the changer arm?

thewho wrote:

That's how I think it works at least

OK, there are ways to handle BCD. One way is to feed the pins in to
www.linuxcnc.org/docs/html/man/man9/weighted_sum.9.html
to get a 32-bit number (not binary coded) and then convert to normal binary with
www.linuxcnc.org/docs/html/man/man9/gray2bin.9.html

However, it is equally likely that the decoding will be done in whatever code runs the changer.

I had forgotten that the most common way to control a tool-changer is with the Classic Ladder soft-PLC.
Intro: www.linuxcnc.org/docs/html/ladder/ladder_intro.html
details: www.linuxcnc.org/docs/html/ladder/classic_ladder.html
examples: www.linuxcnc.org/docs/html/ladder/ladder_examples.html

(The problem is that all tool changers are different, and there are lots of ways to do them)

I had a play around inside a cut-down hal_manualtoolchange last night, and unfortunately that idea isn't going to work.

The problem is that it is not possible to MDI G-code movements when the machine is in Auto mode (ie, when runing a G-code program)
So, it works with M6 in the MDI window, but causes an error with M6 in a G-code programme. (this isn't a surprise, but I wanted to check).

I don't think, therefore, that everything can be done in one place.

Moving the carousel and checking the gray-code is something that needs to be done in real-time. That means either in classic-ladder or a custom HAL component.
As I think that the custom HAL component will be generically useful I am happy to write that, if you are happy to test it

There are already various components along the same lines: wiki.linuxcnc.org/cgi-bin/wiki.pl?Contri...oolchanger_component

But none of them support a 5-pin Gray-scale _and_ don't require recompiling parts of LinuxCNC.

I think that it should be possible to use a G-code routine as already suggested in conjunction with the proposed component to do our complete sequence.

Something like: