Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Options
Smart number entry
traveler_hauptman
Member, OS Professional, Mentor, Developers Posts: 419 PRO
This is a continuation to @andrew_troup's comment on mate limits
I'll start with the caveat that I'm really happy for every new feature that comes rolling out and I don't mind if a feature is a first pass and rough around the edges.
One rough edge with the mate limits is that I the user have to do math that is trivial for Onshape to do.
One scenario is if I enter my mate limits to be from 10mm in the first field to -10mm in the second. It fails. It shouldn't. If the underlying math is insensitive to the direction, then it should handle both directions by doing the right thing (abs()). If it is sensitive to the direction (which I would want it to be for when equations arrive) then it should handle both directions inherently.
A second scenario is if I want an angle limit I have to first get it into the range of 0-360.... Again, this shouldn't be like this. There are two situations that are common for me that would break this. One, I'm entering angles off a notebook sketch. The problem I'm trying to solve will dictate what the 0 angle is and I'll be reading off angles relative to that, often negative.
Lots of my calculations are things with screws where angles I care about are outside -360->360 are common. Multi-turn potentiometers, jack screws, sector gears.
While it would be nice if the solver did track across multiple rotations (which malay said would be prohibitive) I can live without that. But the limit fields do need to be able to interpret angles outside of 360, both positive and negative.
Malay's suggestion that we use the bigger dimension to drive is a viable workaround... but that has me doing the math again which is not a long-term solution.
Presumable neither of the rough edges above will stay rough.
So... having a start to mate limits in the current build is great but I'm looking forward to their completion (as I am so many other of the first-pass of various capabilities that have been implemented).
I'll start with the caveat that I'm really happy for every new feature that comes rolling out and I don't mind if a feature is a first pass and rough around the edges.
One rough edge with the mate limits is that I the user have to do math that is trivial for Onshape to do.
One scenario is if I enter my mate limits to be from 10mm in the first field to -10mm in the second. It fails. It shouldn't. If the underlying math is insensitive to the direction, then it should handle both directions by doing the right thing (abs()). If it is sensitive to the direction (which I would want it to be for when equations arrive) then it should handle both directions inherently.
A second scenario is if I want an angle limit I have to first get it into the range of 0-360.... Again, this shouldn't be like this. There are two situations that are common for me that would break this. One, I'm entering angles off a notebook sketch. The problem I'm trying to solve will dictate what the 0 angle is and I'll be reading off angles relative to that, often negative.
Lots of my calculations are things with screws where angles I care about are outside -360->360 are common. Multi-turn potentiometers, jack screws, sector gears.
While it would be nice if the solver did track across multiple rotations (which malay said would be prohibitive) I can live without that. But the limit fields do need to be able to interpret angles outside of 360, both positive and negative.
Malay's suggestion that we use the bigger dimension to drive is a viable workaround... but that has me doing the math again which is not a long-term solution.
Presumable neither of the rough edges above will stay rough.
So... having a start to mate limits in the current build is great but I'm looking forward to their completion (as I am so many other of the first-pass of various capabilities that have been implemented).
Tagged:
1
Comments
I like the idea of using also mate connectors to limit movement it would give instant visual view of the movement area which would be helpful in some cases. Sometimes numeric entry is better. I would like to have both + their combinations.
The idea of using mate connectors came up in another thread by @peter_hall and @andrew_troup