Running 32 bit SE on 64 bit platform 2

[KENAT]

We are having trouble working with some large assy's and are looking at the various factors that affect it. We've already upgraded the data server, tried a faster network link on one machine, got the 4GB with 3GB switch on several machines etc. all this helps but we're looking at stretching it more. I've looked at some of the other posts on here, data from UGS/Siemans etc and last week (or maybe week before) had one of their guys in.


Got this from the Siemans IT guy:

FAQ 64 Bit ...

3. If customers still require more resources then advise them to run 32 bit Solid Edge on a 64 bit platform. XP64 will allow us to access 4 GB of RAM vs 2 GB in XP 32-bit and vs. 3 GB with XP + the 3 GB switch in boot.ini. This will allow them to open larger assemblies, create larger drawing views, and have more memory to use across the board, without loosing any Solid Edge functionality. ...

Is anyone doing this to get the extra GB of RAM?

If so any comments, issues, problems, massive benefits etc.

Thanks,

KENAT, probably the least qualified checker you'll ever meet...

 

[beachcomber]

Hi Kenat,
At my previous job we ran 32bit SE on XP64 to get the full advantage of 4GB ram and didn't have any problems, except for print drivers and saving as pdf (which worked on some machines but not others - strange !)
XP64 would also give you the option of using SE64 in the future.
Our top assemblies were around 25K parts - haw do yours compare ?

bc.
CAD2 Imagine Workstation
2.4GHz Core2 Quad, 4GB RAM,
Quadro FX4600.

 

[KENAT]

I don't think they're that big, in the thousands for sure but I'm not sure we know for sure. I can’t remember the figure but we did tell the Siemans guy the amount of GB of Data and he said it was on the high side.

Part of the problem is that major sub assemblies have been imported from vendors using different CAD systems so are translated from step or Parasolid etc.

We don't have particularly good model hygiene so with the imported models we may have 50 models of an M5X10 screw or whatever, which doesn’t help some aspects of performance.

Even some of the hygiene of our native parts/assy isn’t that good. This is the first time we’ve had a full ‘master model’ of a big tool and most users creating the parts & sub assy have no concept of the implications etc. Most parts don’t have a simplified config, we have reference parts in sub assy that actually belong in higher assy’s etc.

My colleague responsible for the top model has done some tidying but they wont allocate resource to do it properly.

We tried using simplified Assy’s but it didn’t work well for us.

Most of our trouble is in the draft environment.

Appreciate the input. The print driver thing may be an issue but we could probably work around it. Pulling up drawings may be slow but on our better machines they come up OK and we can print them, the trouble is normally when we are working with views or updating views etc.


KENAT, probably the least qualified checker you'll ever meet...

 

[beachcomber]

Hi Kenat,
You have my deepest sympathy - I've been through all the same problems, but the good news is they can be overcome.
I tried simplified assemblies - gave up - too many problems with updating them, using them with adjustable assemblies and losing assembly constraints.
Simplified parts will make your files bigger - it has to because there are more operations. I've seen complex parts grow from ~2MB to 10+MB.
It also takes longer to open an assembly with all parts simplified than it does with all parts as designed.
I did an experiment on a big assembly and it took 20% longer to open - 6 mins against 5 mins.
Where they do help is when the file is open and you are rotating etc as the graphics has fewer polygons to display.
They will also help in drawing views (fewer edges to process)
As for 'reference' parts - they will kill the system if you have too many. At my last place we cleared them all out and improved things greatly.
Opening drawings is better now on V20 as you have the "Open Inactive". (I know you are on V19 but this could be a reason to upgrade).
If your assemblies are big create view configs with visible parts only displayed.
It sounds like you really need to be ruthless and get everyone into line - it will make NO difference changing systems to SW or Pro/E as the basics are the same.
Remember the old saying "Crap in >> Crap out"

Good luck with the 'saboteurs'

bc.
CAD2 Imagine Workstation
2.4GHz Core2 Quad, 4GB RAM,
Quadro FX4600.

 

[swertel]

Yeah. Good luck.

--Scott

http://wertel.eng.pro

 

[KENAT]

Thanks,

The info on simplified parts is interesting, given what you've said I'm not sure how much it will help in our problem areas.

We're making extensive use of configurations already, it helps a lot in the model and some in drawings.

