cad data corrupted caused by compressing-tool?

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
"Paul Salvador" schrieb im Newsbeitrag news: snipped-for-privacy@mygate.mailgate.org...

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.

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.
"Cliff" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

Hi Dale, thanks for the MD5 hint. I will test that asap.
Regards
Jojo
"Dale Dunn" schrieb im Newsbeitrag news:45f06fde$0$24776$ snipped-for-privacy@roadrunner.com...

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
"TOP" schrieb im Newsbeitrag news: snipped-for-privacy@30g2000cwc.googlegroups.com...

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