tool changer component integreted on a axis
07 Dec 2013 05:07 #41392
by andypugh
Encoders make homing almost too easy
Something a bit like this:
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)
Replied by andypugh on topic tool changer component integreted on a axis
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) Please Log in or Create an account to join the conversation.
Time to create page: 0.417 seconds