detailing in spacelaim

I used SC some months, and it work very well to create in 3D. But to detail in 2D, there are some imperfections :

-I can just use 1 format between the same file.scdoc.

-I can' t have 2 or more parts on the same drawing.

-When I have a drawing with lots of sections and details, it works slowly.

▶ Reply to This

Replies to This Discussion

Permalink Reply by Poorvesh Mistry on March 16, 2010 at 10:02pm

Hello Wim,

SpaceClaim was a software launched with an intension of reducing data loss caused between CAD & CAE software. With a wide variety of CAD file formats supported & making IGES files editable with intense flexibility (usually known to be a dumb model file), they entered into 3D conceptualization. But yet the software is not meant to do complete detailing for manufacturing.

The best thing to do is save the SpaceClaim files as ".sat" file (ACIS kernel) & import the same in AutoCAD and do the detailing. For 2D detailing AutoCAD is the best.

▶ Reply

Permalink Reply by Paul Bock on March 22, 2010 at 4:52pm

I desperately hope this is not the official opinion of SpaceClaim. This part of SpaceClaim is the main factor keeping us from more fully embracing the product.

To add to Wim's list, I desire the ability to create exploded assemblies, and assemblies with multiple orientations
(such as folded, installed, etc states)

▶ Reply

Permalink Reply by Gabhan Gibson on March 22, 2010 at 7:27pm

I would have to agree with Paul on this. For me, an attractive feature of this program is to see immediate updating in the 2D drawings when making changes to the model. Since there may be many drawings associated with each model, I cannot fathom why I would want to go through the process of redrawing from the model in another program each time the model is changed, often in small and gradual ways. It would be better if we saw SpaceClaim mature and incorporate advanced and innovative drawing features, much like it has in modelling. In my mind, this would attract a base of users who cannot adopt SpaceClaim in its current form.

▶ Reply

Permalink Reply by Paul Bock on March 24, 2010 at 7:12am

Thanks to Gabhan's post for making me think of another variation. I think was Gabhan's idea, but here it is more exactly.

I might have an assembly model of a product for which I need two seperate drawings. The first is the detailed assembly drawing for whoever manufactures the product. The second may be a "sales" or "interface control" drawing. The second would have different information represented than the first. And these are two seperate drawings, not seperate sheets of the same drawing.

▶ Reply

Permalink Reply by Matteo Pellizzoni on April 30, 2010 at 12:59am

I completely agree with Paul.

▶ Reply

Permalink Reply by martin kopplow on March 25, 2010 at 9:28am

Redrawing in another application is no option for anybody involved in such things as 'development' or 'research', as these are highly dynamic processes that do not allow taking the time to do it over in another program. That approach, I'm afraid, will only be suitable for government sponsored historians (or most government departments in general).
It is necessary to keep the drawings linked and updating with the model. Spaceclaim does that very good and very fast which is one of the most important reasons I want our manufacturing preparation team to jump on the Spaceclaim users bandwagon.
Right now, they use a system that also has it all linked, but requires annoying 'redraw' processes every time changes are made. Even that is already too slow, besides it can be forgotten.

I find the detailing options in SC are already quite good. If I had to set up a wish list, though, the top ten would look like what you can see below, and the items on the list would be usability oriented in the first place:

1. Named sheets, named sheets, named sheets.
2. Independent page format for each drawing.
3. Visibility settings of drawings should be fully independent from the component settings, to allow different setups for multiple drawings per component, and not to destroy a drawing composition when visibility edits are made to the component. That would then enable drawings of different configurations off the same component, too.
4. Auxiliariy views and section views in deliberate angle or along a deliberate curve or set of lines drawn on the referenced view.
5. Better method of dimensioning the extents of objects even if there is no point or modeled edge, but just a projection of an outline. (Think of dimensioning the outer diameter of a bubble without a section view ...)
6. The auto balloons should always orient on the view frame, and the view frame should be user resizeable (thus also allowing to create incomplete or broken views of the component).
7. BOM should be customizable and have a page break option. Ever tried to print a BOM that has 286 items? I just did the day before yesterday. If you have an LFP, it works fine on an A0 oversize portrait plot using a 3pt font. Alternatively, the BOM could be automatically stored in a spreadsheet document in the SC file container. We could just print that, then. It is important it stays linked: Export is not any option.
8. Filling in the title block should be further enhanced, maybe by an input mask or just by making the customized fields a bit more responsive and flag their identity in a toolhint bubble on mouseover.
9. Hidden line mode should also work with large assemblies.
10. Option "Print all drawings" respectively "Export all drawings to one PDF".