It sounds like you really need to be ruthless and get everyone into line - it will make NO difference changing systems to SW or Pro/E as the basics are the same.
Remember the old saying "Crap in >> Crap out

LOL! Neither I, nor anyone else who has even a basic understanding of the issues has any real authority to do this. Those that do supposedly have the authority either don't care, don't understand, or have been won over by the SW fanatics. Don't need to tell me about the basics being the same, I get that, the SW fanatics either don't or are lying about it.

Thanks,

KENAT, probably the least qualified checker you'll ever meet...

 

[beachcomber]

Kenat,
Have a look at this thread on the SWX forum -
thread559-217837
It seems to indicate a physical PART SIZE LIMIT.
Would it affect your design process ?


bc.
2.4GHz Core2 Quad, 4GB RAM,
Quadro FX4600.

 

[KENAT]

We're at the opposite scale, we have users complaining that SE doesn't have nanometers as a unit option. There's some debate that even putting in .0000000... there is a lower limit of resolution or something.

The biggest we get is maybe 5m on assys.

Thanks anyway.

KENAT, probably the least qualified checker you'll ever meet...

 

[beachcomber]

Kenat,
If you're worried about your system performance using SE, have a look at this thread from the SoildWorks forum.
It's my opinion (having used both systems) that SE is far better with large assemblies.


bc.
2.4GHz Core2 Quad, 4GB RAM,
Quadro FX4600.

 

[KENAT]

Beach, you didn't appear to put the link, or am I missing something?

Interesting timing on the post, seems another department want to run some analysys on the machine we're putting to 64 bit and are paying for extra RAM to support this. So the machine will go to 64 bit OS, and have something like 16 gig of ram so we've changed our plan are are toing to go to 64 bit SE!

Thanks Beach.

KENAT, probably the least qualified checker you'll ever meet...

 

[beachcomber]

Kenat,
Sorry - old-age creeping in - I need a memory upgrade !!!thread559-218636

bc.
2.4GHz Core2 Quad, 4GB RAM,
Quadro FX4600.

 

[donyoung]

Hi,

also a factor that can cut into performance is the number
of parts an assembly holds. 'Small is beautiful' applies
here. I've an assembly with a total of approx. 5000 parts
the top assembly. however contains 8 entries, all are assemblies.
The lowest assemblies do contain at most 20 parts.
When opening such an assembly SE must check all relations
for any inconsistencies. But putting this assembly along with
another assembly in a new assembly SE will have to
check at most 3 relations and that's it.

dy

 

[KENAT]

Thanks Beach, I just forwarded that link to my boss and my other colleage that gets caught up in the SW V SE arguement.

Don, so what you're saying is that you're better off having more assembly levels but for each Assy/sub Assy to be relatively small? This sounds familiar, is it in some SE/UGS/Siemans documentation or presentation somewhere.

Sadly this clashes with the habit here of having relatively flat Assy/BOM structures. They claim it's better for operations/manufacturing however as best I can tell this is just because their system requires them to book each sub assy back into stock before assembling the next level assy, or something like that. It causes us problems in product documentation as conventional assy drawings get busy/confusing/difficult to show everything so we end up having fights over whether we should have a detailed work instruction ...

KENAT, probably the least qualified checker you'll ever meet...

 

[donyoung]

Ken
[cite]
Don, so what you're saying is that you're better off having
more assembly levels but for each Assy/sub Assy to be relatively
small?
[/cite]

yes, that's right but, you mentioned it, it might not be *the*
solution for every installation, mainly because of the inability
to create a structured BOM. One has to decide how far this
approach can be put into practice

