Retrieving Routing Preferences for Pipe Types

Retrieving Routing Preferences for Pipe Types

colin_magner
Advocate Advocate
4,288 Views
11 Replies
Message 1 of 12

Retrieving Routing Preferences for Pipe Types

colin_magner
Advocate
Advocate
I'm writing an addin to duplicate pipe types, which requires duplication and renaming of associated fittings as defined in the routing preferences for the type. I'm able to retrieve the pipe type OK, but when I try to retrieve the builtin parameters that store the routing preferences the values that are returned are for a different type. The same happens when I use "Revit Lookup", which makes me suspect there's an API issue, rather than an addin issue. Has anyone else managed to retrieve routing preference information for pipe types successfully? To replicate the issue with "Revit Lookup": 1) Create a new project that contains Pipe Types (I used the Autodesk template "UK Pipe Template.rte") 2) On the project browser, select a pipe type (for example "Families > Pipes > Pipe Types > Copper - Press-Fit") 3) Activate Revit Lookup using "Snoop Current Selection..." 4) Select the "Parameters" item 5) Click the "Built-in Enums Snoop..." button 6) Select a builtin parameter that corresponds to pipe routing preferences, for example "RBS_CURVETYPE_DEFAULT_TEE_PARAM" 7) Revit Lookup shows the "As Value String" returning "Branch - Push-Fit - SS: Standard". If you edit the routing preferences using the Revit UI "Junction" is set to "Tee - Press-Fit - CU: Standard". This difference occurs for all of the builtin parameters and pipe types that I've tried.
0 Likes
Accepted solutions (1)
4,289 Views
11 Replies
Replies (11)
Message 2 of 12

colin_magner
Advocate
Advocate

Sorry - noticed after posting that the formatting got messed up making the post very difficult to read - so re-posting to try and sort out formatting:

 

I'm writing an addin to duplicate pipe types, which requires duplication and renaming of associated fittings as defined in the routing preferences for the type. I'm able to retrieve the pipe type OK, but when I try to retrieve the builtin parameters that store the routing preferences the values that are returned are for a different type.

 

The same happens when I use "Revit Lookup", which makes me suspect there's an API issue, rather than an addin issue. Has anyone else managed to retrieve routing preference information for pipe types successfully?

 

To replicate the issue with "Revit Lookup":

 

  1. Create a new project that contains Pipe Types (I used the Autodesk template "UK Pipe Template.rte") 
  2. On the project browser, select a pipe type (for example "Families > Pipes > Pipe Types > Copper - Press-Fit") 
  3. Activate Revit Lookup using "Snoop Current Selection..." 
  4. Select the "Parameters" item 
  5. Click the "Built-in Enums Snoop..." button 
  6. Select a builtin parameter that corresponds to pipe routing preferences, for example "RBS_CURVETYPE_DEFAULT_TEE_PARAM" 
  7. Revit Lookup shows the "As Value String" returning "Branch - Push-Fit - SS: Standard". If you edit the routing preferences using the Revit UI "Junction" is set to "Tee - Press-Fit - CU: Standard".

 

This difference occurs for all of the builtin parameters and pipe types that I've tried.

0 Likes
Message 3 of 12

jeremytammik
Autodesk
Autodesk

Dear Colin,

 

Thank you for your query.

 

Please pardon my ignorance in this area, but I do not know what exactly you are referring to when you say "This difference occurs..."

 

You have described the behaviour that you observe.

 

However, I am unclear on what exact behaviour you might be expecting, and what difference you mean.

 

Unrelated to whether I understand the problem or not, I have a suggestion for you, simply based on the fact that you say, "I'm writing an addin to duplicate pipe types, which requires duplication..."

 

For duplication of elements, types, views, marterials, etc., all kinds of things living in the Revit database, the Copy and Paste API is normally the easiest way to go:

 

http://thebuildingcoder.typepad.com/blog/2013/05/copy-and-paste-api-applications-and-modeless-assert...

 

If you can make use of that, it will hopefully handle all the parameters attached to the types automatically.

 

I hope this helps.

 

Best regards,

 

Jeremy



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

0 Likes
Message 4 of 12

colin_magner
Advocate
Advocate

Thanks for the response Jeremy.

 

To clarify the difference I refer to - if you take the example of the copper press fit pipe type in the UK Pipe template, when I edit this pipe type using the Revit UI, by double-clicking on the pipe type on the project browser, and then click the routing preference button, the dialog that opens shows that there is a pipe fitting "Tee - Press-Fit - CU: Standard" assigned to the Junction category.  If I query the builtin parameter "RBS_CURVETYPE_DEFAULT_TEE_PARAM" for this pipe type it returns a different pipe fitting (in this case a stainless steel fitting) to the one defined in the routing preferences.

 

I added a test of reporting as many builtin RBS_CURVETYPE_DEFAULT_ parameters as I could, across all of the pipe types, and they all reported incorrect family assignments.

 

The behaviour I'm expecting is for the API to return the same family and type as defined in the routing preferences via the UI.

 

To explain a bit more about the addin - I have a project requirement to add a classification parameter to pipework as a type parameter, to be used elsewhere for 4D and 5D analysis.  The nature of this classification system is that the classifications refer to the type of system, and not to the material.  I would have preferred to add the classification parameter to the pipe system definition instead but the 4D/5D work will be done via IFC and if I bind  a shared parameter as a project parameter to pipe sytems, this information doesn't get exported with the pipe objects to IFC.

 

