Mazak Micro Slant 15 Retrofit

More
16 Mar 2023 19:28 - 16 Mar 2023 19:33 #266856 by smc.collins
the emco turret comp has almost no error detection, and also doesn't compile. 

go look in hal examples, i wrote a robust, error detecting, estop capable tool changer for my lathe, and a few changes to the motor control scheme would make it work. 

it's a huge upgrade in terms of safety and capability over the emco program 

I'm also willing to commit some e time to making it work, maybe i buy a Mazak or similar lathe in the future ??

 
Last edit: 16 Mar 2023 19:33 by smc.collins.

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

More
16 Mar 2023 19:53 #266858 by tommylight
I did read about your component, but never had time to try it.
Also never got time to test the carousel component, shame on me! :)
Your persistance deserves respect, for sure.
Still, if i get the chance, i will test both of those.
Thank you.

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

More
16 Mar 2023 20:21 #266862 by smc.collins
it'll need to be modified to work with the Mazak, and I'm more than happy to help with that process.

then there's mazak turret program and then 1 less to create
The following user(s) said Thank You: tommylight

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

More
17 Mar 2023 04:47 #266884 by dctrytsman
Thanks for the help .I would really appreciate the help with your Cincinnati program .I am going to try the carousel and emco components anyway just to see how it works .Please let me know how to implement your program .

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

More
19 Mar 2023 10:31 #267075 by andypugh

1.tool position 1
2.tool position 2
3.tool position 3
4.turret clamped position
​​​​​5.turret unclamped position
6.Index sensor
7.turret pressure down sensor

Outputs :
1.Turret unclamp 1
2.Turret unclamp 2
3.Turret turn clockwise
4.Turret turn anti-clockwise

 

I think that this should work with the carousel component. I would connect iocontrol.0.tool-change to the unclamp output, and (probably) carousel.0.enable to the "unclamped" output, so that the start of tool change unclamps the changer, and then the carousel component only tries to move when the system is unclamped. 
A little more thought is needed about the iocontrol.0.tool-changed which is used to signal that the change is completed. My first thought was to connect to the carousel.0.ready pin, but that is likely to be "true" until the clamp releases (as above) so would immediately end the change.

You sound to be fairly comfortable with ladder, so maybe a hybrid solution of using carousel to calculate the position and motor direction commands, and ladder to wrap a release / clamp sequence around, that?

 

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

More
20 Mar 2023 11:45 #267135 by smc.collins
why build a rube Goldberg machine, when i can change a few small  things and there's a dedicated hal component ???

this is why the Linux ecosystem is a fucking mess.

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

More
20 Mar 2023 12:01 #267138 by andypugh

why build a rube Goldberg machine, when i can change a few small  things and there's a dedicated hal component ???

The carousel component started off as an attempt to write a universal toolchanger component, and I got quite a long way down that path before realising that it wasn't going to be workable. 
The problem is that there are so many possible tool change sequences, some of which require axis movement. 
It is also preferable for a tool change sequence to be able to signal to the interpreter that there has been a problem, preferably with a useful message. 

So, I set up the carousel component to handle the parts that are tricky in Ladder / Gcode, specifically interpreting a variety of encoding schemes, handling homing on those that require it, and controlling the motor movements. 

The rest of it, in most cases, is better handled by Python or G-code. In the latter case the option to use the (ABORT, The tool arm did not retract) syntax in a G-code remap allows the system to halt and report a fault. This is not something that can easily be done with just a HAL component. 

You are right about Linux, in the sense that there is a philosophy of using systems of simple tools rather than one complex tool. 
tldp.org/LDP/GNU-Linux-Tools-Summary/html/c1089.htm



 

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

More
20 Mar 2023 15:33 #267156 by smc.collins
the rube Goldberg machine is spreading out control code, everywhere in the system. having it in the hal component simplifies debugging. 

and until there are a bunch of hal toolchanger components, there will be lots of pain, but avoiding the obvious, making toolchanger components, it's going to remain a shit show. 

there's a bunch of design  but .ost of them are relatively similar. 

and I'm offering to actually write the code, because using python, gcode, and hal to control the tool change, when it can be done in 1 component is insane. it's also very difficult to debug.


what I'll probably end up doing is creating a suite of hal.components that can be stacked up into a hal.file to run a tool changer. 

but first you have to start crafting the components and getting them working. it's a critical mass problem and avoiding the work isn't going to make it better. it's a grinding suck fest  but so is anything that's difficult. you just have to do the work and then eventually it gets easier.

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. 
The following user(s) said Thank You: rodw

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

More
20 Mar 2023 16:59 #267167 by tommylight


this is why the Linux ecosystem is a fucking mess.

Mind the language.
Could have used # or @ or something like that in between.

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

More
20 Mar 2023 17:02 #267169 by tommylight

.... because using python, gcode, and hal to control the tool change, when it can be done in 1 component is insane. it's also very difficult to debug.

I have to agree, i had to use this a few years back, was not easy.

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

Time to create page: 0.152 seconds
Powered by Kunena Forum