Hardinge HXL Tool Turret
- microsprintbuilder
- Offline
- Elite Member
- Posts: 163
- Thank you received: 4
Please Log in or Create an account to join the conversation.
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.
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
Please Log in or Create an account to join the conversation.
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.
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'
Please Log in or Create an account to join the conversation.
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.