Best regards,
Martin

▶ Reply

Permalink Reply by Gabhan Gibson on March 25, 2010 at 4:06pm

Martin,

That is a superb list!

▶ Reply

Permalink Reply by Frank D on May 19, 2010 at 10:40am

Martin
I looked into the named sheets issue (your #1 item)

There is a significant problem with the request; It Contradicts American & ISO drafting standards, which state that sheet numbering should be like book page numbering, sequentially starting from 1:
- Create sheets “Sheet 1” and “Sheet 2”.
- Names in tree and numbers in title block: “Sheet 1” / “Sheet 1 of 2” and “Sheet 2 / “Sheet 2 of 2”. - Consistent and as per standard.
- Delete Sheet 1.
- Names in tree and numbers in title block: “Sheet 1” / “Sheet 1 of 1”. Consistent and as per standard.
- Customer requirement for names and numbers: “Sheet 2” / “Sheet 1 of 1”? “Sheet 2” / “Sheet 2 of 1”? Both seem wrong…

Would anyone care to clarify the requirement, so that we can give people who want standard functionality something standard, first and foremost?
F

▶ Reply

Permalink Reply by martin kopplow on May 20, 2010 at 2:13am

Frank,

I see your point. It appears it is required to keep the numbered sequence of the sheets for reasons of consistency and standards. Standards are nice and the responsibility for not following them must be left in the hands of the individual user. As a software provider you cannot decide in his place.

Still, we have the every day practice side of the issue:
For a user who has been creating dozens of sheets during the past few days it is sure hard to remember what was on which sheet, especially as all the sheets created in an assembly also appear in their usual sequence if he opens only one sub component*, which, per my simple logic, should only 'have' those sheets that were created from it's content.
I already like the tags that appear on mouse over in the sheets section of the component tree and can be used to identify the related component. Also, it am using an insert field in the title block to print the name of the component in the drawing.
This leads to a situation where people from the shop, suppliers or clients would come to my office with a printed drawing and request clarification or propose changes to the specific part. They have the numbering "Sheet 17 of 92" printed on the drawing, but that is most probably no longer true, as new sheets have been created in the mean time, or sheets no longer needed may have been deleted. I do not know any person in the industry who can afford to finish ALL the drawings before SOP. So "Sheet X of X" is of no practical use and people can only reliably identify the part by the component name, because that one is fairly unique, descriptive and understandable for humans.
Now the designer will have to identify the sheet. That requires him to browse them all (mousing over them) and read all the tags, as their true secret sequence cannot be derived from the numbering. If sheets could be sorted and displayed by part name, it would be much closer to life. Also, if there was a 'reveal connected sheets' option in the component context menu or elsewhere, he could then start his query from the easily identifyable component and use that way.

I can imagine the standard sheet numbering still being in place as an option to toggle with sheet naming, I can imagine the names being appended to the numbers, too. As there might be more than one sheet per component (one overview, one with projections and one with details, EG) these should also be distinguishable, which would problably mean allowing the user to customize the sheet names up to a certain point, maybe leaving the numbering intact.

BTW.: There is one more thing that is probably conforming to standards but defies live logic:
The item numbers. They also change as new parts are added and are not unique through components. An item that was number 12 yesterday, might be number 13 today, as a forgotten washer has been added to the component. An item that is ballooned as number 12 in a component can be number 1234 in the assembly, which makes it extremely hard to create consistent assembly instructions. This is surely not easy to tackle, though I could imagine a 'use unique item numbers" option in a root level component.

Martin

Attachments: