SolidWorks File Bloat, EcoSqueeze, and PDM

The rapid increase in SolidWorks file size in SW04 is causing us grief.
EcoSqueeze can eliminate the parasolid information that is bloating the
files, and I ran a simple test to see if it increased the load time for one
of my parts. I got 4 minutes without the parasolid data and 4 minutes with
it, so it looks like we could economize on disk space without slowing down
our workflow. The problem is that we use PDM to keep our files straight
(Activault right now, looking to upgrade to another system soon, possibly
DBWorks). I don't see any easy way to integrate EcoSqueeze with Activault.
Would it be an easy matter to write a script that would run EcoSqueeze on
the parts as it saved them into our PDM system? Has anybody done that for
any PDM system?

The best answer would be for SolidWorks to give us the option to save or not
save the parasolid information, but I'm not going to hold my breath.


Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

Are you sure ecosqueeze won't work? I should unfrag any Structured Storage
file. Of course if it is based on file extensions it won't, but Thilo could
fix that.

I wouldn't want to run it on a vault while the server was up either.

 

Right. I don't want to run it on the files after they have been placed in
the vault. I want to run it on the files just before they are placed in the
vault. Activault doesn't seem to offer any way to intercept the files, run
them through EcoSqueeze, and then place them in the vault. I'm wondering if
any of the other PDM systems would give us that possibility.

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

Jerry Steiger wrote:
The files inside the vault are still native SW files, but the extension has
been stripped off. If the server is shut down you should be able to unfrag
the files. Of course I would test this out first.

I suppose given SW position on using any unfrag utility you will not find
any Solution Partner doing this.

 

"unsupported" doesn't mean "forbidden" ;-)
What would be wrong with a SolutionPartner tool that calls an external tool
every time a file is saved/closed?

I have an idea on how to run EcoSqueeze before any PDM puts the file in its
vault, and how to detect if parasolid info can be safely removed or not.
Any sponsor ?

 

Has anyone seen where EcoSqueeze removes Sharing and Security rights
on a shared folder on a local machine?
It has happened to us several times, and if I remember correctly the
shares and security appear to be there, but you have to recreate them
to allow others to share the directory. I even have one machine that
we have to make a copy of the entire directory after running
EcoSqueeze to allow others to access it.

 

Jerry,

If you or one of your co-workers can write script files....

All you have to do is modify the OnSaveas, OnCheckin, or OnApproval
lst files to check for the file extension. If it meets your criterial
have the script run an external program (ECO-SQUEEZE) or what have you
on the file prior to checking it into the vault.

You could also modify the OnEdit script to perform the same thing when
adding/removing configurations.

At the same time you could perform a whole slew of checks, such as
description naming convention, duplicate numbers, custom/configuration
auto fill, auto drawing creation, check the values against an ERP for
incorrect values, etc....

If you have the 30 day evaluation you should be able to "test this" in
real time.

Len

 

Thanks, Len. Just what I wanted to hear!

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

If push comes to shove, I guess we could try this out, but I, for one, am
very nervous about messing with the files once they are in the vault.
Thanks, again.

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

Thanks, Philippe. I might be able to get folks here interested. How much are
you talking about?

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

Jerry,

are you sure it's the parasolid which is bloating your files? I'm
hesitant to remove the parasolid on "master" production files while
the preview and display list is pretty save to remove. The original
intention of EcoSqueeze was to shrink a copy of an 100MB assembly down
to say 5MB for easy emailing.
If you remove the parasolid of an imported part, SolidWorks cannot
rebuild it as there is no parametric info in the file, so be careful!

I don't know what possibilities you have in your PDM to trigger an
other application before import, but one idea would be to use the
EcoSqueeze command line. An other one would be to write an add-in for
SolidWorks which catches file saves or similar events. Or we could
watch for file system changes on particular folders and trigger
"squeezing" from there.

If you need to save disk space my reccomendation is to run EcoSqueeze
every other week on your vault when it's off.
The ideal sequenze would be to switch off the vault, backup the files,
EcoSqueeze the vault folder and finally defragment the hard disk.

EcoSqueeze does not look at the file extension, it looks at the header
of the file to determine whether it's a structured storage file or not
so it should work.
As SolidWorks does not recommend using defragmentation tools, and I
don't want to get into trouble in case they ever chage anything which
would cause EcoSqueeze to make files unreadable by SolidWorks, I can
only recommend to use EcoSqueeze on data AFTER you have drawn a
backup.

Regarding the permission issue an other user brought up:
Frankly, I haven't looked into this (and don't have the time to do it
right now). All I can say for now is that EcoSqueeze runs by default
under the currently logged it user account where it's executed. When
you have the /v verify option on, it works on a copy of the file, not
directly on it.
The advantage of this is that in case anything happens (power failure,
system lockup), the original file is untouched. Only after the
squeezed file passes some sanity checks, the original is deleted and
the defragmented one renamed to the original. While this method is
safer, it takes a lot longer, may defragment the hard disk itself a
bit more and may change the file permissions as I don't set them
explicitly to the ones of the original file.
Work around: either don't use /v or run EcoSqueeze under an account
with the security permissions you desire (if that's possible in your
environment).

Thilo

 

Quite positive. I ran the "normal" EcoSqueeze on thirteen of my parts and
got the typical halving of the file size. When I remove the parasolid files
they shrink down anywhere from just 10% or so (small files anyway) to more
than 99% on one of the larger files. The average of the thirteen is 83%
compression, so my total file size is about one sixth of the "normal"
EcoSqueeze size.

Right, this is one reason I am a bit hesitant to run EcoSqueeze on the
vault, since I might have some parts in the system that are imported and I'd
rather not find out many months from now that I've blown them away. If we
can run some kind of script on individual files as we put them into PDM,
there's a pretty good chance that we will recognize what we are doing and
won't lose any critical surfaces.

I don't see a way to do this with our existing PDM (an old version of
Activault). We could do this if we switch to DBWorks.

This might work out well. I should run some tests on the comparative times
to save bloated files versus the time to run EcoSqueeze and save the smaller
files. If those are comparable or even smaller, then running EcoSqueeze each
time we save the files would be a good idea. If running EcoSqueeze takes
longer, then it would be best to do it only when saving the files into the
vault.

Given our file structures, this probably doesn't make much sense. Since the
check-in process takes place from SolidWorks, the files have to be
compressed as they leave SW or as they enter the vault. There isn't any
intermediate place where we can do it.

I think this is brain-dead behavior on the part of SolidWorks. But the whole
idea of saving the parasolid data seems to be brain-dead to me, since it
seems to bloat the file size without reducing the time to load the files. If
they would give me the option to save or not save the parasolid data, we
could all be happy.

Anyway, thanks, Thilo!

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

I think this is brain-dead behavior on the part of SolidWorks. But the whole

So...if I am making a brand new part in solidworks, and import nothing
from another file, why in the world must the file contain information
I DO NOT need, and which as far as I read here, that SolidWorks
doesn't need.

Quid quo pro between Microsoft and Intel and Hard Drive mfgrs to keep
upping the computer anty?

I don't want my work horse, SolidWorks, to turn into a Zebra...uh oh,
I remember, I can already use Zebra stripes, so I guess SolidWorks has
already bought into the MS Mess.

Bo

 

My understanding, by way of Ed Eaton's post here some time ago, is that the
Parasolid data is saved in working memory so that rolling up and down in the
feature tree is faster. This may or may not be a good idea for most users,
but it might cause problems for those of us who are working with large file
sizes anyway. I think it would be useful if we had the ability to decide for
ourselves whether or not we want that data in our working memory.

There is another issue, though, which is whether or not that Parasolid data
should be saved to the hard disk. What little testing I have done shows that
saving the data to disk seems to be pointless, since it takes my system the
same amount of time to load the file whether I have the Parasolid data or
don't. I suppose if I had a RAID or SATA drive that it might be a little
faster with the Parasolid data. So, again, give us a toggle to save or not
save that data.

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"