Gossiger?

Yes, my Makinos have three tool change speeds and these are specified in the tool data page where tool lengths and wear offsets are input. A large heavy tool would be changed at the low speed and it is up to the operator/ setup person to make that judgement call unless it is specifically called out in the setup sheet. With misc values in tool definitions it would always be automatic and it would be set by the program.

What about sand blasting? Tumbling?

I have mentioned this before a few times and I'm bringing it up again. Having misc integers and misc reals at the tool assembly definition level would be extremely valuable. Here are a few instances were they would make us much more efficient. Safety: For those running cell systems that have tool numbers defined as a cutter, holder, and stickout combination with misc reals at the tool level you could assign a drop dead gage length or gage length window (upper and lower values). Via macros at the machine you could have the machine check the actual gage length against this assigned value and if the actual was too short (or long) it would alarm the machine. This would add a valuable layer of safety for those running cells or this tool numbering strategy Break detection: Ability to assign break detection parameters at the tool level. This would include specifying the break check routine and tolerance and it would be done at the individual tool assembly level. An indexable shell mill could have the inserts checked at the correct offset, drills would use the solid tool routine, drills and taps, excluding indexable drills would ALWAYS be checked, bull mills and end mills could have the appropriate offset entered to check at the correct location and IT WOULD BE AUTOMATIC, AT THE TOOL LEVEL. Tool life: Tool life could be set per tool, per project. If I am running steel at Rc50 I could edit the tool data in the program (not the master library) so it would set tool life and tool life monitoring every time the program was run. This could probably be done with traditional misc reals and misc integers but it would be better to have it at the tool level. This would make setting this data tied to the program and reduce the setup man/ machine operator burden and mistakes. Tool change parameters: Tool change speeds or other data could be set automatically by the program so large tools that need tool change speeds reduced could tie it to the tool assembly and make it automatic, reducing errors and oversights by the operator. Tool load: Tool load parameters could be tied to the indvivdual tool and this would be fully automatic and tied to the NC program. When a program was run utilizing the specified tool, load monitoring and parameters would automatically be set in the machine via macros. All of these things would require macros at the machine and simple post modifications but they would be extremely valuable. We use all of these technologies and they make our shop much more efficient. With misc reals and misc integers available at the tool assembly level all of this could be tied to the specific tools that need them and once implemented it would be 100% automatic. I'm sure there are a number of applications I missed here and the ones listed are only the ones we would take full advantage of. If anyone else has applications that would streamline processes I'd love to hear them.

I admit, I use Scotch Brite and don't see any issues whatsoever. If done manually with a little care, no problem. I wouldn't use a wheel on a buffer though, and I know that isn't what you were referring to. Tool holders wear out and over time the tapers become dinged, fretted, etc... and the wear inflicted by Scotch Brite wouldn't even be measurable.

Makes sense to me.

Here is what I do, though I'm no expert. The first operation in my program is a manual entry. This has the part offset location and sets the machine's offsets via G10 commands. If I need better accuracy I will follow that up with probing cycles that reset those offsets based on the probed values. I then program one face of the tombstone to completion and post is out as a stand alone program. I control the transformes at the machine via M198 master programs that have this format: G90 G10 L2 P1 B0.0 (sets B value only) M198 P100 /2 M0 G90 G10 L2 P1 B90.0 M198 P100 /2 M0 etc... This is inefficient due to extra indexes and tool changes, etc... but I have parts moving through the machine. I will then set up another operation group that consists only of rotated transforms that all reference the original program. I will strategically transform based on index position, tool, etc... to hit all four sides of the tombstone with minimum tool changes and indexing. The original program stays 100% intact so I can always post the stand alone program if I need to run on one side only. The transform operation group might consist of 4-8 transform operations and these post with zero hand edits. Once the transformed program is ready to go I modify the M198 master and insert it into the queue on B0.0 only.

MA Ford 134 series will beat that. With 3/4" 3-flute I am removing 100 cipm conservatively and 180 cipm if I really want to get after it. At 180 tool life needs to be monitored but at 100 it will run forever.

+1^^ I don't think it can be done. My machines will not let me but I haven't changed the channel to do so, but I can't put files in the data server DNC queue while they still reside on the USB stick.

Thanks for the heads up, I hadn't even installed that utility... I went ahead and ran the optimization and the CPU came out at 4.7 GHz for one computer and the other is at 4.2 GHz. Funny thing is that the slower computer actually posted a better time by a few seconds than the faster one. The faster CPU posted 3:52 which is about 30 seconds faster than before so I'm happy.

I'm running the same processor and motherboard you are running along with water cooling. Where did you go to get info on overclocking? Also, care to share your settings?

