Creating Sub-Assemblies

[doni49]

If I create/import a sub-assembly, where is it stored?  Meaning is it embedded in one of the cuix files?

What happens when my computer is upgraded?  Or acad is re-installed?

What if I need a one-off sub-assembly--meaning that I'll only need it for THIS project?  I don't want it in my pallette permanently in that case.  Can I delete it from the pallette after I've added it to the Assembly?

[doni49]

---

@Joe-Bouza wrote:

The SAC is provided for users to develop assemblies that can't be achieved with the OOTB subs. That initself tells me that the user has either 1 of 2 things going on; they have some JPL grading or construction activity of the likes that the typical civil engineer does not see on a daily basis or they need to re-think what they are doing.

What does your section do? Many of the generic links can do oodles of different things

---

If that were the case then almost NOBODY would EVER need to use SAC.  With all do respect, I think you're way off base here.

And to answer your question RE what my section does, I'll tell you about the SA that I just finished.

I needed to show curb from station 0+00 to 0+40.  In this station range, the pavement width is 7.5 ft.  From 0+40 on, there is NO curb and the pavement width is 8ft.  I was previously using an offset alignment to specify when there is curb.  My SA uses a "Decision" to check the BaselineStation.  If it's in the curb range, it shows curb and makes the pavement 7.5 ft wide.  In the no-curb range, it doesn't show the curb and makes the pavement wider.  I like the fact that I will not need to create extra alignments.

Next thing that I"m using it for that I was having trouble doing with OOTB SAs:  From the curb or EOP to the daylight point, I needed a 2 ft deep rock blanket.  Then IF the daylight is before a 30ft offset, continue the rock blanket to the 30 ft offset.  Now I could have used a TopSoilStripping to deal with the second part of that, but I was unable to figure out a way to do it from the curb/EOP to the daylight and make it all one shape.  My SA does exactly that.  I created Offset alignments at 30 ft left and right.  If the OA is found before the daylight slope, then it doesn't continue the blanket past the daylight.

And lastly, I previously had an Assembly using OOTB SAs but it was extremely complex and there were so many different conditionals.  I had to set lots of horizontal targets and surface targets.  I really like the results of my work with the SA.

[doni49]

---

@nilesh33 wrote:

Hi,

Exactly. We have to import SAC subasseblies into Tool Palette before opening the Corridor File.

We need to send both SAC subassemblies (pkt files) and Corridor to the end user.

Regards,

nilesh

---

That directly contradict's a statement that Almas previously made.  He first told me that the SA can be deleted from the pallette.

[fcernst]

The SAC is provided for users to develop assemblies that can't be achieved with the OOTB subs

It's really much more than that. I say it's for users who want to do some things more efficiently,  and especially to let the software handle the mundane.

I have  SA's now (see this forum)  that do daylight slope transitioning and daylight slope clean up between adjacent daylight conflicting Corridors.

I just finished a ditch assembly for county road widenings and rehab work that determines if the exisitng ditch grading is adequate, or needs to be rehabilitated/increased in capacity per drainage requirements, or is not needed at all,  by essentially sensing and reporting back to itself the lay of the land for its own decision making. Saves me a lot of mundane evaluation and manual editing. I just do QC after now and I'm pretty much done.

Reaching out, testing and reporting back conditions for dynamic decision making is an attribute that makes SAC very appealing.

Another thing.. it's pretty darn fun and satisfying to see these type of results.

Only limited by your imagination now... This is awesome technology that needs just a little platform/workflow TLC to help us with primarily the debugging process for our SA's...

[doni49]

---

@fcernst wrote:

Another thing.. it's pretty darn fun and satisfying to see these type of results.

---

 I highly agree.  That is once I was able to really understand what I was doing.

---

@fcernst wrote:

Only limited by your imagination now... This is awesome technology that needs just a little platform/workflow TLC to help us with primarily the debugging process for our SA's...

---

 Again, I HIGHLY agree.  The SAC is already a fantastic thing and has a lot of power.  But there is also a LOT of room for improvement as far as the workflow for actually using the custom SAs.

[LeafRiders]

The subassembly is not stored within the drawing file. This coming from someone at Autodesk is very amusing. Have you ever tried sending a Civil 3D file to an external client that doesn't have the .pkt file saved to their tool palette? If you do they get the error:

One or more subassembly macros (or .Net classes) could not be found. Check Event Viewer for more information. Continue? Yes or No.

Now when you send a model to an external file or have someone internally look at the same design file, the need to add the same .pkt file to their tool palette in order to utilize the corridor modeling that was initially setup. Because the process of adding the .pkt file to your palettes creates the .dll file saved to the C:\ProgramData\Autodesk\C3D 2012\enu\Imported Tools ... folder.

Furthermore the concept of model based design, and the statement that everything to do with your model is saved within the .dwg file is out to lunch. Autodesk needs to figure out a way to embed this ".Net / macro" information in the drawing or the subassembly within the .dwg file to make this work as it should. Very disappointing.