For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings

 

Need to speed up your development?
Have a look at our:

Samples & Tools

 

Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Related pages

Overlapping parts in STEP file

Anonymous's picture
Forums: 

Hello all,

I now have a STEP file reader/writer that appears to be mostly working OK, except in the case when parts overlap eachother. For example:

case 1: Suppose an assembly contains three child parts which do not overlap. With a STEPControlStd_Writer object I first write the three children to the file, then I write the parent assembly. The resulting STEP (AP214) file correctly contains the three child parts and the parent assembly which refers to each part.

case 2: Suppose an assembly contains three child parts such that the third part overlaps the first two. Using the same writing code that I used in case 1, the result is a bit different. The first two (non-overlapping) children are written to the file normally - that is, I can follow the references from the NEXT_ASSEMBLY_USAGE_OCCURRENCE of both children within the assembly back to the original part to which the part instance refers. However, the third child is written as a NEXT_ASSEMBLY_USAGE_OCCURRENCE that refers to an exact duplicate of the original child part. A child written this way has no references to the original part (as far as I can tell). Is there a way to tell the STEPControlStd_Writer object not to worry about cases when the parts overlap? I do not know if I will encounter this problem when I read objects or not, but if I do, can I instruct the reader object not to worry about this case either?

Thanks,

-- Shaun Bloom

Betenev Andrey's picture

Hello Shaun,

> Hello all,

> I now have a STEP file reader/writer that
> appears to be mostly working OK, except in
> the case when parts overlap eachother. For
> example:

Please explain what you mean under the term 'overlap'. If you mean geometrical overlapping, STEP translator has nothing to do with. If you mean sharing of subshapes (e.g. if some shape is included in assembly as component several times), this sharing is preserved when reading and writing STEP files.

Note that sharing of subshapes is not allowed in STEP except sharing of components of assembly. Hence, if e.g. two solids share one face, this sharing will be lost when writing.

> case 1: Suppose an assembly contains three
> child parts which do not overlap. With a
> STEPControlStd_Writer object I first write
> the three children to the file, then I write
> the parent assembly. The resulting STEP
> (AP214) file correctly contains the three
> child parts and the parent assembly which
> refers to each part.

> case 2: Suppose an assembly contains three
> child parts such that the third part
> overlaps the first two. Using the same
> writing code that I used in case 1, the
> result is a bit different. The first two
> (non-overlapping) children are written to
> the file normally - that is, I can follow
> the references from the
> NEXT_ASSEMBLY_USAGE_OCCURRENCE of both
> children within the assembly back to the
> original part to which the part instance
> refers. However, the third child is written
> as a NEXT_ASSEMBLY_USAGE_OCCURRENCE that
> refers to an exact duplicate of the original
> child part. A child written this way has no
> references to the original part (as far as I
> can tell). Is there a way to tell the
> STEPControlStd_Writer object not to worry
> about cases when the parts overlap? I do not
> know if I will encounter this problem when I
> read objects or not, but if I do, can I
> instruct the reader object not to worry
> about this case either?

Normally you should not have to write separately components and assembly. Just put to writer the whole assembly, it will write it along with all components.

Note again that neither reader nor writer do not worry about any overlapping except that they preserve sharing of subshapes in shape and components in assembly.

Best Regards,

Andrey

> Thanks,

> -- Shaun Bloom

Contact us

Attention: DO NOT use this form for all kind of request for the removal of your personal data. Please follow this link for such cases.