Custom subassembly built in Subassembly Composer act as a different subassembly when the other branch of a decision becomes valid

[madumitru1]

Hello friends,

I made a subbassembly for the shoulder, that allocate a space for a gutter in the situation when the slope of the carriageway send water to the gutter. If the slope is raised / superelevated, removes this space.

When I use this subassembly in Civil 3D, if the other branch of the Decision becomes valid, then the program acts like there is a different subassembly, even tough there is only a slight variation in the construction sequence, and the outermost point have the same number.

When I use this subassembly, the subassembly which is attached to it, jumps to the next subassembly (to the inside) whenever the carriageway is superelevated.

See the attached image which shows a typical example. The slope to surface subassembly which is attached to the shoulder act like in this area the shoulder disappeared. 

I attached a test dwg in which I have tried this subassembly and the archived subassembly.

Did you encountered a situation like that? And, more important, is there anyone that found a solution?

Thank you in advance for the help.

BR

Marius

 

[ecfernandez]

Hi @madumitru1, I opened your file and thought your shoulder had the slope daylight included within the subassembly. However, I noticed it is not included. Then, what is not working well is the attachment point you rely on to append new subassemblies to your shoulder.

Try to fix a point that is always present regardless of the decisions you evaluate in your logic branches. Try to do it and let us know if you can solve it.

As an idea, you could place a point that looks detached from the shoulder in the layout mode, which allows you to attach new subassemblies to it. Then, in roadway mode, it sticks to your shoulder, guaranteeing the correct geometry.

I hope this helps. Best regards!

[madumitru1]

Hi @ecfernandez. Thanks for taking your time to check the issue I have exposed.

1) the shoulder does not have the slope attached, because in the situation where I will use it I will have multiple other subbasemblies attached to it, and I prefer to have them separately. Only for this exercise I attached the Slope daylight.

2) In my case the attachment point is P8, which is present on both branches of the logic decision, so I don't understand the comment :"Try to fix a point that is always present regardless of the decisions you evaluate in your logic branches".

3) Please if you have an idea, adapt my subassembly and drop it back here, because I experimented multiple ways of solving this issue with no success.

Thanks and have a great day!

Marius

[ecfernandez]

Hi @madumitru1, I understand. Sometimes, it can be stressful when we try repeatedly and do not get the expected result. 

Look what I did to your subassembly. I created the attachment point I was talking about, and I ran your corridor and saw that it did not work. I was confused about what could be that it was not working properly, so I decided to erase your Decision and connect all of your geometry in a unique logic branch. I ran the corridor again, and it worked. 

My conclusion was that somehow, SAC gets lost after your decision. Look at the files I attached. If you keep it as I sent it to you (with the decision erased), you won't need the attachment point. You should be able to attach everything to P8.

Furthermore, I noticed that something is not working properly in your subassembly that causes your shoulder to look deformed when using it to the left (see image, I think it should look closer to the yellow line). When the subassembly had the decision, I noticed that L1 disappeared, making S1 unstable, having L1 sometimes and sometimes not.

If you have any questions, let me know. Best regards!

[madumitru1]

Hi @ecfernandez ,

I tried to open the attached subassembly  in SAC but I get an error. I have SAC 2022 and 2023. 

Have you used SAC 2024 to build it? I don't understand why I cannot open it.

I wanted to see the changes you made in the construction sequence.

Please can you retry to send it? Maybe using an older version of SAC if you saved it in 2024? Or at least some screenshots explaining the changes in the workflow.

Regarding the Datum line, this should slope to outside until the carriageway is superelevated up to 4% and over 4% should follow the superelevation.

The problem I am trying to solve is part of a bigger and more complex subassembly, with multiple decisions:

Thank you and BR

Marius

[ecfernandez]

Hi @madumitru1, sorry for that. I totally forgot to mention I worked in Subassembly Composer 2024, and I do not have any other version. I'll upload screenshots so you can replicate the changes in case you find them useful.

 This was the condition for the attachment point (P9) I was trying to create but did not as expected.

This is the error about the hatch I was talking about. This is because L1 does not exist in that logic branch.

I hope this helps. Best regards!

[madumitru1]

