Is it the same sweep generated in the same version of SW? The problem may be with the underlying surface definition, not the Extend feature.
SW occasionally changes the algorithm used for sweeps and lofts. The results are dependent on the originating version of SW. (This was once documented in the API for lofts.) If the underlying definition is different, the resulting extension will also be different, especially if one is extrapolating beyond the full definition of the surface.
..made in each version, a 2012 Sweep/Extend and 2016 Sweep/Extend.
I also made this in 2015,.. also different,.. so, the algorithm changed in 2015... (~2014?)
...SAD......... that is, imho,.. UNEXCEPTABLE!
..THIS IS A BIG PROBLEM FOR US WHO USE SURFACE EXTEND!
Actually the biggest issue with this whole thing is that this error creates a bigger problem for the entire forum, anytime we got some major surface modeling issues in comes Paul Salvador to the rescue, now what'll we do when Paul got issues and we can't help, we need Kelef Man to help enlighten our minds till SolidWorks figures out Paul's problem, this has got to stoopppp..
Maybe use Untrim? It generally produces better results anyhow.
The core problem is that you are extrapolating beyond the underlying surface definition. Every surface has an underlying face definition that may or may not be bigger than what you see. (That's why I make my A-surfaces with oversize definitions). Extend and Untrim work well enough when you are still within the bounds of the definition. As with any system, extrapolation can yield widely varying results from apparently similar conditions.
Roland, yep, you are thinking like me at this moment,.. how can I do this now (because EXTEND IS BROKEN and it will NEVER GET FIXED!) after you've been using extend for your past workflow... UNTRIM is the alternate and the better option now.
btw,.. what is ALSO the problem here,.. both edges from the extend are no longer continuous,.. they are now broken..
..amazing.
Hi Paul,
Please contact your SOLIDWORKS reseller and have them submit a bug on your behalf for this issue so our QA and Dev groups can take a look at it. We've made a number of changes to Sweep over the last couple of years and this may be causing the issue.
Jody
It's your job, not mine,..... your company/contractor broke it, your people failed to catch this error.. and you are making the users, who pay your salary, post problem reports?????
Nice job security!
Hmmm... typical oblivious SW response.
I am sure Paul remembers the past occasions when he has found loft or sweep had been tinkered with between service packs to similar bad effect...
I suppose the obvious questions to ask yet again is "why was it changed when it seemed to work fine before?" and "why weren't the changes communicated to users?".
Of course I've been around long enough to know the answer and I am confident Paul knows it too - it's just what SW guys do over and over to the user's annoyance regardless of how sharp you try to keep them. Behold the enhancement/bug matrix in action. Maddening stuff.
Coming across this report reminds me how much stress and bother I avoid these days by not being on the upgrade march. Good to see those that are standing their ground though. Bah to mindless and needless corporate hoop jumping I say...
I'm not giving SW an excuse. I've been used and abused since the 98+ version.
It is frustrating when settings change to different defaults or turned on/off for no apparent reason. It's difficult to compare apples to apples in workflows/features when they change "minor" settings.
I'd be willing to bet that there are very few, if any, programmers still around who wrote the code when the features first came out. That being said, good luck not breaking some things while attempting to (we can only hope) get rid of the bloat in the software. I can't even imagine what the code looks like from 5-10 years ago compared to today.
> attempting to get rid of the bloat
LOL. Well that's an interesting interpretation. I guess they are actively making room for more fluff then?
Just joking, just joking, but I do empathise with Paul's complaint. I am sure as a long time user and forum circulator as are many you too recognise patterns in SW issues that you would rather did not exist. Personally I cant imagine why you would want to go mess with established code when there are other things that ought to have attention but...
Perhaps you are right however that we have a new generation of coders (post DS takeover) who could benefit from some fine tuning/guidance from the user community as their predecessors were subtly nurtured. Unfortunately maintaining the quality and focus of SW has pretty much always required users to be active participants otherwise we might not like what the program may come to look like in less time than we can imagine.
Later .
I just say "hopefully getting rid of some bloat" so that consumers don't have to upgrade computers/graphics cards as often. All too often things are released (not just software) with band-aids applied to fix problems. Not necessarily the most efficient fixes.... And over time that can grow the bloat exponentially.
This is the scary thing about where this software is going.
So many fixes and who knows what kludges adding to and bloating the software
Soon we will need some Star trek quantum warp/hyper technology just to do a simple sketch.
As for lofted bends and failure with 2 simple curves - well that may require tech well beyond that......... sigh!!!
Note the really helpful error message...
Hey Neil, yeah, this extend edge break is really what got me.. but, honestly thought the surface/extend deviation behaviour related.. anyhow, my error for assuming and not checking/verifying the start/end tangency setting,.. although, now.. (wth) the default start/end settings from none to tangent?
I skipped or refused to use a few versions because of past years of inconsistency and the MANY failures I've seen in old models with mixed versions of past loft/boundary/sweep/fill/... features.. very painful... I mean, it can be a revolving cycle of WTH?....my advise, just redoing the model.. it's NOT WORTH the headache. (which defeats the WHOLE REASON WE BOUGHT INTO THIS PROGRAM??)
How/why the extend algorithm changed.. I don't get it?... this is not for the better.. the cause/effect to the user is MORE WORK!
(btw,..testing last night,.. it may have changed back in 2014?... arrgghhh)
Hi Paul,
I believe this may actually be an unrelated issue in your example. If I'm not mistaken your 2012 Sweep has "Start and End Tangency" set to "None". Whereas the 2016 sweep as uploaded has "Start and End tangency" set to "Path Tangent" which for whatever reason is introducing a nasty ripple near the edges of the sweep.
See curvature comparison below (same scale curvature combs)
If you set the 2016 sweep to match "Start and End Tangency" to "None" like the 2012 sweep I find the results are identical. In the attached file I only changed the 2016 sweep feature to match the "None" start end tangency
Hope this helps,
Ryan and Craig,.. thanks for checking that,.. arrgghh, not what I wanted to focus on but,.. yes, you are both right, in that, I missed the start/end tangency difference.. for some reason my 2016 sweep default is/was set w/ tangency? (wrong) ..and, my 2012 is set at none? (correct, what it should be)
... the real issue though, for downstream errors is the new extend changes the edges to be non-tangent or broken.
Ooooopppps - that doesn't look so good !!!!!