VERICUT and file management, from Irvine VUE discussions

BillH · 2007-03-19 22:05:31

At the VUE in Irvine last week I heard about and/or participated in discussions about managing VERICUT files. Most of the problems seemed to be site-specific, requiring site-specific solutions. However, some information on VERICUTâ€™s current file-handling capabilities might help lead a way to solutions.

When VERICUT opens a project file, it attempts to open files referenced in the project file (machine, control, tool library, nc program, stock stl file, fixture stl file, etc). VERICUT automatically searches specific locations in a specific order, attempting to find each file. We call this VERICUTâ€™s â€œfind-fileâ€ logic.

Additionally, the project file references files which also reference other files, such as a machine file that references stl files. The find-file logic is applied when opening these files as well. The file that references another file is known as the â€œparentâ€ file. For example, a project file is the â€œparentâ€ of a machine file it references, and a machine file is the parent of an stl file it references.

For the purpose of this discussion it is important to realize that a file name is made-up of two parts: the folder (or directory) path to the fileâ€™s location, and the fileâ€™s name. Added together, the path + name is commonly referred to as the â€œfully-qualified file nameâ€.

VERICUT searches for files in the following order:

. As specified by the fully qualified file name
. In the current working directory, using the file name only
. In the parent fileâ€™s directory, using the file name only
. In paths specified by the environment variable CGTECH_LIBRARY, using the file name only

If VERICUT is searching for a machine, control or tool library file, and the above search sequence does not find it, then VERICUT opens a file selection box, allowing the user to browse for the file.

If a file is not found VERICUT displays an error message in the logger.

If VERICUT finds a file in a location other than what is specified by the fully qualified file name, the fileâ€™s path is changed to the actual location where the file is found. The actual path is displayed in VERICUTâ€™s file summary and stored in the parent file the next time the parent file is saved.

The careful readers among you may have noticed that the last place searched is in â€œpathsâ€ specified by CGTECH_LIBRARY. The â€œsâ€ on â€œpathsâ€ is not a typing error. It is possible to specify multiple paths in CGTECH_LIBRARY. Paths are searched in the order defined.

As delivered, CGTECH_LIBRARY is set to the â€˜libraryâ€™ directory in VERICUTâ€™s installation. However, additional paths can easily be added by modifying CGTECH_LIBRARY in VERICUTâ€™s startup batch file (or UNIX script). For example, consider the following CGTECH_LIBRARY setting:

Set CGTECH_LIBRARY=c:\cgtech61\library;c:\myfiles\mylibrary;g:\bobsfiles\bobslibrary

When searching for a file (the file is not found as specified), VERICUT will look in the current working directory, and the parent directory. Then, using CGTECH_LIBRARY, it looks in the installationâ€™s library directory; the â€˜mylibraryâ€™ directory, and finally â€˜bobslibraryâ€™ directory.

If carefully configured, this mechanism can be used to painlessly move VERICUT projects to other computers with other directory structures.

Some more complex multiple user environments may require sophisticated external project management tools, and are outside the scope of VERICUT's file handling. These tools typically cost a few thousand dollars, plus a few thousand more for on-site configuration consulting from the software supplier.

But I hope the above information is useful for some of you.

Bill

Roger Bombassei · 2007-03-20 11:38:03

Thanks for the explaination Bill. It is very confusing dealing with these files all over the place. But I will print out this info and keep it at hand.

I also get confused when saving IP files. Is there a document that explains what info is being saved in the IP files.

And I wonder why I get prompted to save machine and control files so often. It seems like if every Vericut user is writing over the shared machine/control files, there will be a problem eventually. Also, if I didn't make any changes to the machine or control, why is Vericut prompting me to save them?

rklutts · 2007-03-20 14:15:17

Thanks Bill, I'll give this a shot as it sounds like it may do what I want. However, I need to know is there any other way to save just the file name in the project file other than manually editing the project text file and removing the path?

Ron

SergeV · 2007-03-20 15:52:45

Ron,

Use Info > File Summary, Copy all files (icon that looks like a diskette)

When copying the files, VERICUT will strip all the paths in the files.

