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.
Frame Cut Lists K-Factor is 1?
Derek_Van_Allen_BD
Member Posts: 123 PRO
I have been looking at cut list properties a little closer lately and noticed that the cut list tool assumes that the outside dimensions of any rolled segments are representative of the final straightened segments of frame length. Recently we had some rolled round tube come out of the shop oversized and the fabrication team had to rework the parts, and only after I've been digging into the featurescript implementation of cut lists did it occur to me that the dimensions given by the table might have been the cause for the out of spec parts. Wouldn't it be more appropriate to use the mid-line of the frame for rolled segments for a closer approximation of how frames deform when put through a rolling operation? Ideally the ability to specify a k factor for particular bends would be best but .5 is surely a better stab than 1.
Comments
Hey @Derek_Van_Allen_BD sorry meant to reply before this.
I posted something about the way cut list lengths are calculated a while back but it might take some digging to find the original post.
In your particular case (if I read it right that is: "planar circular bends of profiles that don't produce edges") I think that hits the codepath in cutlistMath of getLengthAndAnglesWithoutEdges(165) → getCircularArcBeamDimensions (228) → getMaxRadiusEdge.
You could experiment there (with a modified cutlistmath) to tune the approximation more to your liking. Even so, for profiles that don't produce edges (circular profiles), we end up creating isoparam curves (174) so an average "edge" might not be the exact centerline either.
Some background:
Cutlist lengths are not exact. I think they are at best, exact, and at worst, strict overestimates. As I (now dimly) recall there were several considerations that informed our strategy:
1. The neutral axis analysis for tube bending worked remarkably well in my textbooks and never at all in my experience. In my experience it's always an underestimate, and…
2. Underestimates are a pain in fabrication (it's hard to make a steel tube longer, easier to grind it shorter).
3. But the biggest factor is not obvious: Frames current implementation doesnt have the swepth path centerline information at length calculation time (and sometimes doesnt exist) so it's not used. If I were to rewrite frames today, I would certainly try to write this information (the defining edge / points / curve whatever) as an attribute for retrieval at custlist length calculation time so it could be used downstream but…
4. At the time I couldn't come up with such a strategy that worked in all cases (including oddball trimming cases). The solution I eventually got to was a reasonably robust and performant set of heuristics (cutlistMath.fs). But you can put it on my tombstone: "Geometric heuristics are guaranteed to be wrong some of the time".
Hopefully that sheds some light on why it works that way. It was intended to solve most problems adequately/workably for fabrication, rather than any but the simplest problems perfectly. But I know you can write your own cutlist calcs in for your application. Let me know what you come up with! Would love to hear about it.
Hey @jnewth, nice to run into you again.
I had assumed that some kind of compromises were made during development of that general sort. Unfortunately for me my team is impressively skilled at finding oddball cases in any application and bringing them to me looking for solutions to them. (Got some real weird trims to deal with right now in fact because of tab and slot frames)
Technically this k factor thing isn't an issue if you're looking to get an over-estimate for stock purchasing but like most things I do that isn't the end goal. My end goal is essentially simultaneous sheet metal but with frames.
For starters I was intending to do an Auto Layout inspired script that would do frame cut list layouts by straightening the bends and laying parts end to end for visualization of how many lengths of tube need ordered for a project. I can do that now with cutlistMath as is. After this script is done though I intend to create another script that switches between folded and unfolded states of tube stock for lasering and then forming them into shape post-lasering to get those fancy notched self-fixturing tube bends that all of those tiktok reels are doing with an angle grinder. K factor is gonna matter a lot here.
I do have a couple of ideas on heuristics I could use for better estimates of that medial axis of the tube with varying levels of detachment from reality and/or sanity but the simplest one that will likely be used is finding the largest radius swept edge as well as the smallest radius swept edge and applying a curve tween between the two at whatever k factor is feeling spicy to me that day. Still patching in all of the overload cases for the tween script for the line types but that should be ready pretty soon to plug into this and keep me moving on the rest of my non-sheet metal folding and unfolding explorations.
Simultaneous sheet metal but for frames sounds very juicy! I think there are a fair number of "power Frames users" around the forums that would be interested in reading about whatever you cook up. Keep us posted!