The Online Community About Exciting CAD Technologies
Since we work with SpaceClaim we are very happy with the ease of working directly in
3D. However we have some problems with the way the filestructure is composed. It
complies with the so called Microsoft Open Packaging Convention. These files are
actually zip archives with a special structure, the contents of which are primarily XML
data. Problems for us arises when we create drawings of the parts, assemblies or
subassemblies. These drawings are positioned in the same file as the related part
or assembly. When, during the process of developing new products, you have to generate
drawings of the parts/assemblies. That is, a drawing is only visible in an opened
part/assembly and cannot be opened separately. This is very annoying when you want
to find different drawings you want to check or print. You always have to open the
related file to find the drawing. Because you don’t always remember where the drawing
is located (was it in the part file, the assembly file or the subassembly file, or was
it a part used in an other design?) it gives a lot of waisted time to find the drawing.
Better would be when the drawings where saved in a separate file (or a copy file related
to the original file). When I look at other 3D software like SolidEdge, Solid Works or
Inventor, the drawings are generated to a separate file with a *.dft or *.drw extension.
The great advantage is that you can put the file in a separate folder, together with all
related drawing files of the design. This makes it easier to find and check or print the
drawing. I really hope I that any one encountering this problem also, gives some reaction
on this of even come with a better solution. In the end I hope that the developers from
SpaceClaim will see this problem also and come with a solution on short term. The more
support from members of this forum, the better the chance they will react. So please,
give me some feedback….
I think Willem is using the PDF Creator tool to merge the multiple pages together into one document. I have acrobat on my machine, so I could do it with that, still doesn't make it any easier.
I used to use a command line pdf tool called PDFTK.exe. I still use it for automated PDF tasks.
There is an option to print all open sheets in one go, be it to paper or to PDF if you have a PDF printer installed. It is found in the print properties.
In the save as setting for pdf I set it to "Facet Only" and it seems to work. I haven't been able to get the "Geometry (B-rep) setting to open in Acrobat. Also I override the units and set them myself. I have found the units get screwed up if you don't. One more thing is in Acrobat if you right click on an element in the structure tree you can "zoom to" that element, so if don't see the model you can zoom to it.
"Also I haven't had any luck generating 3D PDFs. A file gets created, but it appears empty when I try to view it." (Paul Bock)
It works. Open the PDF in acrobat viewer, then go to the tree, right click on the root part and choose "page width" or so in the context menu. It appears the model is not always centered in the 3D PDF, so it appears out of sight, though it is still there.
I save a 2011sp0 SC model as PDF using the "Geometry(PRC-B-REP)" option. When I try to open with adobe reader 9.4.2 I get an error message that says "A 3D data parsing error has occured"
If I use the facets method it does work.
I was hoping to be able to exchange 3D data using the BREP method.
B-REP doesn't work here, either.
I wish it would, as I could make good use of it.
(Paul Bock) "We have also run across problems opening certain assemblies if in the last session, new components weren't saved. One assembly I worked with wouldn't allow the missing components to be deleted or replaced. Very annoying."
Replacing a component by itself does not seem to work. Try this as a work around: Replace the missing component by any old small SC model of your choice, then delete that. Now you are free to import another one, or in this case maybe a saved version of the missing one.
The problem was that when right-clicking on the "missing component", there was no option to delete or replace component. When loading, it gave us the option to find the component, but locating an old version of the file, or a dummy one of the correct name, we would get a "wrong version" or something like that. I no longer have the file so I am trying to describe the behavior and dialog box verbage from memory.
we have run into this a couple times over the couple years we have had SC. I have never spent enough time to figure out what was happening.
I have more info now, as I built a test case for people to try.
I built a simple part called block.scdoc. Then I built an assembly called test3.scdoc that uses block.scdoc.
Now put the original block.scdoc in a separate folder. Without doing anything with the assembly file, use a new session of SC to create a new block.scdoc part. Store this new part local to the test3.scdoc assembly.
now try to open the test3.scdoc. It will try to open the "new" block file and will give you the error message " The target file is not a version of the correct file". It will give you the option to go find it. If you say no, you will get a structure with an unloaded component. If you browse to where you hide the original block file, it will open like normal.
The problem comes in when you don't have a copy of the "original" file that the assembly is looking for.
If you ran through my little test and select "no" when asked if you want to locate, you get the "not loaded" item in the structure tree. Right clicking this item doesn't let you delete it. For some reason in my test case, I am able to replace the component with any old component and it works. For some reason on my real-life file, it doesn't work. But in the real-life example, the files were converted from step. I don't know if that hsa naything to do with it.
my concern is, why doesn't it just accept the local block.scdoc file since it has the same name as what it is looking for? That is the behavior I would expect. And what is going on that it knows it isn't the original file. I also tested the idea of modifying the original file. SC is okay with this. It sees the modified original file as a good one. It somehow knows that it came from good stock!!
Yepp! SC files are in fact .zip files that contain a collection of files*, so when you rename an SC file you change the name of the zip-archive but not the name of the content, that is how SC knows you're cheating.
*) E.G. in XML format and in binary ACIS, each serving to store a certain type information from the model. You can open it by simply replacing the file extension .sdoc by .zip and unzip it. Use a copy. This could be helpful for file recovery.
Martin - Please help me get my head around the difference between the file name and the name of the content within?. I understand the zip file format and the xml data stored inside.
I also noticed that they use zip for the file structure, not for compression. You can get pretty good zip compression on scdoc files when you zip them again.
What I mean by get my "head around this" is, what operations rename the content without changing the filename, what changes the filename without changing the content, and is there a way of changing both.
(paul Bock) "But How would indicate in the SC document which sheets are for which drawing? And some of the drawing properties like "sheet X of Y", must get screwed up in this arrangement."
In the final detailing stage I assume you work with externalized components, at least that's what I do. To create two sets of drawings, create two new designs, say "Customer drawings" and "Shop drawings". Now insert the part in question into both of them, and create the drawings in there.
Works well, though for one level deep only. Unfortunately. Still you can have two sets of drawings at least of the component level. I started experimenting with moving views of deeper levels up to sheets on higher levels, but am not yet done with it regarding the implications that has for references.