I wouldn't really be doing that much of this work. I have a good friend that is an engineering contractor (mechanical engineer) and he is extremely talented and he lives for these sorts of projects. We work very well together and our skill sets compliment each other very well. One project we collaborated on was completely rebuilding and fitting and existing 6-axis CNC grinder with a new xxxxor (Faygor, LOL) control. I made most of the parts and he fitted the control and wrote the entire ladder, from scratch without a software aid such as Proficy. This was the first time he had ever dealt with a CNC and he nailed it. He went on to create macro based parametric programs for grinding the line of tools his customer planned to make on this machine (end mills, ball mills, tapered end mills, etc...). When all was said and done the customer was grinding ball mills down to .015" and the final tab was just under $80k complete IIRC. That included the purchase price of the original grinder ($30k). This endeavor is pretty much 99% contingent on Makino's willingness to support it. I have emails and calls into the applications/ automation department and they are reviewing some of these systems. This is all a ways off so all I am really doing in checking into feasibility, nothing more. I see a number of challenges and if I can come up with solid, viable solutions to these I will go this direction. If not I will come up with a different path.

I wouldn't touch that with a 10' pole. A system like that has the potential to generate some serious cash, so why are they selling it? Are the maintenance costs and down time becoming significant to the point where it is costing enough in maintenance and lost revenue to justify a new replacement? That would be my guess. I wouldn't want to be the sucker that takes on that system complete with past crashes and the maintenance burden it would bring. Notice the tool change door (dinged up)? To me that is a red flag. It has been run hard, if not abused.

I'm just not intimidated by the tool magazine. Really it is pretty simple. The tool change arm remains unchanged, the magazine gets the tool into position, tells the machine it's there, and the tool change arm executes its cycle. Everything is pretty much single axis and positions are verified by micro switches and/ or proximity detectors. Motion is executed by solenoids or pneumatic cylinders and it can be broken down to very basic, discreet functions and motions. It isn't brain surgery.

If the matrix system from MAM could be fully integrated and 99.99% reliable I think it could be a better system than Makino currently offers. Makino maxes out at 320 tools I believe and the cost of that system is ~$200k (guess). The MAM system starts at over 500 tools and is expandable to over 800. The IFs above are BIG ifs, but I will spend a considerable amount of time vetting these solutions to make sure they will actually work. Financially they are very viable however and well worth checking into. Two machines in a cell system with up to 1600 tools available between them would be really bad@ss!

Right, but can they fit one of those to a Makino in the field?

The MAM-L40-532 tool matrix system with 532 tool capacity comes in at just under $200k after all is said and done. VERY attractive if you ask me :-) I'll post more info and results as I get them. http://www.mam-maschinen.com/

We'll see. It might be more than $200k for one machine but the second should be considerably easier to integrate. Right now I'm just exploring options. I do like the OEM matrix system best from a reliability standpoint but it never hurts to explore other options and see what is out there. One thing I like about these is some of the systems go to 500 tools and beyond and I am sure those are more than $200k but there is a ton of value there and Makino doesn't even offer that from what I know.

No, but I do have calls in to Makino and RFQs out to the various companies.

One thing that is a little odd is if you want to save a stock model as a STL it is under 'toolpaths/ stock model export as STL. They are pretty intuitive really, just poke around for a bit and everything makes sense, setting and function wise.

The next step in our shop will most likely be adding a pallet system and that is a major expense in itself. Dropping another $500k+ on a machine with a larger magazine will not be an option and selling my current machines and replacing them with machines with larger magazines will be a tall order as well (dealing with selling, financing, rigging, etc...). I think adding a third party tool magazine will be the easiest and most economical solution as long as the finished product works well and is bulletproof. I really like this solution that was pointed out above. http://www.mam-maschinen.com/

I saw my high school employee hit cycle start on a new program with the machine at 100% rapid. He will not do that again hopefully. When stuff like that happens I try to make it memorable with being an @sshole because I really don't want it to be forgotten.

The machines have the 60 tool ring type tool changer and they are not expandable. I got to thinking about this the other day. With a robotic arm and RFID and some creative macro work a system could be built where the robot loaded the tool in the magazine as needed and used RFID to scan all of the data in to the control. I figured before I put a ton of time thinking about this I might as well look into what is out there. I agree that the Fastems system is painfully slow and probably more expensive than a new 313 tool machine but I like the concept. What I would be looking for is a system along the lines of what Newbee posted.

Yes, I have been investigating this very concept but I figured I'd have a look at what is out there.

Anyone have any experience or knowledge of these? https://www.youtube.com/watch?v=_sqTyvNRZdg Both of my machines have 60 tool magazines that are not expandable and this will become an issue when we get into a cell system. This looks promising as a third party solution.