Boxford 125 lathe Tool Changer Comp FERROR (SOLVED)
The same code with possible modification of values in
param rw float odd_move = 22.2
param rw float even_move = 24
will work for TCL 160 and TCL 125 and probably other lathes with the same 'move past pawl and reverse to stall against it' methodology.
These move figures are only half the actual move in degrees. The scaling takes care of the distance actually moved.
There is a very good reason for this.
It prevents the stepgen seeing any move as being in excess of 180degrees, therefore all moves between tool stations will be forward moves.
If you command a move to a position which is say 270degrees on a angular axis, the stepgen will try to move 90degress backwards
to get to the same point by the shortest route.
In theory unlinking the stepgen dir signal and using our own should work, but it didn't and the axis wanted to go backwards all
the time despite the flag being set at TRUE (FWD).
As this worked perfectly, I preserved my sanity and just left well alone.
So somehow
param rw float odd_move = 22.2
param rw float even_move = 24
and
SCALE = 80.0
should get the stepgen to only move forward. I don't quite understand this though.
Please Log in or Create an account to join the conversation.
The author of the comp has commented on the unwanted backward moves:
[code]The same code with possible modification of values in
param rw float odd_move = 22.2
param rw float even_move = 24
will work for TCL 160 and TCL 125 and probably other lathes with the same 'move past pawl and reverse to stall against it' methodology.
So somehow
param rw float odd_move = 22.2
param rw float even_move = 24
and
SCALE = 80.0
should get the stepgen to only move forward. I don't quite understand this though.
I have never used angular units before. So the scale 80 was arbitrary do you think it might be moving too far so going over 360' ?
Another thing I have noticed is that the X and Z jogging seems to be altered by the slider that is in degrees !! and not the linear one.
Please Log in or Create an account to join the conversation.
[edit]
Ok, I think I get it:
The idea is to command only half the required angle so as not to exxeed 180° per command and to compensate for that by doubling the SCALE so the motor actually moves to the correct position. So it commands 22.2° but the motor moves 44.4°.
I still don't understand why your motor is moving backward on some moves.
[edit2]
maybe keep an eye on stepgen.3.position-cmd and see what that does when its moving backwards.
Please Log in or Create an account to join the conversation.
Usually the SCALE would represent how many steps the stepgen needs to put out to move the axis one unit. So for an angular axis this would be 1 degree. Does the toolchanger move to the correct position with this setting?
[edit]
Ok, I think I get it:
The idea is to command only half the required angle so as not to exxeed 180° per command and to compensate for that by doubling the SCALE so the motor actually moves to the correct position. So it commands 22.2° but the motor moves 44.4°.
I still don't understand why your motor is moving backward on some moves.
[edit2]
maybe keep an eye on stepgen.3.position-cmd and see what that does when its moving backwards.
Yes we are getting there.
So the first thing is to get the scale set to get exactly 360' when commanded. (have to test if g1 A360 f5 will work)
This just might be cured with scale if it was going over 360I still don't understand why your motor is moving backward on some moves.
I will check stepgen.3.position-cmd when I get the scale correct.
Many thanks for sticking with me. I will report back. I intend to move the config to V2.8 so will have to sort the ini file out because of joints etc. I have done this before. I just hope the comp will compile on 2.8
Please Log in or Create an account to join the conversation.
So the first thing is to get the scale set to get exactly 360' when commanded
Exactly and that number has to then be multiplied by two to work correctly with the comp.
Please Log in or Create an account to join the conversation.
I've also just started playing with this component. I've noticed it runs in reverse after toolchanger.position-cmd rolls over from 360 to a lower number of degrees. Each move increments this value until it finally rolls over.
Please Log in or Create an account to join the conversation.
[AXIS_#]
WRAPPED_ROTARY=1
if I recall this correctly the sign of the command determines the rotation direction.
Please Log in or Create an account to join the conversation.
So I wonder if maybe the wrapped rotary option would solve that.
[AXIS_#]
WRAPPED_ROTARY=1
if I recall this correctly the sign of the command determines the rotation direction.
First it is nice to see I am not alone with this.
Sorry I have not responded until now. I have installed linuxcnc 2.8 mint I now have moved the config on to mint 2.8 and had to sort out the files ie. Joints etc.
I also have taken the turret off the lathe so I could disable the paul so it will run backward without it trying to break itself .
How can I be shore that I have it set to degrees and not steps (I do have it set as angular) Because I am wasting your time if the scale is wrong. At the moment I can drive it with G1 A90 F200in the midi. Then A360 it will do a full circle Then A0 then it reverse back to 0
Attachments:
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Does it respont to the m6tx commands?
Yes but this is only for testing I had to comment a coupe of lines out in the hal file. I can also jog it with page up/doen on the key pad
Would you mind posting your config. I am have the same trouble with as you as it not respecting the 360'
Have you read the readme and the comp?
Between the 3 of us we just might have a chance
![:laugh: :laugh:](/media/kunena/emoticons/laughing.png)
Please Log in or Create an account to join the conversation.