My solution to this (which I'm not keen on from a 'BIM' perspective incidentally) is to duplicate the pipe types, so that I would have a Copper pipe type for each required classifcation, e.g. I would have a copper pipe type for hot water, a copper pipe type for cold water and so on.  I can then just bind the parameter to pipes and this finds it way to the IFC.

 

For this to work correctly I also need duplicate the associated fittings, rename then, and assign them to the newly duplicated pipe type (thanks for your building coder post that showed me how to do this by the way!), so that I can also assign the classification parameter to the fittings.  This is the primary reason why I'm trying to retrieve the builtin parameter values.

 

Hopefully that clarifies what I'm trying to achieve, and the issues I'm experiencing with it.

 

Regards,

 

Colin

0 Likes
Message 5 of 12

jeremytammik
Autodesk
Autodesk

Dear Colin,

 

Thank you for your update and clarification.

 

Oh, and also for the blog post appreciation. What is the link to the discussion you are referring to, please?

 

For the moment, I am only reading the first half of your answer, explaining the differences that you observe and the behaviour that you expect.

 

I agree with what you say.

 

Could you therefore please provide a reproducible case for me to submit to the development team to ask them what is going on?

 

http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

 

Please include a single-click compile, install and load add-in, plus the UK template file you are referring to. Thank you!

 

Maybe we are approaching this whole thing wrong, maybe there is a misunderstanding somewhere.

 

For instance, the routing preferences and the built-in parameter may in fact have different meanings, different from each other and different from what we think.

 

Once we have that sorted out and understand that side of the issue better, please prompt me to re-read the rest of your message again 🙂

 

Thank you!

 

I hope this helps.

 

Best regards,

 

Jeremy



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

0 Likes
Message 6 of 12

colin_magner
Advocate
Advocate

Thanks Jeremy.

 

The easy bit - this is the blog post I referred to.

 

The more difficult bit - I will attempt to reproduce my addin in the form requested.  Where I work we have a framework for addin development and deployment, so we no longer tend to make standalone addins.  (I think you've also posted about this previously but can't find the link now).  I can create a a solution with a test adidn in it, but to be honest programming isn't my day job so I'm not sure about the single-click compile, install and load addin.  Looking around a bit I guess starting with your add-in wizard would be the way to go?

 

Regards,

 

Colin

0 Likes
Message 7 of 12

jeremytammik
Autodesk
Autodesk

Dear Colin,

 

Thank you for the update.

 

Yes, absolutely, the add-in wizard should make it a snap.

 

Cheers,

 

Jeremy.



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

0 Likes
Message 8 of 12

colin_magner
Advocate
Advocate

Hi Jeremy,

 

Sorry for the delay, my day job took over...

 

Please find attached a zip file containing the solution and project template as requested.  This is a purpose built project that does the minimum required to demonstrate the issue.

 

To reproduce the issue:

 

1) Open the attached project "UK Pipe Types".

2) On the Project Browser navigate to "Families > Pipes > Pipe Types" and double-click on one of the pipe types.  On the dialog that opens click the "Edit..." button on the "Routing Preferences" line, and note the families and types selected for the various options.

3) Cancel those 2 dialogs to return to Revit.

4) Run the addin and select the pipe type from the Combobox that you reviewed in step 2.

5) Note the values returned by the addin and compare against those shown via the Revit UI in step 2

6) The values should match, but in my case they do not. (I have tried several templates and numerous pipe types)

 

The image below shows an example:

 

Pipe Type Sample.png

 

I hope this matches what you expect from a reproducible test case, but if not please let me know.

 

Regards,

 

Colin

0 Likes
Message 9 of 12

jeremytammik
Autodesk
Autodesk

Dear Colin,

 

Thank you for the update and reproducible case.

 

It looks absolutly perfect like this.

 

I passed it on to the development team for further exploration by submitting the issue REVIT-76496 [pipe type routing preferences differ between API and UI] on your behalf. Please make a note of this number for future reference.

 

I hope this helps.

 

Cheers,

 

Jeremy.



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

Message 10 of 12

colin_magner
Advocate
Advocate
Brilliant, thank you very much.
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses
0 Likes
Message 11 of 12

jeremytammik
Autodesk
Autodesk
Accepted solution

Dear Colin,

 

The development team resolved the issue:

 

The parameters like RBS_CURVETYPE_DEFAULT_CROSS_PARAM are no longer being used, since Revit 2013.

 

We should obviously remove these parameter ids to reduce potential confusion. Sorry about that.

 

Instead, the correct usage (UI or API) is to go through the routing preference manager. For example:

 

  // Get the routing preference manager:
  
  RoutingPreferenceManager rpm = ductType.RoutingPreferenceManager;
  
  // Get the first rule of crosses:
  
  RoutingPreferenceRule rpr = rpm.GetRule(RoutingPreferenceRuleGroupType.Crosses, 0); 
  
  ElementId fittingId = rpr.MEPPartId;

 

The Revit SDK samples include the sample 'RoutingPreferenceTools' that provides more insight on how to traverse, add and delete routing preference rules.

 

We have accordingly closed the issue REVIT-76496 [pipe type routing preferences differ between API and UI] that I raised on your behalf, with a resolution of 'Works As Expected' and 'Workaround Provided'.

 

The Building Coder has discussed a number of aspects of using the routing rpeferences as well.

 

Sorry I did not point out that approach right away up front.

 

I hope this helps.

 

Cheers,

 

Jeremy



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

Message 12 of 12

colin_magner
Advocate
Advocate
Jeremy,

Thanks for the feedback and direction to the new approach.

Regards,

Colin
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses
0 Likes