DaveF · 2007-03-20 16:33:37

And I wonder why I get prompted to save machine and control files so often.

Roger, are you changing the visibility, or blanking specific components?

We talked about that at VUE also, as that changes the machine.
That is why people are changing machine files here.
I suggested adding several "Mixed states", and adding Blank to Mixed, to allow groupings of what is visible.

Going to work with the vericut I have today, If a programmer wants a machine with Base and X &Y blanked, is is repetativley using it, I make a copy of that machine and name it Cincy_Gantry_M22_Blank_Base_X_Y.mch

My machines files are on the network, and are write protected.

Ron
RE:

I need to know is there any other way to save just the file name in the project file

I think info > files summery > copy all files does that, but your Idea is a good enhancment, IMHO :wink:

DaveF · 2007-03-20 17:05:43

I would like to hear from others what they are doing for File managment, and network usage, and directory structure.

We use Catia, and smart team, a PDM system for checking in and checking out files is FREE :mrgreen: , but they quote 35 days at 1500$ a day to implement it.

I see PDM systems as necessary for a company like Boeing, or software developers like Catia, or Vericut. But, a small job shop can go broke implementing these fancy things.

we store everything about a part, on the network, filed by part number. with seperate subdirectories, containing various things, like center line files, posted data shop books, stl files, etc. That structure was created before I got here. I think it would be cleaner to have all files broken into operation subdirectories op_10, op_20 op_30, etc, with stlfiles pch, and apt and books for that op under that dir on the tree. a programmere could grab the op_50 directory, in its entirety, and work on it.

Some times, a good idea prompts a change in the directory structure. That breaks all the links.

or a 3,000 gigabyte server is added, and the Network drive letter changes.

NC Programmers, can be at the mercy of IT managers, yes?

I would also like to create a system where there is a work in progress subdirectory, as well as a released to the shop directory. If we wanted to add more programmers to one large project, this would help share files.

It can get confusing. :?

I suggested at VUE, that a check box or environment Variable would enable the working directory, to also slurp files from sub directories, if they exist. Of course, if there are multiple copies of the same named file in that path, my idea would tumble like a house of cards.

Hopefully, if such a feature was enabled, we could grandfather older files, and eliminate any redundancy as we go forward.

I would like to hear how others have approached multiple users sharing files without stepping on each otherâ€™s foot. And also directory structure.

BillH · 2007-03-20 17:46:24

This sure kicked-off some discussion ...

A few random items.

IP file content:
I'll post something separate in this forum in a bit.

Prompting to save machine/control:
Occasionally we change the machine or control file content between versions. If you are using a 5.4 machine file in 6.0, you will be prompted to save the file because the content changed simply by using the file in the newer VERICUT. That may be what's dinging you.

Saving path-less files
We're looking into adding a checkbox option in the "save" and "save as" File Selection Box, that tells VERICUT to strip the paths from referenced files. This is valid for project, machine, control, and tool library files, which all can reference other files. It is not valid for IP files (see separate discussion).

Bill

rklutts · 2007-03-20 22:32:00

BillH wrote:

This sure kicked-off some discussion ...
Saving path-less files
We're looking into adding a checkbox option in the "save" and "save as" File Selection Box, that tells VERICUT to strip the paths from referenced files. This is valid for project, machine, control, and tool library files, which all can reference other files. It is not valid for IP files (see separate discussion).
Bill

I vote to have it done this way. Having Vericut save it without the path info seems a better option to me.

Ron

vhubbard · 2007-03-23 14:31:39

Vericut file management, our version. (6.1) I have been asked by a few for an explanation of our process.
We have been doing this for years, but recent changes allow multiple directories in CGTECH_LIBRARY path definition. We no longer need to reference full path names in files when the CGTECH_LIBRARY contains a path to the directory where the file is. Each support file must have a unique name. Vericut should find any file that is in a directory defined by CGTECH_LIBRARY or the WORKING directory.

We have a master directory with all of our Vericut support files. This is set to "read only". Model files for machine definitions, subroutines etc are referenced by defining multiple directory paths in the CGTECH_LIBRARY variable.

