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
Not an expert here, just deducing from years of usage-- an edge does have direction, because it's the intersection between a circular feature (defines the axis) and a planar face (defines the direction). For a simple hole through a flat plate, when placing the constraint, you can easily see the vector flip directions as you slide your cursor from one end of the hole to the other.
But for more complex geometry, such as chamfers, fillets, etc., sometimes the vector goes the wrong way, when Inventor's assumptions turn out to be incorrect. But in general, I've found the the Insert constraint to be pretty bulletproof, and I rarely constrain the rotation angle of fasteners.
And, I've used Joints a few times, but found them to be unintuitive and awkward. Never did figure out how to use Joints to create a Flush or Mate relationship between two parts' origin planes, which is often where I begin during the design process.
Sam B
Inventor Professional 2016 R3 SP2 Vault Basic 2016 SP1 Windows 7 Enterprise 64-bit, SP1
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
Thanks in advance for your answers
Walter
Walter, here is the answers I got from one of our Joint testers.
1. In 2016 SP2 and 2017 we fixed the issue with the missing accept button on Joint creation and we are actively working on Joint error handling and repair.
2. Not yet
3. No and neither can constraints
4. No.
for 2-4 do you know if there are idea station posts for them yet?
....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....
Can you attach an example that exhibits this behavior?
I do not recall ever seeing this behavior myself or recall seeing this behavior reported here in the past.
No as this is propriety information and the last one that exploded like this took a month to fix.
I understand this but I can't fix what I can't reproduce. I'll try to keep an eye out for this but like JD said I've never seen or heard of this one. Let me know if you can ever reproduce it in a simple case or something you can share.
Hi Steve, thanks for your informative answers. I'd like to add some comments.
1. I've had these issues in the past with broken non-editable Joints, and I've noticed, that development has worked against it. I didn't do intensive tests about the new situation, so I can't tell much about success. On the other hand, I'm still having problems with flexible assemblies and driving constraints. Let's hope you're working there, too.
2. It is, as it is. I think, that's not enough. We can animate Constraints in Studio, but not at all any Joints. So, if anyone is focussing on a Studio animation, Joints are no way to go. But we have arrows in browser instead of +/- signs
3. Joints are not possible in Showcase transfer, but Constraints can be done. See attachment.
4. I'll come back later with my idea, hoping it's not buried then in Idea Station.
I voted for your idea, I like it, and have worked on product families that were panels and blocks, that begged for something like this to reduce the tedium, but mostly I voted for it because I thought steven.dennis and team need more improvements to work on (just to keep them off the streets at night).
But I have to say that it reminds me of some other ideas that were implemented in the not so distant past. Maybe "brick mode" is really just a refinement of Grip Snaps and/or Assemble Mode to make those compatible with joints and add some ... (wait for it) ..........Consistency to the tools!!!!!!!!!!!!
Grip Snaps:
Another way to assemble your assemblies but without constraints. Intended for place and ground workflows. Great idea for static assemblies that do not need the computational overhead of constraint relationships. I was excited about this when it came out, as I'd done a great deal of assembly work in AutoCAD 3D in the past using Osnaps, but the interface was poor and very inconsistent with other assembly interfaces so I don't think anyone ever really used it. I'm not sure that Autodesk has touched Grip Snap since introduction.
A quicker way to create constraint relationships. Fairly well received, and the interface seemed acceptable to people, but it was not updated to make it consistent with creating Joints:
( I'm hoping to make it to AU this year and have a beer with steven.dennis and speak more about this, but by the time December get's here, I'll probably have beat this dead horse to the point that he puts me in head lock as soon as sees me ).
I had this facility in solid edge from v20 Onwards for locking a concentric mates they added the facility to their mate wizard which is like i-mates back in 2008 to ST3 how come it take 8 years for Autodesk to catch up with solid edge on simple stuff like this?
I had this facility in solid edge from v20 Onwards for locking a concentric mates they added the facility to their mate wizard which is like i-mates back in 2008 to ST3 how come it take 8 years for Autodesk to catch up with solid edge on simple stuff like this?
smokes2998,
I can't answer that question directly... in the past 5 years or so I have personally become more involved in what gets worked on and what doesn't in my role as Tech Lead of Customer Success (used to be F3/JDI)... but there is a lot of fingers in the pie so to speak on what gets prioritized over what.
We are trying to refine that process and I think most will agree that we have gotten better at it in the last few years.
( I'm hoping to make it to AU this year and have a beer with steven.dennis and speak more about this, but by the time December get's here, I'll probably have beat this dead horse to the point that he puts me in head lock as soon as sees me ).
Curtis,
I would love to meet you at AU, either attend my class (Ask the Inventor Developer) or find me in the Answer Bar area, I'm there 90% of the time answering questions on Inventor.
In this thread there is a bit of discussion about the "why" of this idea: Basically the thought being that "loose" fasteners that can rotate add to Inventor's solver workload, as it considers the loose degrees of freedom.
But I'm not sure if that is true or not, as I've not ever noticed a difference or done any testing. But maybe some one has.
I would encourage users to provide more about why they feel this is needed.
Personally, though, the reason I want to lock the rotational DOF is not so much for screws and bolts (although I would probably use it for that). It's mostly for assemblies with a round component, maybe a collar, that I want to free-drag in order to re-position part of my assembly. If that collar is free to spin, trying to re-position the assembly by free-dragging it can be sporadic at best and futile at worst, because the collar is just trying to spin as I drag.
The collar is round (axisymmetric), so I don't care what rotational orientation it's locked at. I just want it locked so I can drag it and re-position my assembly as desired.
This is one kind of application where a rotation lock would be really handy for me.
I deal with a lot of components (screws, bolts, nuts, hydraulic fittings, etc.) whose rotational orientation doesn't particularly matter. However, although I don't really care what orientation it is in, I don't want it randomly changing because it may cause balloon or leader text arrows to follow the geometry in ways I didn't really want.
May not seem like a big deal, but I find it really annoying when a bunch of my leaders are now crossing part geometry or otherwise looking goofy because some bolts or fittings got rotated unintentionally. A rotation lock on an Insert constraint would be a great way to resolve this without having to add a bunch of angular constraints that are otherwise not really important.
I assume that you guy do bench mark the workflows and features of competitor products using a fully trained user in each competitors product.
If you did you would understand why users wonder why inventor is 5 to 10 years behind in development.
I had a shock when I went from SE to Inventor had poor the work flows were and how many workarounds are needed to do the same thing in SE ,that SE have a tool for.
I have to agree with Smoke, Inventor seems to loose ground every year. I used Solidworks for 7 years in manufacturing and for the last 7-8 years I have used Inventor. In both cases we put the software through the ringer with models of machines that are bigger that a three story house, to models the length of a city block. Primarily sheet metal and structural steel. Now keep in mind we would joke out about SolidQuirks, but when the majority of the time the fix for Inventor not working is restarting it 2-3 times a day (if it didn't crash), makes the Solidworks seem perfect.
The biggest thing is actually the littlest things that add up resulting in loss of time. I have seen many really good suggestions through the idea station and kudo'd them and have also made suggestions. Many times an Inventor user will chime in saying it already exists, it just requires a work around of 2-4 steps while the suggestion is citing doing it in one step. Then there is confusion on why doing 2-4 steps is a problem. There is a disconnect between the software and a natural workflow of using the package for manufacturing of large structures, alrighty rant is over.
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 ) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!....!
I posted a comment to another thread which I want to repeat here, because I think it's highly relevant.
To respond to this 3 years later... I definitely do NOT think that the "Show Sick" function resolves this Idea.
There are many cases where resolving conflicts using the Browser Tree would be more efficient than doing so with the aid of little icons in the Graphics Window.
There's no sure-fire criteria for which (the Browser Bar or the Graphics Area) is going to be more efficient for a given task. It's going to depend not only on the task but also the circumstances and personal preference. Sometimes you want to keep your focus on the actual parts that you're dealing with (hence this idea), and sometimes it's more efficient to work with an "outline" of your model. But you can't restrict one functionality to the Browser Bar and another functionality to the Graphics Area and think that you're doing the user a favor.
As much as possible, capabilities should be consistent between similarly-purposed tools (like those I listed above with the links). This is not duplicating functionality, it's being consistent. Consistency facilitates efficiency; inconsistency facilitates confusion, lost time, and frustration.
The Browser Bar and Graphics Area are, for all intents and purposes, similarly-purposed tools. Both of them are intended to let you interact with the components and features in your model. So in light of that... please facilitate some efficiency and implement model diagnostics in the Browser Bar as well, as requested in this Idea, not just in the Graphics Area. 🙂
I could repeat that last sentence almost verbatim except in regards to the "Insert Constraint Lock Rotation" functionality. In fact, to prove my point, I will:
Constraints and Joints are, for all intents and purposes, similarly-purposed tools. Both of them are intended to let you define how your Assembly components should interact and behave. So in light of that... please facilitate some efficiency and implement rotation lock functionality for the Insert constraint as well, as requested in this Idea, not just for the Rigid Joint. 🙂
Things don't always get done consistently simply due to resource availability sometimes. Sometimes we have to make a choice between releasing nothing or something but only in one area.
Simple numbers and availability. How "consistent" things work in two different areas sometimes require different expertise.
For example, I am one of the original constraint developers (from the application side, not the compute engine side) but I have never coded in the Joint area, that was done by a different team. So there is a learning curve for me to do Joint work (it is similar but different). That is just an example.
Just trying to be transparent and continue the conversation.
PS. the lock rotation is still on our list but we have not gotten to it this year.
Things don't always get done consistently simply due to resource availability sometimes. Sometimes we have to make a choice between releasing nothing or something but only in one area.
Hi steven.dennis,
Hey thanks for the reply!
I understand that resources are limited. They should be. Always. We never want to design and develop without considering resources, that's a good way to go broke.
I think of this as an issue of Design Requirements and Requirements Tracking, and the verification and validation process.
If consistency, correctness, and completeness are not part of the process of verifying and validating design changes, then it becomes very easy to make change management decisions weighted too much on just time and resource availability (or something else), and then end up down the line with:
a user experience that feels disjointed
a product that is difficult concerning change management
silos of experience in the design team
If we track and document the verification and validation of design requirements when implementing new features and changes, we can use that to:
bring the uninitiated up to speed
ensure that the left hand knows what the other three left hands are doing
deliver new stuff more seamlessly
I'm just not sure that I will ever agree that just adding something, when we do not have the resources to hold consistency, correctness, and completeness, is the right decision.
Unless maybe it is done over a phased implementation. For example, where we don't have the time to add "Lock" to the Insert constraint this time around, so for now we'll just add it for Joints. But we don't remove "consistency among all things Relationship" from the requirements, we simply leave it open and tackle it in the next phase/release, and then at the end of that phase we return to the requirement and verify and validate it so that the requirement is tracked and documented.
And then the next time anything under the umbrella of "Relationships" is considered, we look back at the past changes, interrogate the requirements to see what is impacted, and then we plan and execute on that plan.
I know the real world gets in the way, but that is exactly why we want to lean on Requirements, no?
