Subassembly Composer 101: Sequences

As you can tell by the title of this post it is about sequences but really it is also an addendum to my post about codes as well. There are two elements in Subassembly Composer (SAC) that will really help in your flowchart organization these are both found in the Workflow portion of the Tool Box and they are called Flowcharts and Sequences. Both of these elements are like folders that allow you to hold multiple pieces of the main flowchart. Sequences are used to hold linear logic and flowcharts are used to hold branching logic. So why do I love using sequences and flowcharts so much…

There are lots of reasons that I like these organizational workflow elements but the main two are:

  1. They explain the logic flow to someone who opens a .pkt file and wasn’t the original person who made it. Similar to a filing cabinet if I put all my papers into one drawer and tell someone to go find the application for project 08080054 they will have a much more difficult time than if I put all my papers into file folders within my drawer that are already numbered by project. Now the person can just grab the 08080054 folder and have much less clutter to go through.
  2. You can only copy and paste one element at a time either within a single instance of SAC or if you have a second instance of SAC open. Since the sequences and flowcharts are one element but hold lots of elements they make copying and pasting so much easier.

imageAs I stated previously, sequences are used to hold linear logic, so they are perfect for any of the Tool Box elements other than Decisions and Switches. As you can see in my example to the left I have define a road cross section with shoulders using four sequences. The second sequence defines the points and links for the road, the third defines the points and links for the left shoulder, and the fourth defines the points and links for the right shoulder. Clean and simple.

imageThe sequences will default with the name “Sequence” but you can click on the title to change it to something that makes more sense. Double click to enter into the sequence for editing. When you are done, just click the “Flowchart” to go back to the main flowchart.

You may have noticed that I skipped right past that first sequence that I have labeled as “Codes”. This is where my brilliant idea comes in. In the previous post I talked about how you can define codes using either strings (ex. “Top”, “Datum”) or a combination of Input Parameters and strings (ex. SurfaceCode, “Datum”). Input Parameters are defined by the end user in Civil3D. What I did not mention was that you can also define codes using Variables. Variables (available in the Tool Box under the Miscellaneous section) are defined by the person composing the subassembly in SAC and are thereafter treated just the same as Input Variables (without quotes in VB Expressions).

imageNow why would I want to define all my codes up front? For consistency. You will learn to love those lovely red exclamation marks that tell you something is wrong (or inconsistent). If you define all of your codes using strings and you switch halfway through your design from using “Top” to using “TopSurface” you potentially won’t realize it until you import it into Civil3D and are trying to make a surface based off of those links. Here if I define them all to begin with and use the variables instead of the strings when defining the codes, the program will yell at me when I switch. Or if I meant to switch, I can just go in and change them all at the same time without having to hunt and peck and find all of the links.

Here are my variable properties for my “Top” string:

image

With this variable defined I will just use the word Top (without quotes) when defining my codes for the top links. As shown I defined the variable name to be the same as my code string used in Civil3D. If I want to change what is used in Civil3D to “TopSurface” I simply change the default string variable like this:

image

Note that I will still use the Top variable in all my Codes in SAC despite changing the Civil3D string to “TopSurface”.

Hopefully this little tip will help you keep more organized and consistent. Happy composing!

2 comments

  1. Zoran says:

    Is it possible to inherit the output parameter from one to another subassembly in subassembly composer?
    For example:
    I made one lane.pkt file where i control slope of subgrade depending on the slope of pave. Then i made another gutter.pkt file, but i don’t now how to control thickness of subgrade in this file depending on whether it comes to higher or lower side of the carriageway.
    Sorry for bad english.

    • Great question Zoran. Using Parameter Reference in Civil 3D on a subassembly created in Subassembly Composer is the same as any other stock subassembly.

      If I understand your question correctly, you will set an output parameter in your lane.pkt file that is called SubgradeThickness. For a VB Expression you will want to find the algebraic difference in elevation of the two points at the top and bottom of the subgrade that you are trying to match. If these points were P2 and P4 you would use the VB Expression P2.elevation-P4.elevation. In your gutter.pkt file you will want to set an input parameter for SubgradeThickness.

      Now in Civil 3D when you put all your subassemblies together you are going to right click the assembly in the Prospector, go to Properties, and then click on the Construction Tab. Click on the gutter portion of your subassembly and check the box to use the Parameter Reference and get the value from the output parameter of the lane subassembly. Hopefully this answers your question.

      There are lots of power in using the Output Parameters. Stay tuned for an upcoming post! Happy Composing!