We wrote a Perl based Vericut start utility. Our users drag-drop a directory on the shortcut to this utility. This directory becomes the WORKING directory. The stock, design, fixture, nc program and cutter lists are expected to be in this Working directory. A naming convention is used when users create these files. This allows the utility to identify the files automatically.

The utility determines the machine type from the nc program file name, defines the environment variables needed, copies 3 files, .mch .ctl .vcproject to the working directory. The .vcproject is edited on the fly by the utility to define the stock, design, fixture, nc program and cutter list files. User selected defaults related to speed and tolerance are also set in the .vcproject file. Then vericut.bat is run with this preset environment.

Variables we define before starting Vericut.
WORKDIR
CGTECH_LIBRARY (All directories with support files)
CGTECH_LICENSE
CGTECH_VCPROJECT
CGTECH_USERNAME
CGTECH_FONT_SIZE
CGTECH_CODEC_FILTER

Vericut.bat may have to be modified to convert some of the variables from this:

set CGTECH_LIBRARY=%CGTECH_INSTALL%\library\

to

if "%CGTECH_LIBRARY%" == "" set CGTECH_LIBRARY=%CGTECH_INSTALL%\library\

An enhancement has been turned in to have more variables checked for pre-defined values in vericut.bat. I HATE having to remember to change installed files.

You don't have to use Perl, Vbasic etc. Scripts could be used if you don't need to edit the .vcproject file.

After exiting Vericut the utility will clean up or remove .log, .mch .ctl and .vcproject files from the working directory if you want it to.

Why do we copy the .mch, and .ctl files? to prevent "access errors" that drive people nuts if they try to save one of the files.

We do define the nc program using a full path in the .vcproject. We have found the nc program may not be found in the working directory when Project, Gcode, Settings, Subroutine is defined. Users sometimes do this to see the subroutine code as it processes in the info window. Not often done so it is a minor problem to us with an easy workaround.

Our masters are safe and everything runs fast and startup time for the users is about 15 seconds.

DaveF · 2007-03-23 19:53:59

Thanks Mr Hubbard

That is a great description of your techniques.
I will study this a give it a shot, with the Vericut I have today.

vhubbard · 2007-04-20 18:45:50

One more thing on files and table locations. (version 6.1)
Tables can be defined in the .mch file and the .vcproject file.
The tables in the .mch file are ONLY displayed in Configuration, Machine Settings, Tables
The tables in the .vcproject are ONLY displayed in Project, Processing Options, Gcode, Settings, Tables.

While it appears there are two sets of tables, there is ONLY ONE USED.

Both areas can define the same table/locations. If defined by both, the ones in the .vcproject or Project, Processing Options, Gcode, Settings, Tables are used.

Both locations must be checked by users to see if defaults have been set for a table.

We want the users to change values in Tables under Project, Processing Options, Gcode, Settings. Theses are stored in the .vcproject file. We want them to leave the ones defined by the .mch file alone.

VERICUT Users' Forum

#1 2007-03-19 22:05:31

VERICUT and file management, from Irvine VUE discussions

#2 2007-03-20 11:38:03

Re: VERICUT and file management, from Irvine VUE discussions

#3 2007-03-20 14:15:17

Re: VERICUT and file management, from Irvine VUE discussions

#4 2007-03-20 15:52:45

Re: VERICUT and file management, from Irvine VUE discussions

#5 2007-03-20 16:33:37

Re: VERICUT and file management, from Irvine VUE discussions

#6 2007-03-20 17:05:43

Re: VERICUT and file management, from Irvine VUE discussions

#7 2007-03-20 17:46:24

Re: VERICUT and file management, from Irvine VUE discussions

#8 2007-03-20 22:32:00

Re: VERICUT and file management, from Irvine VUE discussions

#9 2007-03-23 14:31:39

Re: VERICUT and file management, from Irvine VUE discussions

#10 2007-03-23 19:53:59

Re: VERICUT and file management, from Irvine VUE discussions

#11 2007-04-20 18:45:50

Re: VERICUT and file management, from Irvine VUE discussions

Board footer