cad data corrupted caused by compressing-tool?

Hi there,

I recently stumbled upon the following problem:

I exported a SolidWorks-file as Parasolid, compressed it at normal rate with
WinRar (ZIP). The part consisted of some freeform geometry and a bore with
a plain diameter of 20 mm.

Our customer unpacked the part with WinZip, opened the part in SolidWorks.
No changes in geometry or shape can be measured up to this point. Then he
exports the part as STLwith fine quality settings for rapid prototyping. Now
the STL file shows some differeces in geometry. The scale and especially the
bore diameter is not round but somehow oval and the meassure is stretched to
20,5 mm!!!

When I send the exactly same Parasolid not compressed, the part also opens
correctly in SolidWorks at our customers. He then exports with the exactly
same STL export options as before and the STL part is generated correctly as
it should be.

??? This behavior is reproducable but a reasonable explanation is still
lacking.

So what could be the conclusions for this weired behavior? Could WinRar or
WinZip have caused the screwed STLs?

I hope I was able to describe my problem. Any opinion on this subject is
very much aprechiated.

Thanx & regards from Germany

 

Hello Paul,

thanks for the fast reply. Yes, I tried to open the compressed Parasolid
and I generated a STL. Sofar with bare eyes it looks quite good to me,
but I have no possibillity to measure an STL within SolidWorks (do I?).
My customer uses a slicing software (magix?) to prepare data for SLS
and with this software he can compare incoming and outgoing data.
I would guess that my data gets corrupted by either one of the two
different compression tools. Winrar (compress) -> WinZip (decompress),
but I would like to proof.

I am also quite confident that my data leaves without degression and gets
crumpled by my prototyper. ;-)

Of cause there are many ways to avoid this problem. Best solution
seems to me just to send uncompressed parasolids (the size is quite
as compact as compressed, so zipping is not really a big gain)

The most important point for me would be to find out, if data
compression could generally affect 3d geometry somehow.
E.g if data compression worked compareable to jpeg compression,
a data change or even loss of information could be explainable.

I will run some further tests at my customers tomorrow and post
the results, (if there are any)

Good night

JoJo

 

Try running an MD5 hash before compression and after extraction. (Search
Google for free tools.) If the hash checks ok, then it is very unlikely
that RAR or ZIP have altered the data. That might be something you could
tell the customer and say "you must have accidentally changed a setting".

Anyhow, it's incredibly unlikely that a file compression tool could corrupt
a file in such a way that a BREP model like a Parasolid would show up with
a non-uniform scale applied to all the numbers which represent geometry,
but not all the headers and whatnot that make the file readable. Data might
get corrupted or otherwise go missing, but it shouldn't be multiplied by
some factor that is remarkably similar to a shrinkage factor that your
customer's software might routinely apply.

 

Short answer: no, not with binary data compressions such a Zip
file.

Such are not lossless compressions as the binary ones are and
the exact original data is somewhat lost.

 

LOL .. it's now a polygon mesh; inexact.
AND they probably have a canted plane they are measuring across
or something.
Operator error IMHO.

 

Cliff,

I am aware that stl is a poligonal mesh but that´s no reason why the part
shows a divergence of almost 3% percent. Not to mention that stl export
conditions were set to high. The whole part is only about 60 mm in height
and therefore the divergence is really cosiderable!

Regarding your concern about the method of measuring, you can be ashured
that they are professionals. Especially in measuring small parts as yours,
mentioned some threads below.

 

Hi Dale,
thanks for the MD5 hint. I will test that asap.

Regards

Jojo

 

It is my experience with rapid prototyping that scale factors can be
introduced by the slicing software. This is done intentionally because
many RP processes have shrinkages that need compensation. This depends
on the orientation of the part. Send your contact the same part
oriented to the front, top and right planes and see if they get
differenct scaling on the hole.

TOP

 

Hi,

our first suspicion was also the internal scaling applied by the slicing
software. We doublechecked that the data degression already
occured before the scaling was applied for sls processing.

I know, it sounds like magic. Now I know why the software for
slicing cad data is named Magics from Materialise.
This causes me headache.

Regards

JoJo

 

Then you are just imagining the problem <G>.

 

Use a program like Beyond Compare to compare the 2 files in question. First
file would be one made and never compressed. Second would be the one
compressed with WinRAR and un compressed with WinZIP. If you find the files
to be exactly the same, then I would think there was a slightly different
setting when your customer generated the STL.

Bill Cain
www.partmaker.com

 

Lossless compression programs (such as PKZip) should error out
if the compressed file has even one bit wrong (can happen due
to several reasons from radiation to media or transmission problems).