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

Sumthin sounds screwy? My first question would be, have you yourself, opened the compressed parasolid file and saved it as a stl to see if it in fact does changes shape? I would wage that this is user (customer) error? Otherwise, have the customer save the data out again as a parasolid, reimport it, and save it as a stl? If that fails, force a repair, right mouse click over solid body icon on feature manager, and save it out again as a parasolid,..
..

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
  Quoted Text Here  

  Quoted Text Here  
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.

Hi Dale, thanks for the MD5 hint. I will test that asap.
Regards
Jojo
  Quoted Text Here  

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
  Quoted Text Here  

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.
wrote:
  Quoted Text Here  

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
  Quoted Text Here