Our CAD viewer times out when trying to load large STEP files (500+ components) during design reviews. The viewer starts loading the assembly, shows a progress bar that reaches about 40%, then throws a timeout error after approximately 2 minutes. Smaller assemblies (under 200 components) load fine.
I checked the viewer server timeout configuration and found this setting:
<ViewerTimeout seconds="120" />
Increasing the timeout to 300 seconds didn’t help - the viewer still fails at the same 40% progress point. I suspect this might be related to assembly pre-processing or memory allocation rather than just timeout values. The viewer server logs show memory warnings around the time of failure.
This is causing significant delays in our design review process as we can’t view complete assemblies. We’re forced to break large assemblies into subassemblies for review, which defeats the purpose of integrated design reviews. Has anyone optimized the viewer for large STEP assemblies?
You’re hitting multiple bottlenecks that need to be addressed together:
1. Viewer Server Timeout Configuration:
Your timeout setting is correct in structure but insufficient for large assemblies. However, timeout is not your primary issue:
Set both viewer timeout AND processing timeout. The processing timeout controls how long the server will spend converting geometry before giving up.
2. Assembly Pre-Processing:
Implement automatic pre-processing for STEP files:
Configure a background job that runs nightly to pre-process large assemblies
The job converts STEP geometry to an optimized viewer format (JT recommended)
Pre-processed files are cached and served directly during viewer requests
This eliminates real-time conversion overhead
Enable pre-processing in your viewer configuration by setting enableAutoPreProcess="true" and defining size thresholds (e.g., assemblies over 200 components get auto-processed).
3. Memory Allocation:
4GB heap is grossly insufficient for your use case. Recommended settings:
JVM heap: 16-32GB depending on typical assembly sizes
Native memory: Additional 8GB for geometry processing
Viewer cache: 10GB for storing pre-processed assemblies
Update your viewer server startup parameters:
-Xmx32g -Xms16g
-XX:MaxDirectMemorySize=8g
Additional Optimizations:
Enable Level of Detail (LOD) rendering so the viewer loads simplified geometry first, then progressively enhances detail
Configure viewer cache to persist pre-processed assemblies across sessions
Implement lazy loading for assembly components - load only visible components initially, fetch others on demand
Consider viewer clustering if multiple users need to review large assemblies simultaneously
Immediate Action:
Increase viewer server memory to 16GB minimum
Enable pre-processing for assemblies over 200 components
Run a one-time pre-processing job on your existing large STEP files
Update timeout configurations to allow for processing time
With these changes, your 500+ component assemblies should load in 10-15 seconds instead of timing out. The pre-processing job will handle the heavy lifting during off-peak hours, so design reviews can access optimized representations instantly.
This draft is based on general Aras Innovator knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
The 40% progress point is typically where the viewer transitions from loading geometry to building the scene graph. If it’s failing there consistently, you have a memory problem, not a timeout problem. Check your viewer server’s JVM heap allocation - it’s probably too small for assemblies of that size.
STEP files are particularly memory-intensive because they store geometry in a verbose format. When the viewer loads a STEP assembly, it has to parse and convert all that geometry into a renderable format. For 500+ components, you’re looking at massive memory consumption during the conversion phase. Pre-processing the assemblies before viewing would help significantly.
How would I implement assembly pre-processing? And what should the JVM heap be set to for assemblies of this size? Currently our viewer server has 4GB allocated.
Tested this on Aras 12 SP9 with a 647-component STEP assembly — setting ProcessingTimeout to 900 seconds eliminated the viewer cutoff we’d been seeing.
4GB is definitely not enough for 500+ component assemblies. I’d recommend at least 16GB for the viewer server JVM heap, possibly 32GB if you regularly work with assemblies of that size. Also make sure your viewer server has adequate CPU cores - STEP parsing is CPU-intensive and benefits from parallel processing.
Pre-processing is key for large assemblies. The viewer can generate optimized representation formats (like JT or Hoops) from STEP files during off-peak hours. When users request the assembly for viewing, they get the pre-processed lightweight version instead of forcing the viewer to process the raw STEP file in real-time. This dramatically improves load times and reduces memory requirements.