[cite]
This sounds familiar, is it in some SE/UGS/Siemans
documentation or presentation somewhere.
[/cite

unfortunately, no. There was a discussion on the UGS BBS a while
ago that recommended this approach. When carefully planned it's
also possible to show the various stages during the assembly
in SE already (but that's nice to have ..)

dy

 

[KENAT]

Thanks Don, from a design & design documentation point of view I prefer the 'lots of small sub-assy' approach.

However, the flat 'BOM' seems to hold a lot of sway here.

There's been talk that the model (and perhaps even drawings) structure doesn't necessarily have to match the ERP/manufacturing BOM but so far in practice they are kept more or less in step.

KENAT, probably the least qualified checker you'll ever meet...

 

[beachcomber]

At my previous contract the customer used a manual BOM system that had only 2 levels.
Level 1 was the GA, level 2 was what we referred to as a 'Zone', and each zone would have a range of part numbers such as M10XX, M15XX, M20XX etc which made it easy to identify the zone area.
Examples of a zone would be Gearbox Assembly, Machine Frame, Motor Installation etc.
The GA comprised about 20 or so Zones, and that was how we modelled it. The top-level assembly model only contained the zone sub-assemblies, no parts.
When it came to assembly models of zones, these would comprise many multi-level sub-assemblies and parts - just as Don suggests.
These sub-assemblies were for only convenience of modelling and never appeared in the BOM unless they were a fabrication or a complete item as ordered.
On the early projects these were given model names corresponding to 'proper' part numbers but this led to confusion in generating the BOM from Solid Edge- we never really knew which sub-assemblies should be expanded. We then changed this so that the model name took the number of it's zone with a X001, X002 extension etc. We could then easily identify which components to include in the BOM.
I think what I'm saying here is that you can have multi-level sub-assemblies for performance and still maintain a flat BOM structure, although I'm not sure how it would work with a pdm system.
I should also point out that the top-level comprised almost 30K parts and we could still easily manage the assemblies, and produce drawings, in a multi-user environment working across a network. The workstation hardware spec was exactly the same as shown after my post. We ran 32-bit SE on XP64 with only 4GB of RAM.
Hope this helps.

bc.
2.4GHz Core2 Quad, 4GB RAM,
Quadro FX4600.

 

[KENAT]

Thanks Beach, we've made a rod for our own back to some extent and I know it.

Sadly it's a bit late for this project though if the opportunity arises we'll try and implement the more tiered assy. In our current climate I don't see anyone wanting to spend a bunch of time/money re-strucuring the model significantly.

We use the automated BOM/Parts List in SE with more or less conventional assy drawings, at least on newer projects.

My feeling is that it may be all the imported assy's giving us a lot of the trouble on this one project, but I couldn't prove it. All of the major sub systems/assemblies (except one) were prepared by vendors in different CAD systems and imported in SE via parasolid or similar. Some of these have fairly flat structures and, as each screw etc gets replicated for each time it's used, lots of parts.

The highest level assy we have completed the drawing for only has around 15 items in the parts list, a few of them multiple occurances, so it isn't massive in terms of number of items at the assy level.

Thanks for the information though, it confirms that a lot of the problems are to some extent of our own making.

KENAT, probably the least qualified checker you'll ever meet...

 

[KENAT]

Well, he only got to play on it for about 1/2 hour but it appears the 64 bit SE on 64 bit OS with lots of RAM (not sure how much but I think in the teens) is working.

KENAT, probably the least qualified checker you'll ever meet...

 

[beachcomber]

Hi Kenat,
Glad you're seeing some improvement.
Just a couple of other points, I think it helps if you have a dedicated server for your CAD stuff, and do you have "reference" models in your assemblies that have 'display at higher level' turned off.
By this I mean stuff that's used as background information for positioning or for producing drawings where you need to see surrounding parts. It all still has to be processed when loading assemblies.
This was one of the thngs that we avoided. When we first got hold of the models from the customer we cleaned all these out (we had 4 or 5 gearboxes and machine frames each of hundreds of parts) and noticed a huge improvement.
What we did then for drawings that needed the background information was to produce a seperate model that had background models + the real assembly model.
This model was identified by adding an extension into the filename, so we had XXXX-123456-1234.asm for the real model, XXXX-123456-1234-DFT.asm for the model used to produce the drawing. We didn't do it for all assemblies, just where you need some background info.

bc.
2.4GHz Core2 Quad, 4GB RAM,
Quadro FX4600.

 

[KENAT]

No dedicated server though the CAD data was recently moved to a newer faster server, this was done at the same time we put a faster network on our 'super computer' so it's not clear which made the difference but both helped.

Funny you mention reference models, we just removed a bunch in the last couple of weeks for the very reasons you state. I can see I've got a fight brewing on another program though, one half of our business loves putting assy tooling in the assy model!

KENAT, probably the least qualified checker you'll ever meet...