tool changer component integreted on a axis

More
06 Dec 2013 06:25 #41364 by jtc
jtc created the topic: tool changer component integreted on a axis
Hi.

In the current configuration, we used a custom tool changer component that works independently (it´s not seen like an axis). The tool changer was homed by the drive itself, from the linuxcnc was just a 5v signal to command the drive to home.

But now we choose to implement a closed loop system, controlled by velocity and we have the need to home the tool axis by linuxcnc itself.

The goal is simple, just be able to home it and control the tool change like on the previously implementation. But I'm not seeing how to do this.


It's possible do a home sequence for a "something" that it's no treated like a axis?
Or its possible command a axis by the old tool changer component, and just home it like an ordinary axis?



Thanks,
João Tiago
More
06 Dec 2013 20:42 #41374 by andypugh
andypugh replied the topic: tool changer component integreted on a axis

jtc wrote: It's possible do a home sequence for a "something" that it's no treated like a axis?


Not easily. The problem is that the LinuxCNC homing sequence is controlled by watching the axis.N.home-sw-in HAL pins, and so the motors need to be associated with an Axis. (Or, technically, with a "joint").

I would have to experiment to find out if it is possible to define and home a joint that is not displayed as a dummy axis in the GUI. (I think it might be, consider an XYZ gantry with 4 motors).

The problem is that once LinuxCNC has control of the motor position, it probably wants to retain control of the motor position.

Would it be possible for you to run the entire tool change as a G-code subroutine? Then the tool changer motor can be an almost-normal controlled axis, and things get easier.
More
06 Dec 2013 21:19 - 06 Dec 2013 21:20 #41377 by jtc
jtc replied the topic: tool changer component integreted on a axis
So, let me see if I understand it right.

I define the tools in the tool-table with offsets and create 12 subroutines, each one for a tool pocket (or just one subroutine that have a input of the tool desired).

I virtually do a tool change, just to load the offsets, and after that I call the subroutine to move the angular axis to the desired position.

for example:
t3m6 g43
"subroutine_name" CALL

and in the subroutine file something like:
G0 A60

and it goes for the angle of the tool pocket.
Last Edit: 06 Dec 2013 21:20 by jtc.
More
06 Dec 2013 22:00 #41378 by andypugh
andypugh replied the topic: tool changer component integreted on a axis

jtc wrote: So, let me see if I understand it right.
I define the tools in the tool-table with offsets and create 12 subroutines, each one for a tool pocket (or just one subroutine that have a input of the tool desired).


I would suggest the latter, After the T-word is issued the tool number appears in #5400
www.linuxcnc.org/docs/html/gcode/overview.html#sec:parameters

I think that returns the tool number, not the pocket number, which is a little unfortunate. It's easy to test, just MDI
T6
(debug, #5400)

G-code like G0 A#5400 would work if the scale was set right.

It is possible to "remap" the M6 command to run the G-code routine automatically:
www.linuxcnc.org/docs/devel/html/remap/structure.html


A completely different approach would be to control the turret with Classic Ladder or a custom HAL component, and code a homing behaviour into that.
The following user(s) said Thank You: jtc
More
06 Dec 2013 23:20 - 06 Dec 2013 23:21 #41379 by ArcEye
ArcEye replied the topic: tool changer component integreted on a axis
Andy Pugh wrote:

A completely different approach would be to control the turret with Classic Ladder or a custom HAL component, and code a homing behaviour into that.


I agree, it might seem a difficult solution, but I would recommend you forget all about defining the toolchanger as an axis and/or trying to remap M6 and just go for a toolchanger component.

Then homing is just a word to describe moving the carousel to tool 1 or whatever and not tied into linuxcnc homing behavior designed for linear axes primarily or to Gcode toolchanges
You can do it on startup, after the axes are homed or whenever suits

We have no idea what machine you are talking about. The below is a toolchanger component for a mill with a carousel toolchanger for instance.
Tool 1 has an index switch and at startup, the machine uses it as a reference to work out what tool is in the spindle and update the current tool number accordingly
wiki.linuxcnc.org/cgi-bin/wiki.pl?Contri...oolchanger_component

regards
Last Edit: 06 Dec 2013 23:21 by ArcEye.
More
07 Dec 2013 03:13 #41389 by emcPT
emcPT replied the topic: tool changer component integreted on a axis
I will try to explain current situation.

Description:
Machine is a lathe, and the toolchanger is the problem.
The tools are fixed on a rotating disk and positioned by a complex mechanism that does not require to have clamping. This movement between tools is made by a servo with feedback to linuxcnc.
The only reference we have is the standard home procedure that must be performed accurately (using the index from the encoder). One index per linuxcnc session is enough and is done at machine startup.
After the home, one pocket is set as the current tool because the home is coincident with one tool pocket.

Things that we tested, that we assume are correct:
If we define the motor that rotates the toolchange like an axis, the home is solved (linuxcnc takes care of it as it is), but we are not able to control it using the component - or we do not know how.

If we use a component, we loose the ability to home the axis using linuxcnc built in homing procedure (that works well by the way).

*****

It seams to us (and we might be seeing it all wrong) that the best solution would be:

1) Use the servo that rotates the disk as an axis.
2) Home it like an axis
3) Use the information passed by the toolchange line (for example)

