Cell is almost up and running, questions...

[Bob W.]

I am in the process of populating the tool library on the Makino MMC2 and I was curious how people do set the information file, format, etc....  Ideally there would be tool information (cutter, holder, stick out) with a graphic view (CAD or photo) of the configuration.  I'd love to hear what people have done, seen, or worked with that worked well and didn't take months to get in place.  Vericut is my current master tool library but there isn't a simple way to export a report of a single tool.  Vericut runs the simulations so I know the tool reports generated by it are 100%.  I am hesitant to export reports from Mastercam due to possible mismatch, etc...  This will be used for operator reference on the floor since there will be several terminals throughout the shop (machine, WSS, tool crib, office, etc...).  Here are the fields I'd like to cover in the information files:

 

Cutter description

Cutter part number

Cutter stick out

Holder description

Holder part number

Coolant style (TSC, Flood, air, etc...)

[mkd]

Vericut makes a nice complete tool list. Not sure about a single tool, or if possible to export all your parameters

 

Sent from my SM-G900V using Tapatalk

 

 

[Mick]

Vericut makes a nice complete tool list. Not sure about a single tool, or if possible to export all your parameters Sent from my SM-G900V using Tapatalk

 

Vericut does indeed do a nice tool list. And it is very customisable. Unfortunately, as far as I am aware, it only outputs the complete list and not just tools used in the programme that is verified.

 

That is a function I would like to see (effectively, scanning a tool library, and then generating a report based on the tools being used only). Currently, when I build a tool list for our Multus, it outputs the complete library

[Watcher]

VERICUT can export a report with all tools used in a project, however you need to complete the verification the get it complete, instead of getting it before the simulation.

[Bob W.]

Right, I have Vericut and love the tool lists but this is for the library within the cell system.  We can have up to 10 functioning cell terminals active in the shop and an employee can open the MAS-A5 tool library and each tool has an information file tied to it.  This file can be anything I specify (Word doc, pdf, Jpeg, photo, etc...) and when looking at the functional tool it can be opened with one click.  The Mas A5 will track ALL tools whether measured and in the crib, in the machine, or just in the library.  We have 730 tools in our Mastercam library currently so I'd like to come up with an efficient way to create these information files.  They will be very handy once done but could potentially take months to create.

[betts]

Is there a reason you aren't using the MCX interface for Vericut?  This would negate the fear of pulling a MCX report and not trusting that is matches Vericut?

[Colin Gilchrist]

Hi Bob,

 

The Vericut Tool Library is coded in XML format. It should be pretty simple to whip up some kind of Script file to generate the data you are looking for. The biggest issue will be in creating the 2D drawing information. It will also really depend on how you create/import the data into Vericut. (STL vs. PLY vs. SOR). Vericut obviously has a method for creating a 2D profile drawing, no matter what underlying data source is being used...

 

Personally, I'd look into TclXML, but I'm probably biased, because TCL is fast becoming my "go to" programming language...

[Bob W.]

Just to clarify, I want to generate one page reports, per tool, that can be imported into the Makino MAS A5 cell control tool library.  This way, if the operators have a question about tool geometry they can pull it up at any of the cell control terminals that will be scattered about the shop (Tool crib, machine, work set station, etc...)

 

 

Hi Bob,

 

The Vericut Tool Library is coded in XML format. It should be pretty simple to whip up some kind of Script file to generate the data you are looking for. The biggest issue will be in creating the 2D drawing information. It will also really depend on how you create/import the data into Vericut. (STL vs. PLY vs. SOR). Vericut obviously has a method for creating a 2D profile drawing, no matter what underlying data source is being used...

 

Personally, I'd look into TclXML, but I'm probably biased, because TCL is fast becoming my "go to" programming language...

 

Maybe a script is the way to go.  I could simply send the data to a text file and not include the drawings or graphic view, then as time permits add the graphics later.  Maybe Excel, pictures can be added to Excel files pretty easily I believe.

[Bob W.]

Is there a reason you aren't using the MCX interface for Vericut?  This would negate the fear of pulling a MCX report and not trusting that is matches Vericut?

Yes, Vericut is the master because it never gets touched and it is rock solid.  I know the information for tool three will be the same in Vericut as it was last year or the year before.  I know a programmer didn't tweak the length to suit his needs to make it work.  Once a tool is put into a machine it might reside there for months and it will not be re-checked or reset during that time.  I need the confidence that the simulations will be valid and not be based on a tool library that may have been tweaked.  Vericut is to my tool library what the North Star was to navigators 200 years ago.

[Colin Gilchrist]

Bob,

 

Does the data have to live inside the Cell Control Tool Library? Why not just use Vericut exclusively to manage the tool data? I get that you want your operators to be able to bring up the tool definition rapidly, but why not just have them pull it up in the Vericut Tool Library?

 

