Mazak Micro Slant 15 Retrofit

Been a while, but mine should have a hydraulic cylinder for locking/unlocking the turret, an AC dual speed motor to turn the turret, 12 tools with 6 boring and 6 normal side tools.
Inputs to turret from Mesa:
Unlock turret
spin turret at speed 1
spin turret at speed 2
(not using speed 2, it is to fast for anything usable, i might try to do some hal stuff to use it later)
Outputs from turret to Mesa:
12 separate pins for each tool (this did require some hal stuff as there are empty spaces between each tool signal)
Turret locked
-
All those pins also go through the existing relays and interlocks, so might or might not still need something, but i doubt it.

smc.collins wrote:

the answer is  a suite of hal.conponents to run the tool changer in 1 file  long term  but that's bot going to happen without the effort part. 

I actually agree with you to an extent, in that a single toolchanger component for every toolchanger variant would be easier for users to set up.
But once you start to try to make a component to handle more than one toolchanger, then the configuration options multiply, and the problem comes back. 

The carousel component only tries to do part of the job, and even that is now so complicated that I think that I am going to have to write a full manual page for it. (Actually, what is probably needed is a page on toolchangers in general, describing all the options) 

Unless you plan to take on the job of writing custom components on request for each toolchanger as they appear on the forum then I don't think the "dedicated component for each changer" is workable. 

For my own toolchanger (If I had one) I would probably write a custom component, but even then I might end up calling it from a G-code remap just to be able to handle fault cases. 

If the tool change process involves axis movement then you _have_ to integrate G-code into the system, you can't move axes from a HAL component. 

To take the case of Tommylight's "pin for each position" changer, this is handled by the development version of carousel. The released version doesn't do it properly in all cases because (unless there is a Geneva mechanism) the tool changer doesn't stop when you stop the motor. 

If you want to write a custom comp for this, then the current carousel behaviour is:

When a new pocket request is received
1) If not homed, turn on the motor and rotate until the home pin is seen. Reset the pocket counter to 1
2) If the current position is not the current one, choose a motor direction and count the position pins as they pass
3) When you see the correct position pin, stop the motor
4) Wait a programmable time for the motor to stop.
5a) If the pin is still at the sensor, back off at slow speed until it is not: Go to 6)
5b) If the pin is not at the sensor, back off at slow speed until it is. Go to 5a)
6) Move forwards at slow speed until the pin is at the sensor. 

At this point the carousel component reports "in position" and expects clamping etc to be handled, and then the "iocontrol.0.tool-changed" pin to be set to indicate that the change is completed to the core system. 

For some changers with a locking pin, you would either)
a) Operate the locking pin when 1 position away from target, wait for it to drop. Check the position sensor
b) Switch to slow speed when 1 position away from desired and wait for the locking pin to drop
c) Wait for the desired position, set the pin and reverse at slow speed until the locking pin drops.

Your components should really try to handle fault cases. (failure to clamp, failure to unclamp, pocket not found after a long period of looking) 
The G-code (ABORT, ....) command is one fairly neat way to do this because it automatically calls the ON_ABORT routine from the INI file. 

A HAL component can send messages to the user too:
linuxcnc.org/docs/stable/html/man/man3/rtapi_print.3rtapi.html

For example
I don't know of a way to trigger an abort from a HAL component, however. Which is not to say that there isn't a method that I don't know about. 


 

Oh, I forgot to mention, it is very important to debounce the position sensor pins with this kind of changer feedback. In fact something rather cleverer than a debounce would probably be better, based on the expected time intervals between pins being sensed.

Went to the shop No1 for a smoke, watched the sad Mazak covered in dust, so gave it a bit of thought, for now.
Not sure when i will have time to go back to it, but i am getting close, hopefully.
I might:
-remove the Mesa 7i84 from the control panel and replace it with a 7i73, i have one
-i need more inputs for the foot pedals that open/close the chuck
-tidy up the wiring, do the power stuff as now there are 3 sockets powering everything
-program some interlocks to prevent moving the back parts if the toolhead is to low, prevent using round tools if the part is held on the back side (probably the first option will take care of this)
-program the panel buttons to go through those interlocks
-maybe paint it other colors?
-
Yeah, i still need to find a hydraulic chuck for it, new was 7900 Euro a few years back, i can not afford that.
Finding a used one proved to damn hard, although i did find one once at something like 700 Euro (can not recall) and asked a friend to get it for me, but he did not !@#$%^&*()
I wish i could sent it to RotarySMP to have it cleaned properly, together with some toothbrushes!

To small, i think i need a 250mm one, with a center hole.
Thank you very much for everything.
Hvala ti puno, za sve.