Txxyy

and that this info was used in some place where we could make calculations for the needed movement and issue movement commands in form of G code.

The movements must we done in respect from the actual pocket into the requested pocket.

*******

I hope I was clear in my explanation as I am not clear how to achieve it.
Sorry if the previous answers already addressed this, but we are quite confused. Remap looks like it is close to what we need ?
More
07 Dec 2013 05:07 #41392 by andypugh
andypugh replied the topic: tool changer component integreted on a axis

emcPT wrote: The tools are fixed on a rotating disk and positioned by a complex mechanism that does not require to have clamping. This movement between tools is made by a servo with feedback to linuxcnc.
The only reference we have is the standard home procedure that must be performed accurately (using the index from the encoder).


Encoders make homing almost too easy :-)

Something a bit like this:
component servotool "A component to drive a servo-controlled toolpost"
pin out unsigned state = 0 "shows the current state";
pin in bit home-trigger "pin to start the homing process, net to axis.2.homing";
pin in unsigned tool "tool position request"
param rw float pocket-scale "the number of encoder counts between the pockets"
pin out float position-cmd "output value to the servo PID";
pin io bit index-enable "net this to the servo encoder index-enable pin";

;;

switch (state){
case 0: // not homed yet
    if (home_trigger){
        state = 1;
        index_enable = 1;
    }
    break;
case 1: // homing
    position_cmd += 0.1; // change this to get a suitable homing speed
    if (! index_enable){ // index has been hit
        state = 2;
        position_cmd = 0;
    }
    break;
case 2: // waiting
    if (abs(position_cmd - ( scale * tool)) > 10){ // need to move to a new tool position
        state = 3;
    }
    break;
case3: // indexing to a tool
    position_cmd += 0.1; // change to set tool indexing speed
    if     if (abs(position_cmd - ( scale * tool)) <= 10){ // near target
        state = 2;
        position_cmd = scale * tool;
    }
    break;
default: // some strange error
    rtapi_print_msg("That's not good");
}

This needs a bit more refinement, I can see problems with it, but it shows the state-machine approach, where it can do any of 4 different things, one of them being moving at a constant speed searching for home.
The encoders have a built-in behaviour where if index-enable is set true then they zero themselves and set index-enable false on the next index event. You can use that to home your toolholder.

I think this probably needs a different starting state which sets the position-cmd equal to the current position, otherwise the servo will instantly shoot off at full speed to zero at machine enable.

Also, the logic here will only ever go to the next tool up, and can't go to a tool with a lower tool number :-) case 3: needs to subtract the number when the tool command is lower than the current position (actually, it needs to take the shortest-path, really)
More
07 Dec 2013 05:09 - 07 Dec 2013 05:14 #41393 by jtc
jtc replied the topic: tool changer component integreted on a axis
I was thinking, if a simple mux can do the trick...

before home, the mux connects axis.N.pos-cmd to pid.N.pos-cmd

when the axis is homed, homed signal connect to the mux2.N.sel, and now, the "toolchanger-pos-cmd" is connected to pid.N.pos-cmd by the mux.

it should behaviour like a axis before homing, so we can home, and after that, just control the position with the tool-changer component.
Last Edit: 07 Dec 2013 05:14 by jtc.
More
07 Dec 2013 23:41 #41397 by andypugh
andypugh replied the topic: tool changer component integreted on a axis
I just realised, that component needs to respond to tool-change-request and reply on tool-changed pins, like hal_manualtoolchange does.
Let me know if you think it is the way to go, and I will make the changes.
The following user(s) said Thank You: jtc
More
08 Dec 2013 02:14 #41398 by jtc
jtc replied the topic: tool changer component integreted on a axis
The component that we are using, calculates the smallest angle (optimised movement) and after that commands the position.

something like:

position_cmd+=angle_to_go

and it respond to tool-change-request and reply on tool-changed pins like you say, and also "translate" the requested tool-number to the correct slot, so in this point of view, its easier to implement the homing function in the current component .

one thing that I don't understand in you example, its that you set " index_enable = 1" and in case1 you will see if "!index_enable", so it should never happens...

but first I want to try with the mux.
Time to create page: 0.096 seconds
Powered by Kunena Forum