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….




Willem Wagelaar

Views: 1243

Reply to This

Replies to This Discussion

Are you suggesting duplicating the part geometry into each of these drawings?  Doesn't that make it harder to maintain the same geometry across different parts. 


Or are the seperate drawing designs referencing the original geometry, in a separate design file?


I am feeling confused on my understanding of what can go where between geometry, drawings, and the scdoc container(s).  I haven't seen good documentation on these concepts.

Paul Bock: "Or are the seperate drawing designs referencing the original geometry, in a separate design file?"


It would not make sense to actually duplicate geometry. I was referring to referencing one model into different design files only created for the purpose of creating different sets of drawings. This way, making changes to the model would be reflected in all of the drawings.



Now since you can store visibility of individual parts with the drawing in the current release, this procedure described above is obsolete. Just make another drawing and compose it as needed, then save.



Yes, it does appear that you can create multi-detail drawings now, but it seems to be limited to internal parts.  It doesn't work with external parts from my experience.  Maybe that makes sense though.

Yes, it probably makes sense. You can, however, create two or more drawings off one component, and while both are attached to that same component, you can have different visibility settings or graphics prefs for each sheet or even view, so a component can now have say a shop drawing and a customer drawing attached and both update as you make changes to the model.

I think that is pretty useful.



I agree.  It is very useful.


Now if SC would allow broken views...  ;-)


Yes, that would be very nice, and I am sure it will come rather sooner than later, as it has long been on the wish list. It appears quite some users have come to use Spaceclaim to keep the master model and issue shop drawings, for it's flexibility, rather than use more complicated CAD. Spaceclaim will have to support these, too.

For businesses like ours, it turned out that though it was meant to be a communications and file exchange tool first, it has the potential to be the spider in the web, and developed towards being the the primary system, with only a little support from other, more specialized systems, should need be.



To continue adding to my list of frustrations with SC.  We are now having problems when we go to save.  We get a message that says that we can't save because we have run out of memory.  At first I thought this might be legitimate because I was on 32 bit XP. 


SC support told me that the memory usage is from the volume of chnages in the "undo history".  Then they added the "purge" feature to the undo list.  I can now undo the memory usage for the undo history, but SC doesn't seem to give back all of the memory.  And purge hasn't helped me with the inability to save once I get this "ran out of memory" problem. 


SC support says they are considering adding an autosave feature, but I am concerned about how that would work if I don't want my changes saved.


Now we are set up on 64 bit machines with 12 Gigs of ram.  And we still get the "ran out of memory" problem when SC is only using about a gig, and there is plenty of free memory available.  So I am confused why it is doing this. 


A common thread among the "ran out of memory" problems seems to be caused after working on drawings of assemblies. 


And why does SC need more memory to save a file anyway?? 


We have been going through a test period on a couple projects and my guys are getting scared of SC because of the potential of not being able to save after they have worked on a top level assembly drawing.  This is not good.


We are still having problems with the proper migration path from a conceptual assembly with component names like "screw", "spring", "plate", etc. to externalized parts with real names. 


The reason this is so frustrating is that the rest of SC is so clean and wonderful to work with. 

Hi Paul,
I'm aware of the undo history issue that you're


I wanted to update that we have developed "PDF Export Addin for SpaceClaim". More details at




Novedge Special




© 2014   Created by WikiCAD.

Badges  |  Report an Issue  |  Terms of Service