Hi,
I´m running out of memory in Subassembly Composer.
Running on a W7 64 bit computer, subassembly composer is a 32 bit program, does anyone know a way to adress more memory, it seems to run out when it addresses about 1 GB of RAM.
Best regards /Msv
Kati Mercier, P.E. | LinkedIn | AutoCAD Civil 3D Certified Professional
Pronouns: She/Her
Co-author of "Mastering AutoCAD Civil 3D 2013"
AU2019 Speaker::: CES321590: Analyze and Revise Existing Subassembly Composer PKT Files for AutoCAD Civil 3D
AU2017 Speaker::: CI125544: Analyze and Devise in Subassembly Composer
AU2012 Speaker::: CI3001: Reverse Engineering with Subassembly Composer for AutoCAD Civil 3D
AU2011 Speaker::: CI4252: Create Subassemblies That Think Outside the Box With Subassembly Composer for AutoCAD® Civil 3D®
It´s a shame that 160 auxiliary points and 20 Decisions is considered a "huge" PKT file.
SAC is a toy..
The problem is Subassembly composer has what are called memory leaks. The files you are working with are not large. Subassembly composer is also incapable of keeping track of logic trees correctly. Changes on one logic branch shouldn't impact another decision route but I have seen SAC break ALL of the logic and start randomly re-writing already defined elements or eliminating content within the nodes. I've also seen elements that are higher in the logic tree become "lost" by downstream components even when they are clearly part of the same logic string.
Another problem with custom SAC subassemblies is that the *.dll that is loaded with the *.pkt file into Civil 3D are in no way handled the same as OOB subassemlies. If you create a simple lane (just like the OOB version) and run both through the same corridor with targets, you will find that Civil 3D will not pick up the targets properly with the custom subassemblies. Civil 3D will also randomly "re-assign" targets when custom subassemblies are used. I have completed corridors and left them alone for months only to come back in to adjust something and find that when they are re-run random targeting occurs for no reason.
You will also notice that when trying to use low level tools like Create Feature Line From Object (CFLFO) , where you assign elevation data from a corridor surface that used custom SAC subasseblies, that you will get absolute garbage as output. Elevation data isn't pulled from tin line intersections, erroneous elevation data will be inserted at random locations and even symmetrical elevation data placed along the feature line regardless if tin lines cross/intersect it or not. I've used the CFLFO on short 600' feature lines with maybe 1,500 intersection locations and over a period of 24 hours, a 2TB HDD will fill with garbage data and then kill the machine. That is classic memory leak and/or bad call(s) within the program.
Three years ago, I proved this with screen shots and working directly with AutoDesk support technicians and re-sellers technicians. I did again spring 2018 with the incorrect processing of the custom subassemblies (even simple ones) and yet again in late summer 2018 regarding the feature line issues. AutoDesk has no intention of ever fixing these issues. They just kick it to development where it goes to die in obscurity.
Can't find what you're looking for? Ask the community or share your knowledge.