Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
Dan and I just looked at some data in the last month related to this issue. My initial read on this request was that if you could do it with Joints why should we spend our resources adding it to constraints? My team has a long list of improvements and I didn't really want to duplicate functionality.
What we looked at was Joint vs. Constraint usage using our Autodesk Data Platform (formerly CIP) data and I think we are leaning towards adding this to constraints since Joints is not as highly used as constraints, the data surprised me actually.
We are attempting to firm up this decision in the short term.
I appreciate the focus on other important improvements, but I'm glad you've seen data that indicates why so many people still wanted this functionality for traditional constraints--because constraints are more widely used.
I personally have four main reasons for preferring constraints over joints. They may be representative of the reasons many other users prefer constraints, and they may not. But either way, I hope it's helpful feedback.
Legacy. Constraints are what we've always used. They're what's in all our existing assemblies. If we started using joints, some of our assemblies would be a jumbled mix of the two.
Experience. I've used constraints for a long time. I know exactly how they're going to behave in a given situation, such as if the geometry on one of my parts changes or I change another constraint. I've had a lot of practice applying them and know before I even start assembling what constraints I want to apply and what button-presses I need to get there. Why would I switch to something that I know less about how it will behave and have less experience applying? Especially when I don't see a huge speed or robust-ness advantage to using joints.
Application. My understanding is that joints are intended primarily for getting a robust and accurate representation of the types of motion in a moving mechanism. At where I work, we almost never build moving mechanisms. We build large equipment which is stationary except for a few moving components. I just don't have much need for an assembly tool geared towards the types of motion in a flexible mechanism.
Issues. When I tried using joints back when they first came out, all I experienced were issues and confusion. The alignment options were confusing and I didn't like that I was building so many dependencies into one Joint command. I just knew that down the road I'd make one part change and all sorts of joints would get thrown off because they had so many inter-related dependencies built into them. And sure enough, this happened. And then the worst thing of all happened: I started trying to repair my assembly, and realized I couldn't say "OK" and apply my changes to a joint if there were relationship conflicts still existing when I try to apply it. This was the nail in the coffin for me. I believe this was fixed in later releases of Inventor, but it was too late. My constraint-centric approach had already been chosen and set in stone.
3. Application. My understanding is that joints are intended primarily for getting a robust and accurate representation of the types of motion in a moving mechanism. At where I work, we almost never build moving mechanisms. We build large equipment which is stationary except for a few moving components. I just don't have much need for an assembly tool geared towards the types of motion in a flexible mechanism.
Almost everything I do is representative of moving mechanisms that goes over the Dynamic Simulation Environments. Everything we do over there is Joints.
Unfortunately the Assembly Joints do not translate to the DS Joints. (at least that was the case last time I checked - I kind of gave up checking from release to release)
Dan and I just looked at some data in the last month related to this issue. My initial read on this request was that if you could do it with Joints why should we spend our resources adding it to constraints? My team has a long list of improvements and I didn't really want to duplicate functionality.
What we looked at was Joint vs. Constraint usage using our Autodesk Data Platform (formerly CIP) data and I think we are leaning towards adding this to constraints since Joints is not as highly used as constraints, the data surprised me actually.
We are attempting to firm up this decision in the short term.
Personally I'm not really surprised by the CIP data at all..
We "grew up" on constraints and really there isn't a huge difference between the 2 with the exception of DOF.. (I think thats about the only difference)
It really seems like the exact same functionality just presented in a new way (like mini-tool bars vs regular dialog boxes)..
When joints first came out I glanced at them and said.. "Seems just like constraints.. not sure of the benefits to one vs the other"
So I/others stuck to what we knew already.. To this day I still really can't grasp why one is better than the other or when joints should be used and constraints shouldn't.. (but again I haven't spent much time if any with joints)
Of course I also don't see the need to "lock" DOF on an insert constraint on a fastener either.. I've left my bolts/screws/nuts spinning for ever and I don't know if there is any benefit to locking them (no idea if it effects processing/calculation time of the model data or anything to have unconstrained DOF's.. I would think so but don't know.. heck might be the opposite too in that more locked DOF actually requires more processing/calculations)
@Ben-Cornelius, if it's not past the point where you can edit this, you might want to edit it and add that we know about Rigid Joints and specifically want to be able to do this instead of using the Rigid Joint.
Fortunately though, according to this thread, Autodesk is "leaning towards adding this to constraints since Joints is not as highly used as constraints." That's not to say they've committed to it, but they're leaning towards it it seems. So that's good news.
Dan and I just looked at some data in the last month related to this issue. My initial read on this request was that if you could do it with Joints why should we spend our resources adding it to constraints? My team has a long list of improvements and I didn't really want to duplicate functionality.
What we looked at was Joint vs. Constraint usage using our Autodesk Data Platform (formerly CIP) data and I think we are leaning towards adding this to constraints since Joints is not as highly used as constraints, the data surprised me actually.
We are attempting to firm up this decision in the short term.
Hi steven.dennis,
I commend you and your team for looking at the data to see how users are using the program, but it surprises me, that it surprises you that the use of joints did not catch on, and that constraints are the more popular solution.
There is a conversation to be had about how the development team gathers and interprets user feedback I suppose, but I do see some improvements in this area and want to say thank you for the effort.
However....
My initial read on this request was that if you could do it with Joints why should we spend our resources adding it to constraints? My team has a long list of improvements and I didn't really want to duplicate functionality.
This statement concerns me.
Adding the ability to the insert constraint should not be looked at as duplicate functionality, but instead consistentfunctionality. (please allow me to add some punctuation to this in case the larger font, red, bold, and underlined text, is not enough to convey that it is consistency across the tools that is important to the users ) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!....!
My point with that sentence was that, given two assignments to complete and I only have time/resources to do one I will always choose the one that let's you do something you CAN'T do at all today. I hope you don't have a problem with that statement!
In some cases the workaround to accomplish something is egregious and we do add "duplicate" functionality (in my opinion it's duplicate).
I get your concern but I have a BIG list of things you guys want improved and I have to prioritize somehow and consistency is not always the #1 priority filter. It is a filter of course... I just think that you need/want things you can't do to bubble to the top rather than something that can be accomplished albeit in a different fashion. In this case if the usage of Joints was higher I would personally still be standing by my original statement but the data does not support that.
As to why I was surprised, Joints do work. They do reflect the "real" world better. Remember I have been around Inventor for 18+ years now, as long or longer than most of you, so I get the "old" way of doing things. I just thought usage of Joints would have been higher and supported my initial decision not to put this at the TOP of our list.
Some good discussion here. I personally think two things would help the situation, as far as joints are concerned:
Create a nice video and/or help page targeted specifically at long-time users of traditional Constraints, and explain when and why we would want to use Joints instead of Constraints (or even vice versa--I'm still unclear on if Joints should be able to fully replace constraints or if it's expected that sometimes constraints are still necessary). Also explain how we should modify our way of thinking and our workflow to use Joints properly and to make ourselves more efficient.
Create a more detailed tutorial (video or help page) on each Joint type, when to use each type, and the options associated with each.
BONUS: Make assembly Joints carry over into the Dynamic Simulation environment. It seems like this would be an obvious reason to opt for Joints, and may be one reason many users haven't.
As far as the Constraint rotation-lock and where it stands in "The List", I definitely get what you mean about prioritizing things that are impossible above things that are maybe not optimal but are possible. However, I think the issue here is that Constraints are extremely ubiquitous. They may never go away, no matter how accepted Joints become. But they are definitely ubiquitous right now, and as far as most people are concerned, it's not worth breaking rank for just one type of constraint (er, relationship) just to get this rotation lock functionality. So in that sense, adding rotation-lock to the Insert constraint is not duplicate functionality--it's adding functionality that most users do not (even if by choice) currently have.
All that said, creating videos and tutorials like I suggested above might help alter that choice.
(I'm in no way meaning to come off as augmentative here, so please forgive me if I do)
>> My point with that sentence was that, given two assignments to complete and I only have time/resources to do one I will always choose the one that let's you do something you CAN'T do at all today. I hope you don't have a problem with that statement!
I like that statement, a lot. And I understood that you were making the first statement about adding the insert constraint lock functionality, and I looked at it in the broader view of improvements overall.
But I would say that even this 2nd statement (concerning doing something you CAN'T do at all today) is not reflective of so many of the improvements we've seen in Inventor over the last many years, where new ways to do the same thing were added, and in doing so created inconsistencies.
>> In this case if the usage of Joints was higher I would personally still be standing by my original statement but the data does not support that.
And I get that resources are limited, they always are (or at least should be), but I would contend that if Joints and Constraints had an equal adoption rate/level of use, it would be a mistake to add functionality to one over the other, without expecting that change to immediately add yet one more improvement request (to fix the inconsistency by improving the other) to the list.
The inconsistency is feeding the BIG list and making it BIGGER. Agile keeps a team moving and allows a more efficient use of resources, but by nature of that process it does feed inconsistency when it is used on existing, mature, platforms. I'm sure there is a middle ground to be found, and I suspect it involves vetting improvement ideas a bit differently to start with. More of a "sniff test", than a series of filters. Or a "sniff test", an then a series of filters.
>> As to why I was surprised, Joints do work. They do reflect the "real" world better. Remember I have been around Inventor for 18+ years now, as long or longer than most of you, so I get the "old" way of doing things. I just thought usage of Joints would have been higher and supported my initial decision not to put this at the TOP of our list.
I think to the average, experienced Inventor user, Joints dropped out of the sky, and users simply stepped over them. For any user (new and old alike) Joints offer no obvious and distinctive benefit over constraints, regardless of the fact that they do work, and that they do reflect the real world better (which I might tend to agree with). I do recognize that on paper, joints should have been more successful because they offer the advantage of being able to use fewer relationships to do the same task, but as implemented this is not obvious.
The disadvantage of joints is in the interface, as many users ( almost quite literally ) don't connect the dots to figure out that they can hold ALT and slide the cursor to place the joint using anything other than the initially highlighted center grip. And so the disadvantage of the interface out weighs the advantage of placing fewer relationships, which squelches adoption.
So I think the lack of adoption of Joints is less about old dogs and new tricks than we might guess.
I think the primary need for this is with hardware, which the majority of the time for me is placed from content center in which case you are defaulted to constraints and not joints. This is nothing new and has been asked for through AUGI back in 2012(Active wishlist item), hence I Kudo'd it once moved to the idea station. I have seen that having an opinion that something is the same has lead to ideas being forever marked as "Duplicate". Specifically a suggestion called "Add a "width" constraint", the difference is in the detail, but that difference can add up. This is why I understand Curtis' concern.
GREAT discussion points! I can "argue" with the best of them and I am not taking it personally, just trying to clarify my POV, email/forums SUCK for that.
If any of you are going to AU and want to continue the "prioritization/consistency" talk over a beer please attend my class or find me in the Answer Bar!! We can get a beer and get the the meat of the issue faster than back and forth here!
Las Vegas is a long way to go from here. I like Joints, and I'd use them much more, but I've seen some problems in the past.
Let me ask:
1. Is the "repair dead-end street" of broken joints solved? Only deleting and re-applying them could be done, no editing
2. Can Joints be used in Studio environment?
3. Can Joints be transferred to Showcase?
4. I'd like to use Joints with LEGO or Fischertechnik. But handling small edge fillets on these parts is a problem. If Joints could snap to intersection points of 3 faces and there's a switch for this mode, placing connections between LEGO bricks seems easy
Can someone explain to me how insert constraints determines the direction of the part?
In principle an edge has No front or back whereas a face does.
I am ask this as I have seen many people use insert constraint to assemble their assembly and I have seen theses assembly break and flip due to the insert constraints.
It is also the primary cause of locking up an assembly that is designed to move.
i prefer it if i-mates would lock rotation of a fastener or concentric mate had lock rotation option as per SW and SE.
