SWX 2004 limit mates bug

There seems to be a bug in distance limit mates when an assembly with
limit mates is inserted into another assembly as a flexible
subassembly. For instance, imagine a hydraulic cylinder with limit
mates to control the stroke of the cylinder rod. If the cylinder is
placed into another assembly as a flexible subassembly, the limit mate
shows as being overconstrained. My VAR doesn't care. If anyone else
does care, and you can confirm this behavior, could you submit this
for your VAR for an SPR #?
Thanks,
Eric
Reply to
Eric Zuercher
Loading thread data ...
I have an upper assembly open right now with several cylinders/mechanisms that were inserted with limit mates and flexible and I have no problems. I am able to move them all within their limits in the upper assembly.
Dave H
Eric Zuercher wrote:
Reply to
Dave H
Actually, you don't even need flexible assemblies to show this bug (feature?).
Say you have cylinder in which retracted length is 10" and extended is 20". You add a limit mate to limit the stroke. All is well. Now, you decide to constrain the length of the cylinder with a distance mate of, say, 15"....BAM!!! mate errors! Even though the limit mate and 'fixed' mate can both be mutually solved, they over constrain each other.
This is not the behavior I (or apparently you) were hoping for with limit mates. IMO, an error should occur ONLY when another mate pushes a limit mate outside its limits (say we set our 'fixed' mate to 9" in the above example).
Flexible assemblies are really nothing more than SWX solving the subassembly mates concurrently along with the parent assembly's mates, just as if the subassembly parts were actually in the parent assembly. Thus, I am betting that by placing your cylinder in an assembly as a flexible assembly, you are constraining its length similar to how I added a mate in my above example and getting the same mate errors.
Quote
EndQuote Perhaps it is time for a different VAR?
Reply to
Arlin
Same here.
Richard
Reply to
Richard Doyle
I would expect an error if I am understanding you correctly. You are asking it to provide motion within the range while at the same time requiring it to be at a fixed distance. How does this system know which one to honor? In what situation would you want both mates?
An analogous situation would be if you fixed it at 15" from one end and 5" from the other. Although the mates don't conflict with each other, they are redundant and the system is over constrained.
JJ
Reply to
JJ
I disagree. The fixed distance mate is telling it that it is fixed at a particular dimension and the limit mate says it can move. They are conflicting with each other and should result in an error if one or the other is not supressed.
Dave H
Arl> >
Reply to
Dave H
What I do is creat a configuration for the mode that I need. Limit mate when the cylinder is in context of its assembly, fully extended and fully retracted for drawing purposes and free floating for when I want to pull the pistion clear out of the barrel!
Reply to
Bruce Wirkkala
Exactly the same thing I do.
Dave H
Reply to
Dave H
This is it exactly!
I guess I can understand the VAR tech's confusion given some of the responses here.
Have you submitted it for a fix?
Regards, Eric
Reply to
Eric Zuercher
I have an assembly with a limit mate as described, but no overconstrained error. I did notice that the limit mate is a bit fussy about redundant mates such as a coincident mate where a parallel will do. That's my memory of it, anyhow. But I just checked the assembly, and it works fine.
Perhaps the VAR doesn't seem to care because the error doesn't occur when he tries to simulate the situation. Has the VAR tried the problem assembly?
Reply to
Dale Dunn
I see your point, but I respectfully disagree. Perhaps is is just a difference in perception on the function of the limit mate. You see the limit mate as a mate that requires motion in a specified range. I see the limit mate as not requiring motion, but rather to limit how that component can be constrained in an assembly.
Getting back to the cylinder example, I think limit mates should allow one to apply the limit mate, documenting the cylinder's limits. Then, other constraints (weather they are in the cylinder assy, or up a level when used as a flexible subassembly) should be allowed to fully define the cylinder length. Thus, when the length constraining mate constrains the cylinder WITHIN the limits of the limit mate, all is well. BUT, when something pushes the cylinder beyond the constrains of the limit mate, errors and warnings should pop up.
To me, it is all about design intent. SWX does allow redundant mates (usually) to help capture design intent. To mate a bolt in a hole, you only need a concentric mate and a POINT on a surface. Yet, using two flat surfaces helps capture design intent (the bolt head is flat on the surface) AND it is allowed by SWX. A rather drastic example, I admit, but does illustrate my point.
Arlin (remove '351' from email to reply)
Reply to
Arlin
Interesting. I would like to use something similar. Unfortunately, I think the people who define what SW is had in mind that the limit mates would be used in the mechanical simulation sense, rather than the design intent sense.
Reply to
Dale Dunn
I believe SolidWorks intended it to be a motion type mate as described in the help file. Note the word "move".
Limit mates allow components to move within a range of values for distance and angle mates. You specify a starting distance or angle as well as a maximum and minimum value.
Dave H
Reply to
Dave H
Yeah, they see it too (I sent them an assembly), I suppose they just see it the same as most of the other responses here. The behavior is probably what SWX intended but it doesn't make any sense for my application. Arlin's responses hit it dead on as to how this thing should function.
Eric
> I have an assembly with a limit mate as described, but no overconstrained > error. I did notice that the limit mate is a bit fussy about redundant > mates such as a coincident mate where a parallel will do. That's my memory > of it, anyhow. But I just checked the assembly, and it works fine. > > Perhaps the VAR doesn't seem to care because the error doesn't occur when > he tries to simulate the situation. Has the VAR tried the problem assembly?
Reply to
Eric Zuercher
It's frustrating when you report a bug, and your VAR says something like "It's performing as designed". At that point, it's not going to be submitted as a bug. Filing an enhancement request would be your next course of action.
Apart from that process, participating in the beta and pre-release programs is the only way for most users to make their opinions heard at SW corp. Without participating in discussions at SW World, that is.
Reply to
Dale Dunn

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.