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.
Laser Joint Updated to V3.0: Pin Face Offset and Pin Chamfer!
lemon1324
Member, Developers Posts: 225 EDU
Direct link to the new version here.
Pin end faces can be offset either in or out; convex pin edges can be chamfered to aid insertion.
End face offset as requested by @Hugh_Goodbody, @michael3424, and @brucebartlett.
Notes:
Performance on joints with no options is the same; pin face identification is currently the most inefficient computation, so offsetting pins on very large automatic joint operations may take some time. Everything is fast enough to easily use for manually tweaking single joints when not in automatic mode: a single joint with all options enabled executes in under 0.5 seconds. Recommended use for automatic mode is to set up the laser joint feature at the end of the feature tree, roll back to previous, and then make adjustments there until ready to recompute all joints.
When finding pin terminal faces, for now I'm only selecting faces which lie entirely on/in the intersection volume prior to the pins being created. This means if the "tab" part overhangs the "base" part, the outer two "pin" faces will not be offset, only fully internal ones. Current recommendation for now is to manually offset these if it's critical.
I also found that in cases where more than two parts initially occupy a joint at non-square angles (e.g. at the corners of a hexagonal prism), small disconnected components can be created, which sometimes caused some joints not to be generated correctly. In addition to fixing the query in these cases, I've also added code which automatically deletes these disconnected components if they occupy less than 0.1% of the parent body volume, and displays an info message to the user. Disconnected components larger than this will be identified, not deleted, and a warning to check for intended function will be displayed, while the joint completes as computed.
As always, no bugs found on my test cases, but if you find any, send me a link to a public document with a minimum example demonstrating the problem and I'll look into it as I get time. PhD responsibilities come first, so I recommend if you get any bugs breaking functionality to revert to a previous Laser Joint version until I can get a fix out.
Arul Suresh
PhD, Mechanical Engineering, Stanford University
PhD, Mechanical Engineering, Stanford University
4
Comments
Twitter: @onshapetricks & @babart1977
Thanks
Arul, would it be easy enough to allow sheet metal bodies to be picked as well as solid bodies?
I haven't looked in detail at how sheet metal bodies are queried in the code; my understanding is that operations on active sheet metal parts actually modify the flat pattern directly. With this and the very likely case that each part is no longer planar (which is the core assumption of the code currently), I think it would take a near complete rewrite or a new feature from scratch to get that working.
Would you want such a feature to only join sheet metal parts to other sheet metal parts, to deal with a mix of sheet metal and non-sheet metal parts, or to do laser cuts on the bend lines, like this?
PhD, Mechanical Engineering, Stanford University
Sheet metal features act on a folded-up sheet body representation of the sheet metal, which is then built out into 3d and flattened into the flat pattern by "updateSheetMetalGeometry(...)"
You don't really have to worry about this, though if you were to want to adapt your feature. On a high level, any feature that you can use to edit sheet metal in the graphics area can also be used to edit sheet metal in a custom feature. In other words, if you use the "extrude(...)" function rather than the "opExtrude(...)" function, you can cut sheet metal without ever thinking about how sheet metal works internally.
A word of warning: features that affect sheet metal can cause performance hits. If you are cutting five tabs along a planar sheet metal part, it will be much faster to call extrude() once than five times. That being said, your best bet to adapt the feature with good performance would probably be to create a bunch of tools and then just call "booleanBodies(...)" (this is the FS name for the "Boolean" feature) once to subtract the tools from the targets.
I am designing laser cut steel parts to be welded together, up to a couple of meters in length. The problem is that the desired tab length (30-40 mm) gives to many tabs and would result in more cutting time on the laser and more welds.
Is there any way to get a fixed tab length and fixed number of tabs equally spaced? Result from Laser Joint V3.1 at the top in the screenshot and the desired result at the bottom.
For example; eight 40 mm long tabs equally spaced, with 30 mm edge offset.
Or; X number of 40 mm long tabs with 150 mm spacing
Fillets on the corner overcut edges would also be a great feature.
How important are fillets on the corner overcut edges? (And what are they used for? Smoothing the toolpath for faster cuts? Legitimately curious since I didn't think of that as a thing that would be useful). It would be pretty easy to add that functionality, but adds yet another option in what's getting to be a moderately unwieldy UI at this point. The nonequal pin/spacing option seems obviously useful enough that it's definitely worth the extra input selections.
PhD, Mechanical Engineering, Stanford University
I do not think the UI have to change that much. Maybe adding a Fixed pin sizing checkbox with a show on click Pin width input. And using the existing number of pins input. Something like this maybe:
The fillet is not that important, just a nice to have feature. You are correct, it is for smoothing out the path, every time there is a sharp corner the laser have to decelerate more which takes longer time (and therefor higher cost). Depending on the laser, or when using cnc plasma there is also a risk to to overburn (causing lots of dross) or burn away sharp edges.
PhD, Mechanical Engineering, Stanford University
Twitter: @onshapetricks & @babart1977
Pin chamfer could be a fillet instead to fix the same problem with with sharp edges. Added it in my copy, but maybe it should be switched to be able to pick only chamfer or fillet? Use it if you like it!
Another thing I realized when testing it out was that i was able to join to crossing parts, which is a good thing. The problem is that it resulted in two parts that could not be joined in reality without cutting apart one of the parts. Something like this is a nice way to do it.
As far as the crossing parts, those are intentionally left out of scope - there's the Lap Joint feature @NeilCooke wrote that handles that case, although without doing the corner overcuts. I haven't come up with a robust, computationally inexpensive way of automatically detecting that situation.
@brucebartlett Fillets seem to be pretty fast, and cylindrical corner overcuts means I can use primitives and a boolean (fCylinder/opBoolean), so for regeneration times I'm pretty sure that's the most efficient rather than trying to sketch and solve some optimal curve. More curvature from more radius on the overcut/fillet is probably the best as an overall compromise. If your machine time is that valuable, CAD each overcut by hand!
PhD, Mechanical Engineering, Stanford University
Can this be used on frames (angle and box section)?
@aaron_harris672 It'll probably do something, but even if it does, I suspect it won't work entirely as you think, the core assumption right now is that parts are planar and intersect along a line. Working with tube sections I think would require a large enough refactor that it might end up being a different feature altogether.
PhD, Mechanical Engineering, Stanford University