If you look in the \VERICUT 7.3.4\windows64\commands folder, there are "short-cut" links. One of them is for "Shortcut to Toolman 64 7.3.4". This is the Vericut Tool Manager, and can be launched outside of Vericut. So your operator could pull up any tool, in the Vericut Tool Library, without having to Launch Vericut itself. It would also be one less data source to maintain...

[Bob W.]

Bob,

 

Does the data have to live inside the Cell Control Tool Library? Why not just use Vericut exclusively to manage the tool data? I get that you want your operators to be able to bring up the tool definition rapidly, but why not just have them pull it up in the Vericut Tool Library?

 

If you look in the \VERICUT 7.3.4\windows64\commands folder, there are "short-cut" links. One of them is for "Shortcut to Toolman 64 7.3.4". This is the Vericut Tool Manager, and can be launched outside of Vericut. So your operator could pull up any tool, in the Vericut Tool Library, without having to Launch Vericut itself. It would also be one less data source to maintain...

This would actually work really well.  How do I point that shortcut to my specific tool library when it opens?  Right now it only opens the tool manager with no library, I have to hunt for that and open it within the tool manager.

[Colin Gilchrist]

This would actually work really well.  How do I point that shortcut to my specific tool library when it opens?  Right now it only opens the tool manager with no library, I have to hunt for that and open it within the tool manager.

 

First, make sure your .tls file is located somewhere where everyone has at least Read access. I just tested this by putting a copy of the .tls file on one of our servers.

 

Go into the 'Shortcut to Toolman 64 7.3.4', and Right-Click. Choose "Properties".

 

In the "Target:" data entry field, there will be a path to the batch file in double quotes:

"C:\Program Files\CGTech\VERICUT 7.3.4\windows64\commands\toolman.bat"

Add a space character after the file path, then add the full path to the .tls file, also in double quotes. Here is a sample (though I modified the server name/folder, but it does work!)

 

When I launch the BAT file using the icon, the Tool Library with full path that I specified opens right up!

"C:\Program Files\CGTech\VERICUT 7.3.4\windows64\commands\toolman.bat" "\\our_server_name\Folder_name\Tooling_Backup.tls"

[Colin Gilchrist]

Boom! (Drops mic, and walks away...)

 

[Colin Gilchrist]

P.S., you can also "drag n' drop" a .tls file onto the shortcut (without the "library" path on the end of the Target string!!!). This will simply open any existing Vericut library in the Vericut Tool Manager. (This tip is for anyone using Vericut that doesn't have a single, dedicated library.) I'm in the Tool Manager quite frequently, so I tend to use the Drag n' Drop method often...

[Colin Gilchrist]

One more tip: when the library opens, there is a "search" function in the upper right corner, but this only searches the "Description" field. To search for an individual tool number, select any visible Tool ID in the list, and just start typing the ID number of the tool. I just loaded a library with several hundred tools. I typed in "501" and it jumped in the ID list to that specific tool ID number...

[crazy^millman]

Boom! (Drops mic, and walks away...)

 

 

Okay Colin pat yourself on the back.

[Mick]

Actually, Colin mentions a really good point. I have a customer that uses the Vericut tool manager as a standalone app. It works really well, and is really handy.

[Bob W.]

Boom! (Drops mic, and walks away...)

 

Microphone, not micrometer, right?  Thinking of a micrometer getting dropped gives me the heeebeejeebies... 

[Watcher]

We only use standalone ToolMan here.

 

We maintain a master library and reference components from it. We never have issues when we replace a component, because when we change a component in the master all tools in all libraries referencing the component are updated automatically.

 

Also, with this approach we eliminated duplicated components across libraries, and thus improved VERICUT performance because a given component is loaded just once in memory, regardless how many tools are referencing it.

 

I personally don’t believe in CAM To VERICUT interfaces when in comes to tool data transfer. Especially for turning tools. They create duplicated CAD models and don't play well with turning tools or boring bars. It $ucks. Building a master library and get rid of CAM to VERICUT tool libraries was the first thing I tore apart when I started here. The productivity of our programmers increased around 15% after 6 months.

[Colin Gilchrist]

Microphone, not micrometer, right?  Thinking of a micrometer getting dropped gives me the heeebeejeebies... 

 

Yes, microphone. I was just trying to be funny. I always treat tools like the precision instruments they are. Although, from some of your stories about workers you've hired, I'm not surprised you asked...

[Bob W.]

Yes, microphone. I was just trying to be funny. I always treat tools like the precision instruments they are. Although, from some of your stories about workers you've hired, I'm not surprised you asked...

I know the saying and the visual.  it was funny though when you wrote it the first visual that popped into my head was you holding a micrometer out and doing the drill and I was like "NOOOOOOO!".  Then I visualized doing a sliding catch...  I've been in the shop too long I think.