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.
Best Of
Re: drawing - dimension not correct
.. and OS team should not wait a democracy-style vote to fix something that is wrong.
Re: drawing - dimension not correct
I’m not a pro but it is sad that dimensions on isometric views on OS are wrong. Isometric drawings are by far more compelling that any ortho view so any info associated to that kind geometric representation should not be misleading as it is on current OS drawings.
Re: Improvements to Onshape - August 29th, 2025
@Philip_Thomas_PTC I think that's a very sensible rollout strategy. I don't mean to imply that it should already be implemented, but wanted to add my thoughts now in case there's ongoing discussion for the future, which it sounds like there is! Thanks for the reply
Re: Improvements to Onshape - August 29th, 2025
I was imagining that we get a workflow much like creating a new regular variable while in sketcher (or other situations). You could create a QV while in another feature and the QV would be added to the feature tree right before the current feature. This would be an explicit QV. If you delete the feature that was used to create the QV, it would still exist, just like a regular variable.
Evan's second concept is more of a parallel with implicit mate connectors. I could see that being useful to keep the tree less cluttered, but much like implicit MCs, I often later want to be able to reuse them, and there's currently no way to do that. I'd almost prefer that those MCs got added before the feature the same way on-the-fly variables do. It would be more consistent and make them more useful. I suspect that part of the reason for that workflow was that at the time, MCs needed an owner. Now that they don't, I don't see why they shouldn't be created above the feature for potential reuse.
S1mon
Re: Creating Sheet Metal Object via Feature Script
Sheet metal is pretty difficult to work with in FeatureScript. My recommendation is to not use the underlying sheet metal functionality, but rather to just call the existing sheet metal features with your featurescript. Calling the Onshape written features as sub features is going to produce more consistent results, won't break as easily, and will be faster/easier to develop with.
Re: Improvements to Onshape - August 29th, 2025
@EvanReese - we very nearly did allow the creation of QVs ‘on the fly’. The main reason we didn’t for this release was that a user would not be able to locate where in the tree the QV was defined (if they had reused the QV and later needed to edit its definition) or worse still suppressed or deleted the feature containing the definition. One idea discussed was limiting the scope of use to only the containing feature (a ‘local’ QV if you like). We still might do this but wanted to see how QVs were received first (pretty well by all accounts :))!
Re: PLEASE explain "externally disambiguated" / "transient" / "robust" / "tracked" / "unstable" ID's etc
This Onshape Live presentation had ( a very simplified ) explanation of how queries work inside Onshape. For each topology created by an operation there is a record of its dependencies allowing us to identify this topology. When downstream references this topology, query (an encoding) of this record is generated. Query evaluation is a patten matching of the query with current state of history. One of the first matches is operation id. If we introduce an unstable component into ids of some operations, it means that results of those operations will all be considered when evaluating a query generated for one of them. E.g. If we have a set of operation ids fId0,op0, fId1.*id0.op, fid1.*id1.op, fid1.*id2.op .. , when evaluating a query for topology created by e.g. fid1.*id1.op , we'll consider all fid1.*.op operations. This way reference is stable to order and number of input selections. If the dependencies are not enough to disambiguate results of these operations, external disambiguation is used. At the time of query evaluation external reference replaces the unstable component. I hope this gives you a mental model for the future. This is not going to give you a complete clarity without knowing the way each operation handles its history records. I don't think we are going to expose those details any time soon.
All of that is supposed to work in theory, but sequence of opSplit where results of previous step are passed into the next does not. I can't say that there is a theoretical reason why it could not, but so far we've fallen short of getting there. I'll add your example to an issue we have for addressing this scenario.
In meantime If instead of split you could use opThicken to create the skins and opBoolean subtraction to reduce the original body, this should give you a more stable behavior. Sorry about the hassle.
lana
Re: Rotating letters in circular path
Use @jnewth 's Text feature.
https://cad.onshape.com/documents/4e187c2b2f7f4974f4e2b612/v/4446c75baffebee73f367acc/e/e8c85370413ae1136b63f9df
S1mon
Re: Improvements to Onshape - August 29th, 2025
Excellent updates! The include properties checkbox is something we have been wanting to help keep our library clean. Is there a way to change the default to leave that box unchecked? That is typically what we want in our workflows.
Re: Trouble Creating an Angled Face
Pretty sure a simple draft will get you what you need in this situation.
MDesign