Hi @ecfernandez,

I tried your approach but did not work as expected. 

However, thank you very much for your effort, it is much appreciated.

I still hope there is a solution to this problem, unless it is a problem of SAC way of working.

Best regards!

Marius

[ecfernandez]

Hi @madumitru1, that is pretty weird. You can notice from the picture I posted and the attached DWG that it worked for me.

I wonder if you properly replaced the old subassembly with the new one. I mean, considering the C3D version you have, you must erase your old subassembly from the pallet and then insert it again using a new drawing different from the one you are working on (you must close your C3D completely and reopen a new fresh drawing); otherwise, C3D will understand you are currently using the subassembly and will give you a warning. 

If you update to 2024, you will be able to use the new functionality of assembly management that allows us to update our custom subassemblies whenever we want without all the processes I mentioned before.

Best regards!

[madumitru1]

Hi @ecfernandez ,

Sorry, I was not clear enough. I said it was not working in the sense that my problem was not solved.

Since you removed the logical decision from the construction sequence, the problem disappeared in your subassembly.

I added the point P9, with the conditions from your screenshot, but I did not remove the Decision from the top of workflow. As I explained earlier, I need this decision in my other subassembly, as the geometry is quite complex on the different branches of the logical decision.

With this construction, my initial problem is still present.

Thanks again and I hope that clarify the issue.

BR

Marius

[ecfernandez]

HI @madumitru1, could you please explain why you need the decision? What are you trying to achieve? 

I saw when the decision is false, L1 disappears. However, the geometry looks the same. Help me with an explanation of what you are looking for with this decision. I think we can get rid of it, but I need to fully understand prior to proposing something.

Best regards!

[madumitru1]

Hi @ecfernandez,

The subassembly I posted here is a very simplified version of what I am trying to achieve. It was built only to show the error I have when there is a variation on one of the branches of the logical decision, but the final attachment point is the same.

As I said in an earlier post, I am trying to create a more complex subassembly, in which the geometry is more complex (not only one link disappear).

This is the geometry I need when the slope goes to outside:

This is the geometry I need when the slope goes to inside:

I posted here the simplified version because it is easier to debug, and there is not so much information to dig out.

However, I am very happy that you took your time to investigate what the issue may be, and I hope you may have a good idea to solve it.

BR

Marius

[ecfernandez · Accepted solution]

Hi, @madumitru1. Thanks for posting the images. I have an idea to solve the issue.

Break down that subassembly into two different subassemblies. The first should be until the gutter and the next for the shoulder. (see image)

By doing this, you will be able to easily set logic branches for (Gutter and No-Gutter) and avoid the problem with the attachment point; you can follow the suggestion I gave you previously. That is, place an auxiliary point (AP1) before the decision that will always have the width of the subassembly and then a point that in Layout mode will be placed separated from the subassembly but in roadway mode will stick to it. Condition, for Delta X (IF(SA.IsLayout=True, AP1.X+1, AP1.x)), Delta Y AP1.Y; you can save these in variables or write them directly in the Delta field of the point.

In a similar way, for the shoulder, you can set logic branches for (Gutter, No-Gutter) so you can set the desired geometry depending on the same conditions you evaluated for the previous subassembly.

I hope this helps. Best regards!

[madumitru1]

Hi @ecfernandez ,

I used your idea and I modified my subassembly accordingly. I did not split it into two different subassemblies but, using auxiliary points, I recreated the final attachment point (where necessary I added conditions directly into Delta X or Delta Y fields)

This auxiliary points were created before the logical decision (Gutter, No-Gutter), that way they were not affected by the issue in SAC.

In the end, for the final point, I added the condition for Delta X (IF(SA.IsLayout=True, AP1.X+1, AP1.x)) and Delta Y AP1.Y  for the attachment point.

I tested it and it works 😀.

However, this is a problem of Subassembly composer, which it would be good if it is addressed by Autodesk. Maybe someone from Autodesk reads that and take some actions.

Thanks a lot, without your help, probably I would not make it work.

Best regards!

[ecfernandez]

Wow, that is really good to know. Thanks for sharing your comments. I'm sure Autodesk products will keep improving.

I'm happy to help. Best regards!