Boxford 125 lathe Tool Changer Comp FERROR (SOLVED)

More
04 Nov 2020 07:33 #188294 by Clive S

See edit in my last post.


Thanks. That makes sense. I will try it later in the day I have to go to the hospital for a bit of surgery now.

Please Log in or Create an account to join the conversation.

More
04 Nov 2020 07:38 - 04 Nov 2020 07:39 #188295 by Aciera
Another question:

Do you find the "Jogging" function actually useful?

[edit]

Good luck!
Last edit: 04 Nov 2020 07:39 by Aciera.
The following user(s) said Thank You: Clive S

Please Log in or Create an account to join the conversation.

More
04 Nov 2020 16:30 #188320 by Clive S

Another question:

Do you find the "Jogging" function actually useful?

[edit]

Good luck!


Thanks.

Ok I think I have found out what is happening re the fudge number I have changed it to 10 and it definitely reverses back and locks
and then misses steps .

But the trouble is that going to the next tool it is then short on steps so it looks like it is not respecting the missed steps.

Re the jogging function it is only good for testing i.e. when it is short of steps you can jog it the missed steps so as then the pawl will drop in . In normal use you would never use it.

Please Log in or Create an account to join the conversation.

More
04 Nov 2020 18:38 #188333 by Aciera
Hm, it shouldn't get short on steps going forward. It needs enough steps to clear the pawl and enough steps to back up against it and some more to be certain its right up against the metal. It it is not against the metal then the next forward move will take it even further beyond the pawl and it will end up even further away from it after the backward move and so on. It actually needs to loose steps in
its locking move:
So say we are at 0° and we command a forward move, say 48°, the stepgen then puts out the steps (48 x scale) and the motor moves forward. Say at 47° the pawl drops in so at the end of the move it is 1° beyond the pawl.
Now say you command it to move backwards 5° (which is actually 4° to much). So the motor moves the 1° back against the pawl and the remaining steps for the excess 4° are "lost". But the as far as the stepgen and the component are concerned the motor is at (48° forward - 5° backward = 43°) because the stepgen does not now that the motor is stalled.
In an actual axis this would be a problem but in this case it doesn't matter because the next forward move is now added to the 43° and the motor starts forward again. The forward move is always relative to the pawl, not the absolute angle in degrees from where we started.

Having written all this makes me think that the forward moves must add up to 360° (4x "even" + 4x "odd" = 360°). Otherwise it ends up getting ahead of itself. So I think you need to adjust those two angles.

Please Log in or Create an account to join the conversation.

More
04 Nov 2020 19:04 #188338 by Clive S
I agree with every thing you have said, it is a very good explanation.

Ok I will check this tomorrow. I think from a fresh restart of Axis. (I always restart and recompile when I change anything) First thing after homing I have to put the M6T1 in the MID (obviously if T1 is on the pawl) then T3 that drops in fine and reverses and stalls. Moving on to T4 it is then short so the pawl does not drop in.

At this point we have not done 360'. Does this compute in your statement re going over 360'

I will double check this tomorrow .

I will make a short vid of this with fudge at 10 and without a reverse stall fudge 1 with the same moves.

Please Log in or Create an account to join the conversation.

More
04 Nov 2020 19:30 #188339 by Aciera

Having written all this makes me think that the forward moves must add up to 360° (4x "even" + 4x "odd" = 360°). Otherwise it ends up getting ahead of itself. So I think you need to adjust those two angles.


Ok, I changed my mind on this one. Doesn't make sense. I now think it the sum needs to be 360° + 8 x (the extra angle beyond the pawl). Let's see how I feel about that tomorrow.

Please Log in or Create an account to join the conversation.

More
04 Nov 2020 19:38 #188340 by Clive S

Having written all this makes me think that the forward moves must add up to 360° (4x "even" + 4x "odd" = 360°). Otherwise it ends up getting ahead of itself. So I think you need to adjust those two angles.


Ok, I changed my mind on this one. Doesn't make sense. I now think it the sum needs to be 360° + 8 x (the extra angle beyond the pawl). Let's see how I feel about that tomorrow.


Ok hope you are not getting sick of me B)

I will do the vid in the morning a picture is better than a 1000 words. (for me anyway).

Please Log in or Create an account to join the conversation.

More
05 Nov 2020 07:47 - 05 Nov 2020 08:37 #188377 by Aciera
Another thing that I find odd is that the extra forward movement is already added to the two angles ("odd" and "even"). This leads to the adding up of the extra movement when you change to another tool then the next one up.
For example If you change to the one after the next. You need two movements and that move will then have twice the extra forward movement and so on.

So I think the two angles "odd" and "even" need to add up to 90° and the extra forward movement to clear the pawl should be added once after all the necessary "odd" and "even" movements have been added up.

I've been working a bit on this but the jogging is giving me trouble.

Ok hope you are not getting sick of me

No worries. Gives me a chance to learn about programming a component.

[edit]
Try this :

File Attachment:

File Name: toolchange...-05.comp
File Size:12 KB


Adjust the values here. odd and even moves without extra movements and should add up to 90°
// allow parameters to be changed by setp for fine tuning
param rw float odd_move   = 40 	     	"distance from odd tool station to even one";
param rw float even_move  = 50       	"distance from even tool station to odd one";
param rw float clear_move = 5			"additional move to ensure clearing the pawl";
param rw float lock_move  = 10        	"backward move to ensure locking";
param rw float lock_delay = 200         "delay before lock back, very roughly in ms";

Note: I still need to remove/adjust this as it does not make sense anymore. But then you need to adjust your hal as well. So we do that later.:
pin in bit ishomed = false          	"Status of A axis homing";
Attachments:
Last edit: 05 Nov 2020 08:37 by Aciera.

Please Log in or Create an account to join the conversation.

More
05 Nov 2020 08:44 #188380 by Clive S
Ok. Thanks you are teaching me a lot.

I need to sort some issues in respect to the angles we only have the original guys comp saying that they are correct i.e. odd and even are different.
To check this out I am making a cad drawing of a disk with the angles at 45' then I can check it against the turret.

Also with having the actual turret (chuck) unbolted off the pawls I need to check if what I am calling T1 is actually T1 as that might be throwing a spanner in the works.

I will check that by putting the turret back on and making sure that the even number tool lines up with my T1

It might be that all the angles are indeed 45'

Please Log in or Create an account to join the conversation.

More
05 Nov 2020 12:22 #188388 by Clive S

Ok. Thanks you are teaching me a lot.

I need to sort some issues in respect to the angles we only have the original guys comp saying that they are correct i.e. odd and even are different.
To check this out I am making a cad drawing of a disk with the angles at 45' then I can check it against the turret.

Also with having the actual turret (chuck) unbolted off the pawls I need to check if what I am calling T1 is actually T1 as that might be throwing a spanner in the works.

I will check that by putting the turret back on and making sure that the even number tool lines up with my T1

It might be that all the angles are indeed 45'


Ok I confirm that the angles are not the same for odd and even.

But I was being stupid again as I was always starting from tool 1 BUT it was not tool 1 I had marked it up wrong as it was tool 2 :pinch:

It is now marked up correct. The vid shows it starting from tool and it should end on tool 2
This was moved by gcode
M6T2
G0 x2
M6T3
G0 x0
M6T4
G0 x2 etc
...
...
M6T2
Stations 1,3,5,7 are tools and 2,4,6,8 are drills or round shank tooling
Therefore requires different movement depending upon whether current tool is odd or even number.

I am using 44.5 and 48 with the fudge at 10 in the vid

Please Log in or Create an account to join the conversation.

Time to create page: 0.098 seconds
Powered by Kunena Forum