Change the system type for pipe creation via UI

[sniMD547]

Hello,

when you create a pipe via the UI, you can select the system type used for the creation in the settings of the pipe. (If you then create the pipe or not, doesn't matter, the selected type is saved within the document and used as default whenever you decide to create a pipe until you change it again). 

I found out that this setting is saved with the document but I can't pinpoint the location, and I also can't find a way to change it via API which is what I have to do. Does anybody know a way? 

I also have to change the cross-section parameters and the offset. For clarification, I attached an image of the settingsshown when the command to create a pipe is called, and marked the settings of interest.

Thank you!

[matthew_taylor]

Hi @sniMD547,

Have you looked at SetDefaultElementTypeId? http://www.revitapidocs.com/2017/bcd1ffba-2ddf-83b2-a243-fb0cfdba0b7c.htm

(There's an example in the SDK also.)

Not sure if it does what you're after though.

Cheers,

-Matt

[sniMD547]

Hi matthew.taylor,

thanks for your reply. Unfortunately, I already tried that, and it only changes the pipe type, for example from copper to steel.

Kind regards,

Sascha

[MarryTookMyCoffe]

I'm not 100 % sure if it's what you wanted, but I manage to change default pipetype for user with API, I used:

document.SetDefaultElementTypeId(ElementTypeGroup.PipeType, pipeType.Id);

and when I try using pipetype by UI  default type is last pipetype thet i created(i put this line in my creation Pipie type metod).

Before it was always Standard and now it is PEAL, so I guess it's work for me.

I thing you can change default diameter of pipe by changing parameter in pipeType.

[sniMD547]

Thanks for your reply, but I already tried that, and it only changes the "material" of the pipe.

What I want is to change the system type, e.g. to DomesticColdWater, and, in case of a pipe, the diameter, followed by the offset. These parameters have to be independent from the pipe type because they don't change if you change the pipe type, and if you change the system type for one pipe type, it's the same for all other pipe types.

[BardiaJahan]

@sniMD547 Those are called Instance Parameters. (i.e. system type is an instance parameter for pipes) and you would be able to retrieve and modify them through API. Try Pipe.SetSystemType method to change the system type of a pipe. And 'system type' property is associated with enum 'PipeSystemType'.

(I just corrected this reply.)

[sniMD547]

Thanks for your reply.

Edit: Maybe I misunderstood what you were trying to tell me. I'll try what I hope you were saying.

[BardiaJahan]

@sniMD547 Since Pipe.Create method has a systemTypeId input, after prompting the user to create a pipe (most probably by picking the endpoints), you can create a new pipe with a certain system type.

[sniMD547]

That's my alternative approach. The problem is that it is not very user friendly. With calling PickPoint two times, I have to find a way to show the user how the second point is in relation to the first point. I am sure I can manage that, but I would rather find out how to change the system type upfront and call the Revit command for pipe creation via PostCommand.

[BardiaJahan]

@sniMD547 I would also try creating a random pipe with the desired system type through API and then either roll back the transaction or delete it and let's see if the Revit UI keeps the system type as the active one or not. Could you let me know the result whenever you tried it?

[sniMD547]

I already tried that. It doesn't work that way.

[MarryTookMyCoffe]

I feel, like you don't really know how Pipes are made in Revit. You talk about PipeType, but then you call it material(PipeType are made from segments, fitting and some other things.), then you talk abaut parameter of type PipeType and finnnly you use example where you what to change a default PipingSystemType(which you can change just like a PipeType).

 My advice is, read more about difference in Family, Types, and see how it is with Pipe and PipeType
 

[matthew_taylor]

Hi @sniMD547,

My brain has been going hard at this issue since the flood of notifications hitting my inbox yesterday.

I came up with a workflow that may be worth testing:

1. Run an iUpdater in an application. Have it on added elements of the pipe category. Have it turned 'off' by some sort of singleton Boolean switch.
2. Get size/system/offset settings from the user.
3. Use SetDefaultElementTypeId to set the pipe type. (I am not sure this is necessary given we are using PostRequestForElementTypePlacement below.)
4. Turn the updater on.
5. Use PostRequestForElementTypePlacement to post the pipetype creation. This will not start until Revit has regained focus.
6. Once the first pipe has been added, the updater will fire. Change the first created pipe to the settings input in (2). Then immediately turn off the updater singleton Boolean switch. (We do this because we want Revit to handle the creation of fittings etc - we don't want to have to try to replicate that process.)
7. If the process works, handle issues such as adding to existing systems etc.

If your test code works, I'm sure that Jeremy would love to blog about it.

Good luck!

Cheers,

-Matt

[sniMD547]

Thank you for your reply.

I will try that if all else fails. I already thought about changing the system type of the created pipes after all pipes are created. But it could be that the view doesn't show the created pipes due to the system type. That could also be a problem of your solution, just only for the first pipe.

[jeremytammik]

Dear Sascha,

Thank you for raising your query here in public after we discussed some aspects of it in the previous ADN case 12586637 [Pipe Drawing: changing the used piping system type and prompting the pipe drawing command].

I raised a new ADN case 12656570 [Change the system type for pipe creation via UI] directly connected with this thread to keep things somewhat synchronised.

In your last comment on the previous ADN case, you summarised the situation like this:

"The way I understand it, we could retrieve the default system type for a certain system classification as described in the explanation of the 'Pipe.Create Piping System Type Argument' -- http://thebuildingcoder.typepad.com/blog/2014/01/final-rolling-offset-using-pipecreate.html#4:

  systemIdTypeId = mepSystemTypes.FirstOrDefault(
    st => st.SystemClassification ==
      MEPSystemClassification.DomesticHotWater );

However, we cannot alter it according to the section 'C The case of Pipe creation' -- http://thebuildingcoder.typepad.com/blog/2015/04/revit-api-trends-and-team-meeting-in-bretagne.html#....

Did I understand it correctly?

And is this also true for the start offset of the pipe and the diameter respectively the width and height?"

Unfortunately, I am not sure off-hand, so I cannot say anything either way without further research.

I think Matt's last suggestion sounds like a doable approach.

I would be a bit surprised if there is no easier way, though.

I feel this subject has come up before as well, so I checked the history of previous discussion threads here in the forum for topics related to pipe and pipe system types and came up with the following list:

• http://forums.autodesk.com/t5/Revit-API/Pipe-placeholder-set-system-type/td-p/3840383
• http://forums.autodesk.com/t5/Revit-API/Specify-System-Type-Hydronic-Supply-Pipe-Type/td-p/4521851
• http://forums.autodesk.com/t5/revit-api/how-can-i-set-the-system-name-for-a-pipe/m-p/6017010
• http://forums.autodesk.com/t5/revit-api/system-name-is-changing-after-new-pipe-is-created/m-p/565637...

Would it be possible for you to provide a minimal reproducible case so that we are all absolutely clear about exactly what we are talking about, and what you have achieved so far?

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

That might trigger further ideas.

Thank you!

I hope this helps.

Best regards,

Jeremy

[matthew_taylor]

Hi @sniMD547,

I agree.

You may want to create the first pipe length as a placeholder. That category is more likely to be visible.

@jeremytammik I also think that there should be an easier way!

Perhaps @arnostlobel has a suggestion?

Cheers,

-Matt

[jeremytammik]

Dear Matt,

Arnošt left the company and no longer works with Revit, I'm sorry to say. He is sorely missed, of course.

I suppose you guys have rules out all possibility of controlling the desired settings using the PipeSystemType argument passed in to the Pipe.Create method?

What is the proper name in Revit-speak for the settings that we are talking about here, and for whatever entity contains and controls them?

Surely it must have a sensible name that includes something beyond the totally overloaded and painfully limited vocabulary 'pipe', 'system' and 'type'?

Cheers,

Jeremy

[matthew_taylor · Accepted solution]

Hi @jeremytammik,

That is sad news. Who has taken over?

Once a pipe (DB.Pipe) has been created,

• the PipingSystemType is available in the RBS_PIPING_SYSTEM_TYPE_PARAM builtinparameter
• the Offset is available in the RBS_OFFSET_PARAM builtinparameter
• the Diameter is available in the RBS_PIPE_DIAMETER_PARAM builtinparameter#
• the pipe.PipeType is the value that can actually be passed legitimately to SetDefaultElementTypeId prior to calling PostRequestForElementTypePlacement. (I haven't tested this.)

@sniMD547 As I've been typing this message, it occurred to me that I'm not 100% sure of what you are trying to achieve. I have assumed that you are trying to set the above values so you can call PostRequestForElementTypePlacement, or call PostCommand with PostableCommand.Pipe. Can you confirm that that is what you are trying to do?

One other thought I had (which doesn't help much), is selecting a pipe (using the API) with the properties you want, and doing Create Similar with PostCommand. Not helpful if you're creating the first pipe with those parameters.

You could create a pipe (using the API) and then use create similar (with postCommand) to create a similar one, but that workflow doesn't allow for deletion of the pipe. You could do some post clean up though, I guess.

Cheers,

-Matt

[sniMD547]

@matthew_taylor: Yes, that is what I am trying to do.

Your suggestion sounds good if it is possible to create similar elements via the API. I'll look into it.

@jeremytammik: Thanks for creating a new ADN case. But somehow the case got closed shortly after you opened it. Do you know why?

I followed the links you provided. Unfortunately, I couldn't find a solution for my problem there.

I'll see if I could provide some sample code.

[jeremytammik · Accepted solution]

Dear Sascha,

I closed the ADN case. I just use it as a container for our discussion here in this thread. Whether it is open or closed makes no difference as long as we are aware of its existence and case number. All communication can take place via this thread. I hope that clarifies.

I discussed this with the development team, and they say:

You can provide the pipe system type as an argument to the Pipe.Create method:

Sample code:

  private List<PipingSystemType> m_pipingSystemTypes;
  private List<PipeType> m_pipeTypes;
 
  m_pipingSystemTypes = GetElements<PipingSystemType>().ToList();
  m_pipeTypes = GetElements<PipeType>().ToList();
 
  Pipe pipe = Pipe.Create(RevitDoc, m_pipingSystemTypes[i].Id, m_pipeTypes[j].Id, ...);

Also, the other two Pipe.Create methods take the connector as the input and automatically take the system type from the connector:

  static Autodesk::Revit::DB::Plumbing::Pipe ^Create(Autodesk::Revit::DB::Document ^document, Autodesk::Revit::DB::ElementId ^pipeTypeId, Autodesk::Revit::DB::ElementId ^levelId, Autodesk::Revit::DB::Connector ^startConnector, Autodesk::Revit::DB::XYZ ^endPoint);
  
  static Autodesk::Revit::DB::Plumbing::Pipe ^Create(Autodesk::Revit::DB::Document ^document, Autodesk::Revit::DB::ElementId ^pipeTypeId, Autodesk::Revit::DB::ElementId ^levelId, Autodesk::Revit::DB::Connector ^startConnector, Autodesk::Revit::DB::Connector ^endConnector);

As you noticed, the UI has a default system type as well as the default pipe type, even if the input does not include connectors.

That default value is saved in a SymbolIdMgr in the UI editor. Unfortunately, The SymbolIdMgr is not exposed in API.

That UI/API difference is similar for other non-MEP objects, like Wall objects.

There may be a problem with this second suggestion: the system (and thus the type) may not be assigned to the connector yet.

Maybe the first approach solves that and is already pointing to those?

Does that match your findings?

Cheers,

Jeremy