Re: Data exchange formats (longish)

From: André Dolenc (Helsinki University of Technology)
Date: Friday, September 30, 1994

From: André Dolenc (Helsinki University of Technology)
To: RP-ML
Date: Friday, September 30, 1994
Subject: Re: Data exchange formats (longish) 
brindley@ECE.ORST.EDU writes:
 > I don't suppose you'd care to elaborate on these software problems.  

A typical scenario: the user generates an STL file using a CAD system.
The CAD system doesn't tell the user if the result is correct, neither
does the user have the possibility to inspect the result because the
CAD system cannot read STL files. Would it be different if the file format
where CFL? IGES? WAVEFRONT?
Any problems are passed down the pipeline, and eventually on the lap of the
manufacturer.

 > to it being an STL file.  A good file format would solve those problems.

It is very difficult to generate efficiently a CFL file with no redundancy.
(low resource utilization, mainly main memory and CPU time).
In fact, nothing prevents an application program from using the CFL format
just like it would use the STL format. I would agree with the above statement
if it were phrased "potentially solve those problems".

 > Is STEP officially released?  Last I heard it was still 'the coming thing'.
 > It's been that way for a while now.

The first STEP standards are scheduled to be released this Autumn. Several
parts are in the final stages of approval.
Could our collegues from Leeds University who are on this list comment on this?

 > Interesting suggestion.  Any attempt to define a new format should have
 > the purpose (objectives) clearly stated.  If the major objective is to
 > transfer the geometry is a reasonable way to the RP machine, then the
 > above ECO type feedback falls outside the scope of the format.  But
 > including such feedback may be worth while.

Effective two-way communication is essential to reap the full benefits of RPT.

 > Would you also care to explain why this is a MAJOR BOTTLENECK?   Pre-sliced

1. Slices open new application areas for RPT (eg. medical)
2. One can obtain better parts by directly slicing surface models.

 > representations lose a lot of information.  To change the slicing,
 > you need to go back to the original geometry.  Also, who says that future
 > RP machines will build things in horizontal slices at an even spacing?

1. With the current software tools around, this is also true for facetted models.
2. Sliced reps do not imply even spacing.
3. It is extremely unlikely RP machines will do otherwise.
   Ask the BPM developers.

Regards,
Andre'


Previous message | Next message
Back to 1994 index