1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

give parts or assemblies a pseudo name, label or category for constraints auto name purpose

Discussion in 'General Discussion' started by Drutort, Dec 29, 2019.

  1. bigseb

    bigseb Alibre Super User

    That's not what I said. In the design tree you have listed all the parts (and sub-assemblies) in your assembly. Each part can be expanded and in it you will see the constraints that are used for that part. I am not talking about the constraint tree.
  2. bigseb

    bigseb Alibre Super User

  3. Drutort

    Drutort Senior Member

    And I think I mentioned that its annoying that we once again are missing some basic consistent features such as "rename" but on this topic we are missing basic "expand all" and "collapse all"

    Having to have to click on the +- on each part and then on each constraints section is a waste of time

    Also the issue that constraints do not have the (1) designation when you have same instance (duplicate) parts is a problem, so for you to tell me look its simple to find the constraints here are the examples below, be it in the "constraints tree" or in the part -> constraints section it is identical problem!

    Only the constraints tree has (left pic) expand all and collapse all, middle picture is from constraints tree, right picture is constraints tab of the part. This example I have has a few duplicate parts that connect to each over with constraints, notice how some ended up with same face but the instance (#) is missing. We need this fixed in Alibre and you can not tell what part is constrained to what part when they are the same features listed face/line

    constraints tree.jpg constraints example.jpg part section - constraints example.jpg

    This is described here too:
    Last edited: Dec 30, 2019
  4. bigseb

    bigseb Alibre Super User

    In the right pic you have it narrowed down to six constraints. Clicking on a constraint will highlight the constrained features in the model.

    And if that's still an issue why not just rename it?
  5. Drutort

    Drutort Senior Member

    The right pic is from one of the parts in an assembly, its confusing even to me. Pretty much I have to rename things for my own sanity, but that only helps a little.

    As that feedback suggestion states this problem, I suppose the system should show the instance of the part/assembly with the same <#> in the constraint section after the part feature <#>

    for example first one on right pic could be like this:

    RUNKO: FACE<13><9>
    RUNKO: FACE<13><11>

    OR any flavor of:
    <9>RUNKO: FACE<13>
    <11>RUNKO: FACE<13>

    It does not have to be <> could be # * () whatever it is so long as its defined in some logical way

    FACE<13> is the part (models) face number
    The <9> and <11> for example would designate the instance copy of the part/assembly

    constraints example 2.jpg

    actually the first <> is number of the part feature example face <13> of the model,.To me the instance <#> of the part/assembly is far more important

    We need to have both the feature number and the instance number whenever you have a duplicate of a part/assembly

    The issue is even worse because its a sub assembly and doing (ctrl) + click selects the part in the sub assembly, i then have to look in which instance of the assembly is this part

    I guess IMO this issue should take priority even over the whole rename thing

    In my project I think I have over 12 of them so that would be good, each part/assembly duplicate has a <#> so that should be designated to the actual par/assembly

    The issue is really amplified when I want to do main assembly configurations, and I have to suppress constraints and create different ones for the configuration at hand, while keeping the old constraints for each different configuration

    As I would do different styles/layout of my project all in one main assembly

    Also I suppose that renaming is only half the battle, as I can only rename the constraint, not the feature ie face, line etc... those are hard coded to the part instance
    Last edited: Dec 30, 2019
  6. idslk

    idslk Alibre Super User

    Hello Drutort,

    Regardless that a instance number would be ok, have you tried to change the color scheme for hover to a more intense color?


    if you hover over a constraint the participants will be more visible:



    Attached Files:

  7. JST

    JST Alibre Super User

    I do not think using the Label field will do all the things that a "name" should do.

    The name should be the main part/assembly identifier in the program, and the filename should just be a "handle" to use for identifying it to the OS for retrieval, etc. So, for instance, the part/assembly name should be what the "home" page of the program uses to identify what you are looking at.

    Then, if desired, the constraints could be ID'd as the Align of name1 and name2, for instance (although I don't really think it is needed)
  8. NateLiqGrav

    NateLiqGrav Alibre Super User

    I proposed this idea to Max a little while back in another thread and I believe he understands the need for identifying the instance. My hope is that it will be addressed in the next release along with the other design tree changes.
    simonb65 and Drutort like this.
  9. JST

    JST Alibre Super User

    I do not understand this supposed "problem".

    If you want to see the constraints for a part, just right click the part IN THE MODEL, and select "show part in explorer", which will highlight THAT particular instance among your 377 instances in the model.
    The only problem is that if that is in a subassembly, you will have to edit it separately to fix whatever you want to fix. So use "edit here".

    I still think this sounds like a request for mind reading. Or a magic wand to wave over the model.

    You DO have eventually to pick a specific part to edit, Not sure how the program can help with that. And in the picking process, you will have to do SOME sort of "click to select".

    You can run the cursor over the constraint tree, and see the affected part faces highlighted.

    Or you can select the part, and go look at the constraints, if you are not sure which part of the tree applies.

    But SOMEHOW you must select a part. And they each DO have unique names. Calling it a bolt instead of a 123-67507-A does not make a lot of difference, as there are many of them, regardless of name.

    I suppose f you called it a "waterpump mounting bolt", and called others of the same type "tension bearing mounting bolt", etc, you might be better off, but you have that ability now.

    Oh, yes.... if you have so many constraints that it takes scrolling for days to find the right one, then the model at that level is probably too complex. Use more subassemblies.
    Last edited: Dec 31, 2019
    oldfox likes this.
  10. It is much quicker to right click the part you want to change and select "Show part in explorer". No matter what you call the parts I'd rather do that than scroll through a 400 item list.

    Also wouldn't that screen shot you shared have the same issue?

    Align RUNKO to RUNKO <1>
    Mate RUNKO to RUNKO <1>
    Align RUNKO to RUNKO <2>
    Align RUNKO to RUNKO <3>
    Mate RUNKO to RUNKO <2>
    Align RUNKO to RUNKO <4>
    Mate RUNKO to RUNKO <3>
    Align RUNKO to RUNKO <5>
    Mate RUNKO to RUNKO <4>

    It's just as bad but it looks different... I'd rather devs spend time fixing bugs.
  11. NateLiqGrav

    NateLiqGrav Alibre Super User

    What @Drutort is asking for is something like:
    Align RUNKO<1> to RUNKO<5>
    where the numbers correspond to the different instances of the same part.
  12. Ok that makes more sense, thanks for the correction. I guess I don't really care if this gets implemented. I don't think it would really help me with my work flow. Even a well labeled list is much slower than right clicking the part. I almost never go to the constraint list unless I'm editing a constraint I just made.
  13. JST

    JST Alibre Super User

    Even there, you have to align some FEATURE of Runko<1> to Runko<5>, so you still need to do more identification.... unless I am not seeing the need correctly. So you at some point have to actually specify a part and feature to constrain to another part and feature.

    Therefore, unless you want to type all that out, you will be in the model pointing to the features to constrain. I find that about 40x easier than trying to issue instructions by typing.

    How does the proposal help with that?

    I see a possibility that in a "dense forest of identical parts", it may be necessary to find one in particular, but even there, I am not sure that locating in a list of identical parts is easier than finding the part in a model, where you presumably have some clue where it is, based on function, or the fact that you just put it there, etc.

    Now, if you wanted a "find function" for the tree, so that you could ask to find "Runko<17> and have it found by name, similarly to doing thet through the model, well I can get along with that OK.
  14. NateLiqGrav

    NateLiqGrav Alibre Super User

    There are many things being discussed here but nobody is asking to type this in manually. @Drutort is asking for constraints to automatically label themselves with more info and perhaps the ability to give nicknames or something to parts and assemblies for use in that label.

    I agree with the more automatic info - especially identifying the instance number.
    I'm not a fan of nicknames.
    I would definitely love user made groups or folders in the design tree.

    A "find function" could be beneficial to some with big assemblies.
  15. simonb65

    simonb65 Alibre Super User

    There was a discussion about this when Max was putting forward Alibre's ideas for a new look Constraints dialog, can't remember the link, but I'm sure a quick search will find it. From recollection, it was about automatically including constraint parameters in the displayed tree item text so that it made for easier reading of what each constrain is actually doing. Maybe only half of what @Drutort is after, but anything that makes things easier is a small step in the right direction for me.
  16. GIOV

    GIOV Alibre Super User

  17. JST

    JST Alibre Super User

    If you just refer to having an option to cause the constraints to each list the two items they refer to, that could be good. But it ought to be an option easily turned on and off, because it would have the potential to expand the design tree sideways into design space..... Would almost have to in order to be easily used.

    Then it would depend on the user identifying the part intelligibly for her/his use.

Share This Page