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.
Pet hates
andrew_troup
Member, Mentor Posts: 1,584 ✭✭✭✭✭
Apart from the obvious ones Onshape explicitly sets out to address, what are some things which (we have learned from using other solid MCAD packages) don't work for us?
Tagged:
0
Comments
One of my recurrent peeves actually concerns a pair of related issues in existing packages:
1) : a myriad of different ways (the "arsenal" approach) to achieving the same objective, and
2) : the need for that arsenal, because in any given instance, several of those ways will not work as designed.
This combo gets fairly tiresome when modelling forms which are both complicated and exacting. (Which is when the need for alternative strategies typically comes into play).
It is relatively commonplace to dive into a particular area of a tricky model thinking "if this doesn't work, there are four or five other options", and hoping that it doesn't come to having to try them all in turn.
The arsenal approach, in my experience, makes it unnecessarily difficult to acquire and maintain mastery of the feature set for a given package.
When a particular workflow does not achieve the intended result, I would rather the entire development focus was directed to making it work, rather than being diluted across the provision of alternative tools and workflows, in the hope that one of them can always be found which will pinch-hit.
So far, Onshape seems promising on this front, consistently "doing more with less".
It will get progressively harder to hold that line, as the package matures.
I hate that you can not import parts to a part studio/ reference to parts outside of the doc or even part studio and interrelate parts to a construction sketch unless it is all done in the 1 part studio from the start. I know this is going to be hard to achieve without sacrificing a bit of stability but absolute required for me to use Onshape on larger projects.
Twitter: @onshapetricks & @babart1977
because it seems to me these bitter experiences can provide useful signposts to help Onshape avoid falling into known, existing pitfalls.
It'll be much more fun if they can find new ones!
Just spent time on Onshape now I am back on SW and so want to be back using Onshape again.
That said, SW is an awesome program and have enjoyed using it over many years.
Twitter: @onshapetricks & @babart1977
I agree with you.
The assemblies are non-functional to me because it's impossible to construct a layout of your design. I can hardly wait for this to be fixed.
I was thinking I could live with just importing a sketch into a part studio without any outside references. This minor change would be a big advancement for controlling a project.
I'd really like a way to change the default controls. Sorry, but right mouse button to rotate is extremely annoying to me. Almost every 3D graphics or CAD program I've used has a way to change your controls, but I can't seem to find a way to do this in Onshape. I'm used to the middle mouse button only being used for rotate...this is probably because most programs I've used come this way as the default. It doesn't have to be the default for Onshape, but please let me change it if I want. Pan and zoom can use the +shift and +ctrl keys with the MMB, but rotate is used much to often to require two buttons to accomplish. Put a context menu on the right mouse button.
Sorry if this is a feature that is already provided...I don't see it.
We use right mouse button for rotation.
We don't allow users to change their preferences yet.
We don't all have the time availability to start all over again.
Some of the features never worked as described from day one until (for all I know) the present day. "Pierce", for instance, never worked for axes (at least, not last I checked) but it was clearly intended to, according to the documentation, and finishing it off in this way would have led to simpler feature trees. Some users needed some way to provide a robust location for where an arbitrary line would pierce an arbitrary plane if extended sufficiently far, and an axis is the obvious (and conceptually purest) way to implement that.
Sick of doing 15-20min work then having a crash just when you go to save.