You are not logged in.
Pages: 1
Some inquiries on IP file content instigated this post.
VERICUT In Process (IP) files are a snapshot of the VERICUT session in its exact condition at the time the file is saved. The intent of this file is to allow a user to exit VERICUT, then reenter sometime later and restore his VERICUT session to the exact same condition it was in when he exited earlier. Think of it as the "coffee break" option.
It may also help to know what IP files are not. IP files are not:
. Archive or storage files used to store simulation results for later reference. They do not transfer between versions, and are system dependent.
. Master or template files used to begin a new simulation operation.
. A file to transfer from one setup to another, because of their version dependency.
Their only intent is to save a VERICUT session's status so a user can restore his session in the exact same state. But it must be with the same version, on the same computer type, and with the files in the same locations when the IP file was saved.
The IP file is primarily a binary image of VERICUT's allocated memory at the time the file is saved. It is not like a CAD/CAM data file, with data structure and a database schema. It is simply a binary memory dump. Hence it is not transferable between different kinds of computers, and is not transferable between different VERICUT versions. It is not very flexible because of its design and intended use.
The IP file also contains the ASCII project file it references, so an IP file can be opened like a project file. This is the only "archive" usage of an IP file. But in this usage it is no different than a project file.
Offline
After some further investigation, the above posting has a small inaccuracy.
IP files do not require that the reference files (machine, control, etc) reside along the same paths as when the IP file was created. However, a bug caused the find-file logic to fail and so it behaves this way.
This problem will be fixed in VERICUT 6.1.1 so that files paths will be reassembled using the find-file logic. See the post http://www.cgtech.com/forum/viewtopic.php?t=794 for information on the find-file logic.
Offline
Thanks for the detailed explaination Bill.
I made changes to a machine file once and it didn't seem to effect the machine when I opened an IP. The only way I could update the machine in the IP was to call the machine back in after I opened the IP.
I was under the impression that the IP saved it's own copy of the machine and control.
Offline
Roger,
You are correct and the behavior you describe is correct. The IP file contains the "in memory" version of the machine and control. The machine and control file (the things on disk) are not read when the IP file is opened. Thus, after opening an IP file, the "in memory" version of the machine and control, whatever settings were in effect when you saved the IP file, will be used.
If, after opening the IP file, you do something to re-load the machine file, then you get whatever is available on disk at the time you load it. I think that is what you're describing.
The STL files that represent the "physical" bits of the machine are not saved in the IP file. Thus they must be loaded when the IP file loads. The paths to the STL files, as saved in the IP file, must match the current paths to STL files. Or VERICUT can't find them. We're working on a solution to this path problem.
I hope the above is not too confusing. It makes my head hurt. :?
Bill
Offline
Hehe, thanks for verifying that for me Bill. It was confusing to me too. But your discription of the ip being a snapshot of what is in memory made it a little easier for me to swallow.
This is complicated stuff, but I love a challange.
Vericut is one of the most valuable tools in my toolbox.
Offline
Pages: 1