Property sets pushed to schedules

[jasonp]

Hello, I'm having an issue doing something I've already done before concerning MEP schedules. I simply want to schedule a number of blocks, and I've added the property set definitions, the extended data shows properly in the Extended Data tab. My schedule even shows the proper count of attached objects, BUT I don't have access to schedule any of the property sets from it! I can't figure out why it won't read the attached property sets in the schedule.

The attached word doc just contains screenshots of the schedule editor, and the block with properties attached, but unavailable in the schedule.
Any help would be greatly appreciated!

[jay.ayala619681]

JasonP, can you attach a sample of what the *.dwg file itself and what that schedule is supposed to look like? I think I can help you.

[jasonp]

Attached should have everything so far, please keep in mind it's a WIP file, so the naming and multiple property sets will be cleaned up. Was trial and error trying to figure out why they weren't pushing to the schedule data. (Went as far as building a list, classifications, which didn't look like they're applicable on blocks, a few random things.)

[dkoch]

The Unistrut Clips Property Set Definition only applies to Block References. Your Schedule Table applies to Block References, MInsert Blocks and Multi-View Block References. For a Property Set Definition to be available to a Schedule Table, it must apply to at least all of the object types to which the Schedule Table Style applies. (The Property Set Definition can apply to more object types.)

If you have any plans (current or future) to use the properties in your Unistrut Clips Property Set Definition in a Schedule Tag, you will want to remove the space character from the name. UnistrutClips would be fine. The same applies to any property names within the Property Set Definition. The reason is that attribute tags cannot contain a space character, and the name of the Property Set Definition as well as the name of the property are used in the attribute tag of the attribute that displays that property in the view block assigned to the Schedule Tag's Multi-View Block Definition.

[jasonp]

Adding on to this some, I've resolved most of the scheduling issues I had with the blocks, but now I've gone on to rack objects. I have what should be a simple field I'd like to stack the property sets on, but I'm seeming to fail on finding code examples, or building my syntax correct in the "Formula" area.

In the attached drawing, there's a field called "Test1" where I've been guessing/experimenting on the correct expression to do what I want. The structural components for the rod and unistrut both have a "FINISH" property set, and I simply want the schedule to have one "FINISH", "LENGTH" and "DESCRIPTION" column, and the source to come from either component. (Both finishes will not be the same, one comes from MFR available supplied material, the other is an ASTM code.

In the attached file, "TEST1" has simply the property set from both property set source tacked on to each other. This is great, but I don't want the "?" displayed from the concatenated fields.

[dkoch]

In concatenating two different properties, you will get both values; since one of the properties is not currently on any given object, you will get the "?", indicating that that property is missing from the object.

While it would be possible to display values from different properties in one column, the gymnastics required to do so are unnecessary, since both the threaded rods and unistrut pieces are the same object type - structural members. Why not have one Property Set that holds all of the definitions, and attach it to all of the objects. Then you would have one Finish property, which could appear in one column.

There do appear to be properties that only apply to one of the two objects. I have not looked at all the properties in detail. If there is a strong reason not to have properties that only apply to one of the two item groups being scheduled, you could have three Property Sets - one for common properties, one for just threaded rods and one for just unistrut. All three could appear in the schedule - but you will get "?" for the properties that are only attached to one group.

[jasonp]

I never thought about doing it that way. It makes sense though, I'll rework my property sets to work with an additional combined property set. To be honest, it never even occurred to me.

Thank you!

[jasonp]

Ahh that's why I didn't make a combined property set. The Material finish is from two different lists. One is an ASTM# for the structural all-thread, the other is a MFR finish for the strut. We revisited of how our department needs to schedule the information though, and I think we're going to make it more generic and let project specification determine the finish from the MFR data. There's a fine line between detailing, and swamping our group with having to input too much data all the time on components. I can use a combined list this way as well, hopefully making the BOM less confusing for our fab shop/field.

[dkoch]

You can still have separate finish properties, with separate lists. The separate finish properties could be in the individual-only Property Sets or in a combined Property Set. You already had a Classification set up to distinguish between All-Thread Rod and Unistrut. In the modified version of your file, attached, I created a new object-based Property Set Definition, intended to be applied to both All-Thread Rods and Unistrut. There is a classification property, which reports the classification assigned to a given object, and a formula property, which, based on the value in the classification property, returns either the All-Thread finish property value, or the Unistrut finish property. This property can then be added to your Schedule Table, and, in a single column, report the finish value for a given item (last column on right, in attached file).

If more types of structural members were to be added to the Classification Definition and the Schedule Table, the formula property could be edited, and additional Case statements added to cover the additional types.

I suppose this could have been done in a formula column in the Schedule Table; unless I need a quantity value as part of the formula, I prefer to use formula properties over formula columns, but that is just me.

[jasonp]

THIS was the missing key! Thank you SO much! I couldn't find anything on how to do the coding with the stacked property set on the schedule. I can reuse this in a few other places to really optimize what I have going on!

Thank you VERY much!