Subassembly composer enumeration - setting consistent keys to the inputs


I’d like to know if there is a way to define the input value codes(or keys) of enumeration group.

For example, I have a subassembly parameter that comes with drop down inputs "string1, string2, string3’, if I want to overwrite the inputs using dynamo, I have to give the value as number, like 301, 302, 303 because it’s enumeration group. But the issue is, the numbers the composer assign to the inputs are not consistent. Sometimes it’s 301, 304, 305, sometimes it’s 302, 303, 304. Is there a way to set these values manually?


Hi Soo! Fancy meeting you here :wink:

Posting this here so that other experts can chime in and maybe see if there’s a better way, but here’s what works for me.

Since it seems that the values for how a subassembly codes enumeration groups is hardcoded into SAC, I don’t see a way to reference the display name instead of that enumeration value. Maybe there’s something in the API, but in the meanwhile you can make a copy of the PKT file and rename it to a ZIP file.

Once it’s a ZIP file, you can open it up and see that the ZIP contains several files with the same GUID and a different extension.


If you open up the file with the EMD extension, you’ll find how SAC enumerated your different choices, which is crucial/handy if you didn’t create the subassembly and don’t want to figure it out by trial and error.

Once you know those values, you can use Dynamo to drive their outcome, here’s an example of it in action:


Thanks for the reply Steven! But I wasn’t looking for a way to set the parameter value, but was trying to change the “code” of the value.

And when I first posted this, I was hoping to figure out how to rewrite the codes in subassembly file itself. But I found out that the numbers are given to the parameters in order of the item creation.

For example, if item a,b were created for parameter A, then the subassembly composer gives 301, 302 codes.
Next, if the user creates item 1,2 for parameter B, then it gives 303, 304.
If the user comes back to parameter A and creates item c, then it gives 305.
So continuous numbers based on the order of item creation.

Since the designers can add/delete parameters anytime, I figured overwriting these numbers won’t be useful.

**Rather, I’d like to extract how the codes are given. For example, I’d like to get a list of items (a,b,c,1,2) and get the codes (301,302,305,303,304). So I can look up “a”, “b”… and get “301”, “302”. **
The code data is written in .emd file and .xaml file, but I want to get this data through Dynamo(with python node probably), without opening the .emd, .xaml files.

If there’s a solution for this, please let me know!

Hi @Soojung.Kim,

After changing the .pkt to a .zip and unzipping it, you could try parsing the .emd file using the standard Python ElementTree module since it is formatted as an XML. Here’s an example:

import xml.etree.ElementTree as ET

file_name = IN[0]
xml = ET.parse(file_name)
root = xml.getroot()
for group in root.iter('EnumItem'):

OUT = attributes

1 Like

Thanks @mzjensen !
So it would still require the users to extract this mapping data from emd file whenever the subassembly file changes, right?
It would be best if I can extract the data from subassembly file in live dynamo without the need to unzipping the file, but still, this is a great workaround to get the mapping data. Thanks!

Correct. I experimented some more with using the Python zipfile module and apparently it works directly with the .pkt file! So we’re in luck.

import xml.etree.ElementTree as ET
from zipfile import ZipFile


zipfile = ZipFile(filePath, 'r')

# Get .emd file from zipfile
with zipfile: 
	for item in zipfile.infolist():
	for file in files:
		if file.endswith('.emd'):
	XMLdata =
# Parse XML data 
root = ET.fromstring(XMLdata)
for group in root.iter('EnumItem'):

OUT = attributes


No way! This is awesome!
Thank you so much for looking into this. This really saves a lot of hassle on my end!!


1 Like