Hardinge HXL Tool Turret

More
29 May 2013 07:44 #34888 by microsprintbuilder
just made the tool failed timer 15sec instead of 5 seconds and it now updates. I'm thinking I need to chage that number to more than it takes to do the longest tool change. Would you agree?

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

More
29 May 2013 14:57 #34899 by ArcEye
Replied by ArcEye on topic Hardinge HXL Tool Turret
Hi

You could take the longest time, or a more elegant solution might be to calculate the number of tool station moves and multiply that by the time to move one station.

It is a particular problem sometimes with realtime components and changers that have a lot of electromechanical or pneumatic components.
The component moves at the speed of a greased whippet and unless you put in timers to build in delays,
you can have problems where the machine does not match the logic because it simply has not caught up yet.

regards

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

More
29 May 2013 17:38 - 29 May 2013 17:51 #34903 by BigJohnT
Replied by BigJohnT on topic Hardinge HXL Tool Turret

just made the tool failed timer 15sec instead of 5 seconds and it now updates. I'm thinking I need to chage that number to more than it takes to do the longest tool change. Would you agree?


Yes, the fail timer needs to be longer than it takes to normally change any tool.

Edit: just in case you didn't notice the fail output is connected to halui.program.stop in your hal file. This aborts the tool change.

JT
Last edit: 29 May 2013 17:51 by BigJohnT.

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

More
31 May 2013 17:02 #35008 by andypugh
Replied by andypugh on topic Hardinge HXL Tool Turret

What I have done with 3 different toolchanger components that start in an unknown state, is to change iocontrol.


I wonder if this scheme would work....

The tool change component has an output pin "toolchanger.current-tool"

In master it is possible to read HAL pins in G-code. (it requires an option to be set)

LinuxCNC has the option of "startup G-codes". (I don't know when these run...)

A startup G-code of M6 T#<_hal[toolchanger.current-tool]> should cause no toolchanger motion, but should update the system's view of current tool.

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

More
31 May 2013 20:36 #35014 by ArcEye
Replied by ArcEye on topic Hardinge HXL Tool Turret
Andy Pugh wrote:

I wonder if this scheme would work....
The tool change component has an output pin "toolchanger.current-tool"
In master it is possible to read HAL pins in G-code. (it requires an option to be set)
LinuxCNC has the option of "startup G-codes". (I don't know when these run...)
A startup G-code of M6 T#<_hal[toolchanger.current-tool]> should cause no toolchanger motion, but should update the system's view of current tool.


See no reason why not, just depends how the toolchanger establishes the current tool.

If it is a grey scale decode, then it knows immediately, but if it has to find tool one sensor first, then M6 will get a tool number 0 passed.

The edit to ioControl.cc is fairly minor, a couple of extra pins and setting a tool change state based upon the flag pin, but not likely to be 'approved by management' B)

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

More
05 Jun 2013 06:38 #35273 by andypugh
Replied by andypugh on topic Hardinge HXL Tool Turret

LinuxCNC has the option of "startup G-codes". (I don't know when these run...)
A startup G-code of M6 T#<_hal[toolchanger.current-tool]> should cause no toolchanger motion, but should update the system's view of current tool.


I just found out about M61, which sets the current tool number, but with no pin-wiggling in HAL. That is probably the appropriate command.

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

Time to create page: 0.230 seconds
Powered by Kunena Forum