Suggestions for a better choice for axes at home in ClassicLadder

More
27 Oct 2020 06:48 #187379 by rootboy
Hi guys,

Currently I'm using:

net home-z => classicladder.0.in-07
net home-x => classicladder.0.in-08

in my CL program to make sure that I am homed before I change tools. A couple of things are going on that makes me think that there might be a better choice for detecting that the X & Z axes are at home rather than these inputs.

1) Both home-z and home-x report that their axis is at home while running the homing sequence. Kinda odd if you ask me... This I "filtered out" using a pair of timers to inhibit the changer for 3.5 seconds during the initial homing sequence, and for 1 second for subsequent moves. It's a kludge, but it works reliably.

More importantly, I don't always get an at home signal after sending the axis to home. Which means my tool changer won't index to the tool that I want, and the program just sits there. This one is a show-stopper.

I could always just look at the current position of the axes and decide if the tool changer is in the clear, but if there is a standard way of doing this I'd rather do that.


Thanks!

John

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

More
27 Oct 2020 07:48 - 27 Oct 2020 08:10 #187385 by Aciera
What about:
joint.N.homed OUT BIT (DEBUG)

TRUE if the joint has been homed

If you are using 2.8, that is.
Last edit: 27 Oct 2020 08:10 by Aciera.
The following user(s) said Thank You: rootboy

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

More
27 Oct 2020 13:25 - 27 Oct 2020 13:25 #187412 by Todd Zuercher
How about using a near component to measure if the joint-pos-cmd is where you want it to be?
Last edit: 27 Oct 2020 13:25 by Todd Zuercher.
The following user(s) said Thank You: rootboy

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

More
27 Oct 2020 15:11 #187431 by rootboy
Thanks guys! I've give both of them a try.


John

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

More
28 Oct 2020 05:05 #187507 by rootboy
I ended up using both. I had made a poor choice of signals (mine) and the "joint.N.homed" signals work much better. I followed that up with using the "near" function to give myself a bit of wiggle room (.1").


Thanks again,

John

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

More
28 Oct 2020 14:19 #187575 by Todd Zuercher
I wasn't sure how much good the joint homed pin would be for your purpose. Which is why I suggested using the near component. It has nothing to do with the joints position relative to it's origin. It only indicates that the joint has "been" homed. and stays true regardless of where it is moved after that, unless the joint becomes unhomed for some reason.
The following user(s) said Thank You: rootboy

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

More
29 Oct 2020 05:52 #187651 by rootboy
The joint homed pin helps in that it tells me that the lathe is homed and as long as the lathe is near home, it's safe to change tools. So both were important to what I needed.

Today was spent in getting the lathe to go to home on its own if a tool change command was issued while the lathe was not at home.

There probably is an easier way to do this, but since a MDI command has been issued, one which I can't complete since the lathe isn't in the home position, I acknowledge the tool change command as if I had done it, removing it from the command stack. I then issue G0G53X0 and a G0G53Z0 commands to move to home, and then do the tool change.

Works very well. :)

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

More
29 Oct 2020 11:29 #187671 by Mike_Eitel
Have you looked into tool changer position?
The following user(s) said Thank You: rootboy

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

More
29 Oct 2020 13:08 #187682 by Todd Zuercher
The following user(s) said Thank You: rootboy

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

More
29 Oct 2020 16:29 #187699 by rootboy
We (as in Thurston) have just started looking into this. I'll let him handle it unless there is something that I am going to have to program. It's more of an operational issue for machinists, I'm just the humble controls engineer...

The difference being that while Thurston makes chips, I replace them. :)

Here's our EMCIO section:

[EMCIO]
EMCIO = io
CYCLE_TIME = 0.100
TOOL_TABLE = tool.tbl
TOOL_CHANGE_WITH_SPINDLE_ON = 1
RANDOM_TOOLCHANGER = 0

Which does bring up a different subject, a friend of Thurston's came by yesterday evening to have Thurston do a bit of surface grinding and asked why I wasn't using G28 codes. Other than it the obvious "Because it works just fine this way" I had no good answer for him.

For what I need for the tool changer, the G53 code works just fine, and will never have to be touched again. But it would be nice to see how to use the G28 code.

I see that I have to put the lathe where I want it and issue a "G28.1" to store the position. I'll play with it on the lathe when I get there.

He also mentioned G54, but I think that's what the touchoff sets does in the tool table.


Thanks again guys!

John

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

Time to create page: 0.074 seconds
Powered by Kunena Forum