26 Replies Latest reply on Jan 29, 2019 10:50 AM by Dan Golthing

    ZTG

    Brian Brazeau

      Ok. So if you open assembly and show "this works" configuration you'll see SW handling ZTG geometry because when Part2 is extruded (feature "this works") there is ZTG created when it passes by Part1. Therefore the cavity function should have failed, but it didn't. Yeah!

      Now change to "This doesn't" and you'll see I added a contoured parting line and a radius to Part1. In Part2 you'll see I suppressed the original boss and cavity features because they don't work anymore. I added "This doesn't" and "Cavity2" features. You'll notice in Sketch4 of "this doesn't that there are 2 splines. 1 is a converted edge and 1 is an offset of that converted edge. The converted edge is the silhouette "Split Line1" of the Part1.

      So the only reason "this doesn't" configuration is working is because of the offset edge. Play with the value of offset and you'll see there's a point at which it stops working.

        • Re: ZTG
          Brian Brazeau

          Or switch the value of the 2 edges in Sketch4 from construction to regular geometry and watch the cavity2 function fail

          • Re: ZTG
            John Stoltzfus

            We already have this one ZERO THICKNESS GEOMETRY!!   AGAIN!!  plus others ???

            • Re: ZTG
              Jim Wilkinson

              1-6EC8R73 wrote:

               

              Ok. So if you open assembly and show "this works" configuration you'll see SW handling ZTG geometry because when Part2 is extruded (feature "this works") there is ZTG created when it passes by Part1. Therefore the cavity function should have failed, but it didn't. Yeah!

              Now change to "This doesn't" and you'll see I added a contoured parting line and a radius to Part1. In Part2 you'll see I suppressed the original boss and cavity features because they don't work anymore. I added "This doesn't" and "Cavity2" features. You'll notice in Sketch4 of "this doesn't that there are 2 splines. 1 is a converted edge and 1 is an offset of that converted edge. The converted edge is the silhouette "Split Line1" of the Part1.

              So the only reason "this doesn't" configuration is working is because of the offset edge. Play with the value of offset and you'll see there's a point at which it stops working.

              Hi Brian,

               

              I don't believe this is a ZTG issue but rather an issue of resolution between spline edges and a sketch spline created from that spline edge.

              You say that for the "this works" configuration, it is ZTG and the cavity should have failed. That is not true. The cavity feature is splitting the body in half exactly at an edge and the command offers to let you keep both bodies or just one. You decided to keep just one, so there is no ZTG issue. Even if you had kept both bodies, they would be separate bodies meeting at an edge, so still no ZTG issue. Now, if you tried to use the combine feature to join those two bodies together, it would fail because it is in fact ZTG trying to have those bodies connected together into one body at a single edge.

               

              For your case that doesn't work, I have redone the modeling slightly, but still using your converted edge type approach to highlight what is happening. I overbuilt the cylinder so the cavity is created fully enclosed within the cylinder. Then I used the converted spline edge to cut back the larger cylinder to the original size you were trying to create. I then still added on the larger cylinder extruded up to the ruled surface. So I was able to create what you wanted, just with slightly different features that didn't fail. But, if you run your mouse over the edge of Part2 that is created by the split line, you will see that it is not clean, but rather split into 7 edges. This is a clear sign that there is a slight variation in the shapes of these spline edges/surfaces and this is likely caused by the conversion from the split line edge to the sketch spline and then back to an extruded spline surface.

               

              If you open Part2 and switch to the "Cut with Surface" configuration, you will see that I built it in a much simpler approach, with less features and avoiding the coincidences between these spline edges/surfaces and have not used a converted sketch spline at all. I again have the overbuilt cylinder and the fully enclosed cavity and I create the same exact type of ruled surface that you created but then I simply use that ruled surface to cut the cavity body. This avoids the whole conversion from the spline edge to sketch spline and back to a solid surface/edge because the ruled surface is created directly from the edge without any intermediate geometry. Now if you move your mouse over the edge created from the split line, it is one clean edge. This is the approach that is documented in almost all tutorials and documentation about cavities/molds/splits that I have seen and will produce cleaner geometry and have more chance of success.

               

              So again, this is not a ZTG issue, but a resolution issue between spline edges and sketch splines. It would be great if SOLIDWORKS could eventually improve the modeler so that it could better handle these types of issues even when going through sketch conversion approaches. For that, I would suggest submitting this to your reseller so they can submit it to technical support for an SPR because I would think they would consider it a bug and having the example would be good for future improvement. But until it is improved, it is always best to try to use the cleanest, most direct approach possible without sketch conversions, etc.

               

              Let me know if you have any questions,

              Jim

                • Re: ZTG
                  Brian Brazeau

                  Hi Matt, Thank you for the explanation and example. The methodology you used is an excellent way to solve this particular instance, but I would still consider it a work around. (as it happens in this case it's a work around the inaccuracy of the conversion of entities causing a "geometric condition" issue.) However, this example I posted is as I stated a simplified example meant for discussion purposes. The methodology you used becomes more cumbersome when the candidate parting line is more complex (undulating) as often the ruled surface creates rippled surfaces or fails when extended too far. Surfaces converge quickly if they represent too tight a female bend which results in parting surfaces that would be difficult to machine, so creating the surface to cut with as you did in your "Cut with Surface" configuration becomes piece meal and increasingly more difficult. I will concede that this example is not the conventional example of ZTG as the enhancement addresses, but what does the "geometric condition" represent in this case if not SW's struggle to handle ZTG. Just calling it "geometric condition" does not preclude it from actually being an issue with ZTG. To test your hypothesis that the problem lies with error introduced by the conversion of the split line to planer geometry, I tried using a ruled surface with the sweep option and a vector direction of the Top plane, then moved the surface so it completely encompassed the part top to bottom then tried the same cut with surface command and got the "geometric condition" error. Possibly in this case it failed because it could not determine which solid body to keep and maybe the cut with surface function does not support multi bodies. however the edge is still a continuous single entity edge as you can see from the pic below where I highlighted it and so I would assume no more inaccurate than the method you used. If SW were able to handle ZTG all that would ever be needed to create a core mold component would be a viable split line and closure of any open holes in the plastic part representation.

                    • Re: ZTG
                      Jim Wilkinson

                      Hi Brian,

                       

                      I played around with the approach you tried with the ruled surface with sweep and found the same failures. So then I started trying to figure out why that one would fail and not the one where the surface radiates straight outward. So I may have been incorrect in my original reply that this problem is due to differences in the 3d spline converted to 2d but rather due to another geometric condition (but still not ZTG). All around the geometry there is a very thin "knife-edge" that it is trying to create labeled in the two red areas.

                       

                      SuperThin.png

                       

                      What I first did was eliminate the curved bottom of your part but still had the fillet on there, and it worked fine even creating this "knife-edge" geometry with the ruled surface with sweep option. So then in the new part that I have attached to the thread, I went back to having the curved bottom of the part and I created a boundary surface instead of a ruled surface to use as the cutting surface. It creates a surface between the parting line and a circle and you can control the vertical location of the circle by changing the Plane1 direction and the diameter of the circle in Sketch7. That way, I could fully play with making a parting surface that ranged from the ruled surface radiated shape to the ruled surface swept shape. The image below shows the part with the circle at the base and the diameter at 1.5 and you can see that the parting edge is still a clean, singular edge.

                      SuperThin1.5.png

                      In the below image, the diameter is 1.45 and now that parting edge is all split up:

                      SuperThin1.45.png

                      And it works all the way down to 1.25, which is almost vertical, similar to the radiate surface with sweep option. But it still breaks the edge up into many segments.

                      SuperThin1.25.png

                      Below 1.25 it fails due to geometric conditions. So, this definitely has something to do with this very thin region and the curved/spline shape of the edges. And it very well could come down to tolerance/approximation issues between the different representations of the spline edge shapes, but it really needs to be looked at by the developers to know for sure. Or it actually may be a mathematical impossibility; there may be something I'm missing on visual inspection where the geometry is not physically possible to make. But I'm almost 100% certain it is not ZTG.

                       

                      By the way, Instant3D was pretty useful in doing troubleshooting because I could more easily drag the little dimension handles to quickly change the dimension multiple times to see where it worked and where it failed.


                      ZTG is a very specific set of configurations of geometry. For instance, more than 2 faces trying to be joined at a single edge, or multiple pieces of solid geometry connecting together at a single vertex. This help topic shows some of the types of conditions: 2018 SOLIDWORKS Help - Error Message - Zero Thickness Geometry

                      The geometry you are trying to create is not any type of zero thickness condition.

                       

                      There are probably hundreds of other types of geometric conditions that have nothing to do with ZTG but fail due to other geometric conditions. For instance, trying to put a fillet of such a large size it can't physically fit in the geometry. Or trying to shell with a size that offsets faces into one another. Although the shell can faces offsetting into one another or absorbing some faces, if your shell size is so large no faces could possibly be created (like shell size of 1/2 the width of a cube) it will fail due to geometric conditions. Or trying to offset a curved face with an offset larger than the minimum radius of curvature of the face so it self intersects. Or trying to make a sweep with a profile that is wider than the minimum radius of curvature of the path so it self intersects. Or, like in your example, geometric condition failures due to extremely thing geometry or geometry approximations/tolerances.

                       

                      To me, it is very important not to hitch ones wagon to the ZTG bandwagon for all cases of geometric failure. And here is why:

                      1. If SOLIDWORKS did implement ZTG, my guess is this case that you are showing (and other similar examples) would not be solved and you will be very disappointed if ZTG support came out and it didn't solve this. Again, I am almost 100% certain that implementing ZTG would not solve this.
                      2. If it is solvable at all and not a mathematical impossibility, the problem you are encountering may be MUCH easier to solve in the software than implementing ZTG. Many times over the years while I was working at SOLIDWORKS, the product definition and development teams would strategically go after projects trying to reduce geometric failures. When doing this, it is important for them to have as many examples as possible. That way, they can evaluate all the different cases they have and bucket the issues into like groups; some will truly be ZTG, some will be edge tolerance issues, some will be thin regions, some will be modeler limitations (like cases of collapsing/disappearing faces that the shell command can't yet handle), etc. Then when they see a number of things in a specific bucket, they can add a project to strategically tackle those failures. Sometimes the solution isn't actually to tweak the modeling kernel, but change how references are done so there are more direct/robust connections between geometry. For instance, some of the mold tools were specifically implemented to work directly off of edges instead of working off of sketches to help with some of these types of issues.

                       

                      So I would still recommend submitting this problem through your reseller so it can be fully evaluated and logged as an SPR if it truly is a problem and not mathematically impossible.

                       

                      Thanks,

                      Jim

                        • Re: ZTG
                          Brian Brazeau

                          Hi Jim, Thank you for taking an interest in this issue, the time you've put in, and knowledge you've shared. I appreciate it. I did a little investigating on your part as well. The boundary surface method does indeed work to create the core down to the dimension of 1.25 however if you look at the edge it produces it does not seem to be a clean edge. This may be because the part has a diameter of 1.2565 so at that point you had gone under the diameter of the part. It also gave a condition of a very rippled edge see pic below. This condition persists beyond 1.26 which would not work well in real life so the method of boundary surface is not viable. Interestingly the point at which the perimeter transitions from split entities to one is about 1.4965 (so not useful in this and other cases I'm referring to. Need it to work at vertical) and very interesting is that it seems to fail with a value of 1.499 (1.498 and 1.5 work???) Maybe someone could test this and verify.

                          But back to the original problem at hand ("Cavity" function), Allowing ZTG may not solve this issue, but it may or it may allow developers to better handle this situation where this "geometry condition", which seems to be a broader blanket that many issues are clumped under, prevents a feature from working. (in this case it's the "cavity" command.) My question from this round of the investigation would be... The curve that represents the split line "silhouette" of the part seems to be continuous, clean, and represents the point at which the split should take place, although it terminates on the part at a point which represents Jim Wilkinson said "a very thin "knife-edge" " which is another way of saying ZTG. Why can't the "cavity" command create a viable core with it? I think that allowing ZTG may in fact help solve a lot of issues that have never traditionally been associated with ZTG. Again Jim thank you for your efforts.

                            • Re: ZTG
                              Jim Wilkinson

                              Hi Brian,


                              Yes, I do realize it is rippled like you show. I saw it myself, but I just didn't go into that level of detail in my description when I showed the images of it being clean at 1.5 and split up at various sizes below 1.5. My point is that something is falling apart in the modeler in trying to create this geometry and IT IS NOT ZTG. It is successful in creating it but it is creating very bad geometry below 1.5 and that is what is wrong; likely something to do with the spline edge/surface formulations of the various surface creation methods. It works when this knife edge is created with a flat bottomed part (and therefore all faces and edges involved are analytical, not spline) but it doesn't work when splines are involved. I don't agree with your assumption that fixing ZTG may solve this problem, nor do I agree that supporting ZTG may allow developers to better handle this situation of geometric condition, because it has nothing to do with ZTG. Those are absolutely false hopes.

                               

                              The main point of my explorations and posting back to this thread is to convince you and other users that are reading this that this, and many other geometric failures are not ZTG. I don't want users pinning their hopes on ZTG being implemented as being the "be all and end all" for geometric failures. IT WILL NOT!!!!

                               

                              Again, ZTG as it is defined, and what would be fixed if ZTG support was implemented, are those types of cases shown in this help topic:

                              2018 SOLIDWORKS Help - Error Message - Zero Thickness Geometry http://help.solidworks.com/2018/english/solidworks/sldworks/hide_non_manifold.htm

                              They are really "non-manifold" issues, but most people don't understand that terminology, so SOLIDWORKS uses the term zero-thickness instead. It has nothing to do with thin walled things or knife edges that dwindle down to a thin section that ends at an edge. While this may be confusing terminology because your part is getting thinner and thinner in that region (i,e, that edge a the end is zero thickness), that edge is not merging with any other faces, so it is not zero-thickness in the definition of what ZTG is in solid modeling algorithms (which again, is non-manifold geometry). If you want to think about what a ZTG issue would be with geometry similar to what you are trying to create, it would be like two of those knife-edges coming together in a single edge like shown in the cross-section image below:

                              SuperThinZTG.png

                               

                              In that image, 4 faces come together at a single edge. This is non-manifold...it can only be 2 edges coming together at a single edge to be manifold. So if ZTG were implemented, you could actually create the above geometry if you had two bodies making the cavities and the bottoms of each body were flat and filleted since those analytical cases are successful in making the knife edge. So ZTG would just allow joining two of those successful knife edges together.

                               

                              The problem you are encountering is that the knife edge for the spline shaped geometry cannot even be created at all, so in the above image, it would never even get to the point of solving for ZTG because it would fail to create either the upper knife edge geometry nor the lower knife edge geometry in the first place; both of them would fail with the same geometric failures that are occurring now.

                               

                              So if you and other users take anything away from this, it is EXTREMELY important to not bundle together geometry failures thinking they are the same thing and specifically, don't assume everything is ZTG. It is important to look at each failure and try to understand why it is failing and if you can't figure it out, get your VAR/technical support involved. Each one needs to be evaluated as to whether it is a limitation (like ZTG, or trying to offset a surface with a thickness greater than the minimum radius of curvature, or trying to shell more than half the thickness of a part) or if is some sort of bug or something (like I believe you are encountering here). Limitations do not get recorded as SPRs and therefore no geometry ever gets sent to the SOLIDWORKS development staff to evaluate.

                               

                              So again, in this case, and if you have any other similar cases, you should submit them to your reseller for evaluation and for an SPR to be logged with SOLIDWORKS development. Otherwise, there is no record of it and nothing for the development staff to act on. The more users that report these types of problems, the more likely such geometric failures are to be fixed since they will have a bundle of like problems to look at and perhaps see a trend which is showing either what is currently implemented incorrectly, or implement new code that handles the cases.  In this case, I would recommend referencing this thread when you report it so they can see the troubleshooting that has already been done.

                               

                              Thanks,

                              Jim

                                • Re: ZTG
                                  Brian Brazeau

                                  Thank You Jim, I guess we'll just have to agree to disagree. I think next time the TTL comes around I'll just enter a request to make the "Cavity" function work with a silhouette edge and then we can start this whole conversation over again. I will not be submitting an SPR, but disagree with your assessment that there will be nothing for the development staff to work on. It is all right here complete with files and my contact information. In fact if I had anything to say about it I would direct development staff to use this "TTL" and all past ones year round for subjects and info on what to work on. I have submitted SPR's in the past and don't think that it works well. Incidentally, I got the split to work with a clean edge at a straight diameter by constructing the entire solid to do the "Cavity" feature from from surfaces and knitting them together. I have attached here if you or SOLIDWORKS STAFF would like to look at it. If I can do it with surfaces it should be do-able with solids. As for pinning our hopes on ZTG I believe that "Non-manifold geometry" would open up far more solutions than it would create problems and I won't be convinced otherwise. Sorry.

                                   

                                    • Re: ZTG
                                      Jim Wilkinson

                                      Brian Brazeau wrote:

                                       

                                      Thank You Jim, I guess we'll just have to agree to disagree. I think next time the TTL comes around I'll just enter a request to make the "Cavity" function work with a silhouette edge and then we can start this whole conversation over again. I will not be submitting an SPR, but disagree with your assessment that there will be nothing for the development staff to work on. It is all right here complete with files and my contact information. In fact if I had anything to say about it I would direct development staff to use this "TTL" and all past ones year round for subjects and info on what to work on. I have submitted SPR's in the past and don't think that it works well. Incidentally, I got the split to work with a clean edge at a straight diameter by constructing the entire solid to do the "Cavity" feature from from surfaces and knitting them together. I have attached here if you or SOLIDWORKS STAFF would like to look at it. If I can do it with surfaces it should be do-able with solids. As for pinning our hopes on ZTG I believe that "Non-manifold geometry" would open up far more solutions than it would create problems and I won't be convinced otherwise. Sorry.

                                       

                                      Hi Brian,

                                       

                                      You can disagree with me all you want, but I worked at SOLIDWORKS for almost 23 years (before retiring 3 months ago) and know quite a bit about the modeler and SOLIDWORKS internal processes on development, so you can trust my advice. I have no motivations coming to this forum now other than to:

                                      1. Help users with solving problems they are encountering.
                                      2. Have fun trying to understand and solve problems users are facing with the software; especially geometry problems because they are good "brainteasers". This was one of my favorite part of running the technical support department for my first 4 years at SOLIDWORKS when it was actually part of my job and I didn't have as much time to do it in my other roles at the company, so I'm happy to have some time to do it now.

                                       

                                      ZTG: Maybe you have misinterpreted my stance on ZTG, so let me start with that:

                                      Personally, I think the best user experience for users would be to allow ZTG, but have an option to choose the behavior, so for those users that don't want it, simply turn the option on to not allow it. That would provide the best of both worlds; users that want ZTG could use it, and those that see the benefit could allow it. Win/win right?

                                       

                                      But the reality is, actually allowing ZTG in SOLIDWORKS is an extremely difficult problem to solve and may NEVER be solved. Your statement of "I believe that "Non-manifold geometry" would open up far more solutions than it would create problems" is purely a statement from a user perspective. And while I somewhat agree with that from a user perspective, having an option to allow it or not completely mitigates the potential problem of whether a user thinks it is good or not; they can choose for themselves.

                                       

                                      But from the modeler standpoint, the statement of "Non-manifold geometry" would open up far more solutions than it would create problems" is very likely untrue. My understanding from all articles that I have read and people I have talked to is that whether a modeling kernel is manifold or non-manifold is fundamental to the underlying mathematics. It may be that it is not even possible to make ZTG optional/switchable in a modeling kernel; it either allows it or it doesn't. And there are very likely things that manifold modeling kernels can do that non-manifold modelers cannot. So let's say Parasolid could go back and change the underlying mathematics to be non-manifold instead of manifold (which may be an extremely difficult, if not impossible task in the first place), it may be that now that the modeler uses non-manifold calculations, some of the old calculations that used to work when it was a manifold kernel no longer work. So when your regenerate an old model that worked with the manifold kernel, some features may fail now that it is a non-manifold modeler.

                                       

                                      So again, my stance on ZTG is yes, it would be great to have as an option for users, but from a modeler standpoint is extremely difficult if not impossible to implement and may introduce more modeler problems than it solves.

                                       

                                      SOLIDWORKS development/support processes:

                                      You say:

                                      "In fact if I had anything to say about it I would direct development staff to use this "TTL" and all past ones year round for subjects and info on what to work on."

                                      This is probably the crux of our disagreement. You can say you'd like their processes to be a certain way, but they need processes that work for supporting over a million users. So you can continue to fight against their processes and be disappointed when your problems continue to exist in the software, or you can embrace the processes and you may find that your problems are solved much more quickly. To support that many users, they need to work from structured databases and statistics. That is exactly what the SPR system is; it is a way to track both software problems and enhancements in a database where they can track how many users are having the same issue and  group like problems/enhancements together to find issues/projects to work on that will give the most users the most amount of benefit. In addition, it allows resellers and users to be notified when problems are fixed. The product definition and development teams are constantly analyzing the SPR system for issues to solve in the software. It is the primary driver for improvement, especially to these reliability problems. Yes, they also look at the TTLs for past years, but in its current form, it is just too unstructured to be used as the primary source for data; it is used as a secondary source to find things to work on and get additional information and user contacts for projects that have been identified through the SPR system. Forum threads are also used as a secondary source, but they are even MORE unstructured and difficult to find information from.

                                       

                                      As has been mentioned elsewhere, they are looking to replace the TTL and enhancement system with a new system that has all of the benefits of the SPR system that I mention and more, but I can't say when that will be available. And your problem is considered more of a bug than an enhancement so would have more exposure from a development standpoint in the SPR system even when the new enhancement system comes out. Bugs will continue to go through the SPR system even when the new enhancement system comes out because bugs are fundamentally different.

                                       

                                      So, my suggestion to you and others is:

                                      • For bugs like this, be sure to submit it as an SPR through your reseller so you get an SPR#. Then the development staff has your data and description of the problem and it is categorized under the cavity functionality in the database. For these split line/cavity type problems, I would submit a different SPR for each case you run into (since it sounds like this is a common thing you encounter). What this will do is increase the number of SPRs in the cavity functionality and therefore, statistically, cavity will bubble up higher as an area that needs to be looked at.
                                      • It is unclear if this is a problem only you are encountering because of the modeling workflow you are using or if other users are encountering it. For that, I would suggest that once you have an SPR, post to the appropriate part of the forum ("Plastics & Mold Design" in this case), and describe the workflow/examples/SPRs and ask that if other users are facing the same problem, have them submit their data to their reseller referencing the same SPR. That way, technical support will either create a new SPR for the other users problem if they find it to be different enough or they will add it to the same SPR with the additional user data on the SPR. In either case, the cavity SPRs will bubble up higher because they look for both quantity of SPRs in an area and number of customer "hits" on those SPRs.

                                       

                                      Doing these things will take less time than the amount of time you've spent going back and forth with me on the forum and has an infinity better chance of getting recognized as something for development to look at. If it is in the SPR database, it even has a chance be looked at and fixed for SOLIDWORKS 2020 if statistically, the cavity functionality bubbles up as something to look at as they are working on "quality projects". If you wait until next year's TTL, you've wasted an entire year and I very much doubt this issue will bubble up very high in the TTL list with other user votes so it will be way down on the list of 1000 other enhancements. In such case, it will probably be read by the person responsible for the cavity area but it wouldn't bubble up in priority to actually be fixed unless there is other supporting data like SPRs.

                                      In your last message you say:

                                      " I have attached here if you or SOLIDWORKS STAFF would like to look at it."

                                      But guess what; that is very likely not going to happen. Having it here relies on someone actually seeing the conversation as it happened or finding it later through searching if something else like a large number of cavity SPRs triggers a product definition engineer to search the forum for additional examples/information; that may or may not happen. And since your thread is titled ZTG and not in the "Plastics & Mold Design" section, it is less likely to be found in searches anyway.

                                       

                                      By the way, I was at SOLIDWORKS headquarters last night for their annual holiday party as a guest and I happened to mention this thread and discussion to the head of Product Definition (the team who has primary responsibility for researching/deciding what projects go into each release of software and researching the details/writing the specifications for what gets implemented in those projects) and he was in full agreement with what I've said above, especially since SOLIDWORKS releases are now more and more concentrated on finding and solving reliability and performance issues in the software. Your best chance of getting the issue looked at/addressed is to get it in the SPR database.

                                       

                                      I apologize if any of this comes across as harsh, but again, truly my only motivation for coming here is to help SOLIDWORKS users solve their problems (primarily) and stimulate my brain with troubleshooting challenging problems. It frustrates me severely when users want to continue to beat their head against a wall instead of taking advice that has an infinitely better chance of getting their problem solved. If you won't decide to take advantage of those processes, then hopefully someone else reading this will learn from it and help improve the software for everyone when they encounter issues.

                                       

                                      Thanks,

                                      Jim

                                        • Re: ZTG
                                          John Stoltzfus

                                          Jim Wilkinson - Well said - Merry Christmas to you and your family

                                          • Re: ZTG
                                            Brian Brazeau

                                            Hi Jim, I totally submit to your experience and expertise on the modeler and SW internal development processes.

                                             

                                            I'm happy that you are not against allowing ZTG if there's a way to turn it off.

                                             

                                            You are right my perspective is from a user stand point as is most of the people on this forum because that's what we are Users.

                                             

                                            I do realize that from a modeler stand point implementing ZTG would be extremely difficult other wise they would have done it by now. What about the Dual kernel route?

                                             

                                            I don't believe I would classify my issue as a bug, but rather a modeler limitation. (Even if it has nothing to do with ZTG). You could say it is MY modeling work flow, but if it were possible to (Extrude a silhouette (Of any shaped part) by the part and then use the cavity function to extract that solid) you would probably find most people using that method to split molds for tool design. The reason they don't is it is not possible. Could you explain to me the modeler reason this functionality could not be implemented?  I don't use that method I use methods similar to the one you showed, but that's only because the way I describe above does not work 90% of the time.

                                             

                                            You are right initiating an SPR would take less time than debating this subject but it would not reach as many people, and if I did it for every instance I run across it Would take a ton of time. Instead I've found ways around it and use them. That is also why you may not hear from a lot of people on this. They have found ways around it and use them rather than express the issue here. Also I've read threads that talk about SPRs that never get solved or claim to be solved when they're not. The fact that you offer that they are looking for a replacement to the TTL and enhancement requests speaks to the problems with these procedures.

                                             

                                            As far as SW developer chances at finding this I would hope they take the time to examine at least the top ten in the TTL with scrutiny and I'd be surprised if the cavity function shortcomings like the one I describe are not common place.

                                             

                                            Finally, don't be concerned with coming off harsh as I said we can always agree to disagree.

                                              • Re: ZTG
                                                Jim Wilkinson

                                                Brian Brazeau wrote:

                                                 

                                                You are right my perspective is from a user stand point as is most of the people on this forum because that's what we are Users.

                                                 

                                                I don't believe I would classify my issue as a bug, but rather a modeler limitation.

                                                And here is the problem that many users make...in the first sentence you say you are a user and taking the perspective of a user, but in the second sentence, you are taking the perspective of a developer. You are saying it is a modeler limitation. Only a developer or someone extremely familiar with the modeling kernel and its implementation in SOLIDWORKS can say that it is a limitation. This is why it is so important to submit it to Technical Support; let THEM determine if it is a limitation or not. Calling it a limitation means that it should go through the enhancement process rather than the bug process. SOLIDWORKS implements a couple of hundred enhancements each major release, and virtually none during the service packs. But they fix thousands of bugs with each major release and through the service pack cycles. This is why it is so important to get things in through the bug process if it is at all possible that it is a bug. It has a much better chance of being addressed, especially because what a user may think is a limitation may actually be an error in the coding or something simple to correct/address. So as I said earlier, if in doubt, get it to your reseller/technical support. Yeah, yeah, everyone says it takes time, but wouldn't you rather have fixes for bugs that allow the system work better rather than years of figuring out and implementing workarounds to those issues?

                                                 

                                                You could say it is MY modeling work flow, but if it were possible to (Extrude a silhouette (Of any shaped part) by the part and then use the cavity function to extract that solid) you would probably find most people using that method to split molds for tool design. The reason they don't is it is not possible. Could you explain to me the modeler reason this functionality could not be implemented? I don't use that method I use methods similar to the one you showed, but that's only because the way I describe above does not work 90% of the time.

                                                This functionality probably can be implemented. I'm not familiar enough with the research that has gone into making the mold tools as they are today and whether that approach was considered. Usually the approaches implemented are done so after researching with a number of different customers using the software for the particular task. But as I've said through this whole thread, I would expect the things you are trying to do to work and would consider them bugs. If they get logged as bugs and the product definition engineers and development engineers see the workflows you and others are trying to achieve they may solve it in a couple of ways: they may be able to make the workarounds that you are currently trying to do just work (i.e. convert the 3d split line to a 2d sketch and extrude it and have it not fail when making a cavity), they may enhance extrusions so they can be made from a split line and then make sure cavity works from that, or they may do both. Through all of that they may even come up with an even better approach to do the whole thing. By the way, in my tests, I did attempt to do something similar to extruding the split line; I made a fill surface from the split line and extruded the face of the split line (since you can extrude 3D faces). It also failed to make the cavity. It was an interesting test because you can also add draft to the extrusion and I think it worked once the draft got to be a certain angle, but never when the walls were vertical.

                                                You are right initiating an SPR would take less time than debating this subject but it would not reach as many people, and if I did it for every instance I run across it Would take a ton of time. Instead I've found ways around it and use them.

                                                As I stated earlier, there are ways to get an SPR into the system AND get it reach many people. Submit it to technical support, get the SPR#, and then post that with the example to reach other people and get them to also submit their examples against the SPR. The problem with JUST putting it out here is you are reaching THE WRONG PEOPLE. The ONLY people who can fix these problems are the SOLIDWORKS developers and SPRs are the most direct route to them, especially for bugs.

                                                 

                                                That is also why you may not hear from a lot of people on this. They have found ways around it and use them rather than express the issue here.

                                                I KNOW that this happens all the time. And this is one of the problems that I'm trying to get everyone to understand in this thread; if users just workaround a problem and never report them, then SOLIDWORKS will never know about them or never know about how important it is if multiple users don't report it. And then users get frustrated that it is never fixed and come here and complain, yet what do you expect if it has never even been reported to SOLIDWORKS? Sure, you can say that they should find it in testing, but even in our investigation in this thread, we've tried out 5-10 different methods of accomplishing the same thing; some work, some don't, and the ones that do pseudo-work produce various results. Users argue that SOLIDWORKS should test the software more thoroughly before releasing and in some cases that is true. But there are only a couple hundred developers, QA, and PD people at SOLIDWORKS vs. millions of users. SOLIDWORKS software is really a general toolbox of features; they can't possibly test or even conceive of all the different ways users may use the tools in combination even on one example case let alone on the infinite possibility of different geometry cases that users can create. This is why user data is so important when problems are encountered.

                                                 

                                                Also I've read threads that talk about SPRs that never get solved or claim to be solved when they're not.

                                                Of course not all SPRs can be solved. Again, this is why it is important that more users submit them....so similar SPRs get grouped together and bubble up in priority. If there is just one cavity SPR in the system, it is going to stay there all alone, never looked at. If there are a whole bunch of them, they will get noticed and looked at and eventually solved. And relating to claims of SPRs being fixed that really aren't, there can be all sorts of explanations for that whether it be truly that there was a mistake made in closing the SPR (no system is perfect) or that a user attached themselves to an SPR or a VAR attached them to it, when the problem wasn't actually the same exact problem. Again, an important reason to get SOLIDWORKS example data submitted along with the SPR. If your data isn't attached to the SPR, of course the developers can't test to see if your exact case is fixed, and it may be a variation on the same type of problem that needs to be fixed in a different way. What you're not seeing on the forums is the thousands of SPRs that are fixed and users are delighted to see are fixed; because users rarely post about them. They come to the forums when they are having issues.

                                                 

                                                The fact that you offer that they are looking for a replacement to the TTL and enhancement requests speaks to the problems with these procedures.

                                                Yes, the limitations with the current enhancement systems are well understood. But again, what we are talking about here are bugs and bugs will ALWAYS have to go through technical support, be evaluated in depth, and submitted through the SPR system (not the current or new enhancement system). Again, I can't stress the importance enough of getting bugs in as SPRs and if in doubt as to whether it is a bug or limitation, submit it and let technical support decide. Again, SOLIDWORKS addresses an order of magnitude more bugs than enhancements in any release of software.

                                                As far as SW developer chances at finding this I would hope they take the time to examine at least the top ten in the TTL with scrutiny and I'd be surprised if the cavity function shortcomings like the one I describe are not common place.

                                                They do look at the top 10 of the TTL and I know many product definition engineers look at all of the enhancements in each year's TTL within their area of expertise. As for the cavity function shortcomings in this regard, I haven't seen anything that stands out in the TTL in the past nor do I find many existing SPRs if I search "cavity parting line" in the knowledge base, so I wouldn't be so sure that this is a well known shortcoming.

                                                 

                                                I do realize that from a modeler stand point implementing ZTG would be extremely difficult other wise they would have done it by now. What about the Dual kernel route?

                                                I am not exactly sure what you mean; two copies of Parasolid kernel, one with manifold and one with non-manifold? This is assuming that Parasolid could make a non-manifold version of their kernel. Or maybe you are talking about a second kernel like ACIS, Dassault Systemes CGM, or the like. That introduces a huge amount of complexity. Every kernel works differently even down to the feature level; so every single feature in the software would have to be made compatible with each kernel, and each feature may have to have different options depending on what kernel is currently running. SOLIDWORKS would have to store information in each file to indicate which kernel to use to regenerate that particular model. And if SOLIDWORKS provided the ability to switch which kernel an individual file was using, then you would certainly have incompatibilities or failures at the individual feature level when the part is regenerated in the other kernel. So if you ask me, this approach is likely even more difficult to pull off effectively than the approach of having one kernel that has the ability to do both manifold and non-manifold.

                                                 

                                                I feel like I'm repeating myself a lot in these replies. But I feel like the more ways I say it, perhaps the more it will sink in to the minds of users and they will take it to heart so the software can be improved not only for themselves, but everyone.

                                                 

                                                Thanks,
                                                Jim

                                                  • Re: ZTG
                                                    Dan Golthing

                                                    Jim, a little late to the discussion here, sorry.

                                                     

                                                    You say that a developer needs to determine if not handling ZTG is a limitation or not.

                                                     

                                                    The fact is that it IS a limitation.  We are not only being disallowed the ability to generate certain geometry, but maybe more importantly, we cannot import certain geometry from more capable CAD systems.  This is a fact and it is a limitation.  We don't need a developer to tell us one way or the other to quite clearly understand that we have a problem.

                                                     

                                                    Personally, it may only be 10-20% of the time that ZTG is a problem from my end from a modeling perspective, but 80-90% of the time it is an issue importing geometry.  Much of that is simply that other CAD systems allow sheetmetal flanges to touch.  This is a guaranteed s-show when you import it into SolidWorks.  Additionally, when another CAD platform exports an assembly as a part, it sometimes joins bodies in a manner that creates ZTG. 

                                                     

                                                    There's a tremendous frustration regarding this and it is a giant limitation.

                                                     

                                                    One imported file I was recently wrestling with had 6700 features when I queried the Performance Evaluation.  This had a rebuild time of almost 70 seconds.  Most of these features were fractured surfaces due to geometry that could not knit in SolidWorks. 

                                                     

                                                    This file will forever be a warning sign in an otherwise unblemished feature tree of any assembly it ever reports to!! 

                                                     

                                                    And note that this file represented only a tiny fraction of the overall assembly I need to import and clean up.

                                                     

                                                    You say that it might even be "impossible" to implement a solution to handle non-manifold geometry.

                                                     

                                                    As I understand it, IronCAD uses a dual kernel, parasolids as the primary and ACIS as the secondary.  Unless I'm missing something, it blows my mind that SolidWorks can't outperform, or at least match, a CAD platform that has less annual revenue than I would assume is lost through simple bureaucratic inefficiencies that I'm sure SolidWorks is apt to have. 

                                                     

                                                    So unless somebody can explain to me how IronCAD and others can do it and the great SolidWorks can't, I as well as many others are going to continue to be confused.

                                                     

                                                    On the other hand, if nobody was able to create non-manifold geometry, then I guess we'd all have much less to say.  But the fact is, OTHERS CAN DO IT!

                                                      • Re: ZTG
                                                        Jim Wilkinson

                                                        Dan,

                                                         

                                                        You misread what I said. I never said that a developer needs to look at ZTG to say whether it is a limitation. ZTG IS a documented limitation of SOLIDWORKS. Whay I've said through this whole thread is that I don't believe the specific case that Brian is running into is in fact ZTG and a developer would need to look at it to see if it is ZTG or not.

                                                         

                                                        I've also commented on dual kernels alreadyS in this thread. Sure it can and has been done but there are certainly tradeoffs in doing so like potentially twice the amount of development work so if SOLIDWORKS had implemented dual kernels from.the beginning, it nay only have half the functionality it has today. And potentially twice the number of bugs since each kernel has to be independently debugged for every single feature/functionality. And models between the two kernels may not be compatoble so they may not even be able to be used together in all situation. It coudl very well be that IronCAD does not have as much functionality and has less revenue because they've gone the dual kernel route. So again, tradeoffs from a functionality and business standpoint (which are both things that affect not only the company but the users of the product).

                                                         

                                                        If you read  the whole thread and my stance on ZTG, you will see that I am in favor of it as an option, but I think it is extremely challenging to accomplish from a techical standpoint (whether it is done with dual kernels or by some other method).

                                                         

                                                        -Jim

                                                        • Re: ZTG
                                                          Brian Brazeau

                                                          Dan. I don't think you are late to the discussion, but you are definitely wasting your time at the moment. The consensus of the poster is that ZTG or Non-manifold geometry is probably too hard to implement yet it is admitted that it is unknown how hard it would be to implement. When you start getting into conversations that circle around on themselves like that its time to face facts. ZTG could be number 1 on the list and SW still wouldn't do a thing about it. They don't have to because not enough people have left their software because of this SEVERE limitation. There is not just 1 cad package out there that handles this there are many. It was mentioned that if SW had started from the beginning with 2 kernels that we would have half the features and potentially twice the bugs. I disagree on the bug issue as bugs are addressed and pretty much ironed out during the life of an iteration of SW. (2018 bugs are usually address before 2019 comes out or at least they should be) and as far as having half the functionality, I still don't know if I agree, but regardless I'd live with half the functionality if this EXTREMELY important one was implemented. How do I justify extremely? Just look at how often, how long, and how high it has been on the TTL in the past. As to the discussion of whether what I'm experiencing is actually ZTG or not, as Paul Salvador suggested why doesn't someone from SW (preferably a developer) get involved in this discussion and begin to explain the real reason they don't even attempt to implement this!

                                                            • Re: ZTG
                                                              Dan Golthing

                                                              It was number 1, if you remember, on the TTL in 2015 IIRC!

                                                               

                                                              If IronCAD's functionality is less than SWX, which I'm sure it is, I doubt it's because of the dual kernel.  If I remember, they came out after SWX and SWX already had some momentum at the time. 

                                                               

                                                              It's a fact, SolidWorks is the McDonalds of CAD.  It's the most ubiquitous CAD system and they try to appeal to the masses.  The masses don't even understand what ZTG is!  "why won't my model section!? Oh well, I'll just section it a little bit off from where I want, never mind that it may mess up my dimensions..."

                                                               

                                                              That's one of my biggest complaints about SolidWorks, that it does appeal to a very broad range of users.  Therefore, development will typically be aimed somewhere near the middle.

                                                               

                                                              Your're right, it would be nice to have some developers come on here and explain the in's and out's of implementing a dual kernel or what it may take for the parasolid kernel to evolve.  What if it were that simple, that Dassault told Siemens to improve their kernel once and for all. 

                                                               

                                                              Are there developers there at SolidWorks that attack their job like some of us attack ours?  When I see a challenge, I get excited.  What I don't get excited about is going to work and just doing hum drum stuff.  If I'm not innovating, I'm not happy.

                                                               

                                                              Just from a consumer perspective, I've been using SWX for about 20 years.  At $9,000 for the seat and about $2500/year, that puts my investment somewhere around $34,000 and growing.  If everybody, all users that is, had some skin in the game, I believe their involvement and expectations would be quite different.

                                                               

                                                              Many of us have spent a lot of money on this product.  Some have spent a lot of time on the forums explaining why it's so important to our workflow to have this capability.  It would be nice if SolidWorks put together a committee to figure out what it would take to implement and then let us know the "whole truth and nothing but the truth".

                                                               

                                                              How about for a first swing SolidWorks implements a dual kernel for IMPORT only.  That way it doesn't effect the program functionality, bugs etc.  So when trying to import ZTG from other software, somehow it would alert the user to ZTG, allow the second kernel to activate, import the geometry, and then somehow allow manipulation of that geometry so that it can finally be saved in SolidWorks WITHOUT ZTG!?

                                                               

                                                              The best example of this would be sheetmetal from CREO with touching flanges.  If we could open it in a dual kernel in a special environment that allows some move face commands or chamfer or something to eliminate the ZTG so that it could be saved in SolidWorks without errors??

                                                               

                                                              I don't know, I'm assuming you've hired some brilliant people that could figure all this out, assuming their hands aren't tied.

                                                      • Re: ZTG
                                                        Alin Vargatu

                                                        Jim Wilkinson wrote:

                                                         

                                                        Brian Brazeau wrote:

                                                         

                                                        Thank You Jim, I guess we'll just have to agree to disagree. I think next time the TTL comes around I'll just enter a request to make the "Cavity" function work with a silhouette edge and then we can start this whole conversation over again. I will not be submitting an SPR, but disagree with your assessment that there will be nothing for the development staff to work on. It is all right here complete with files and my contact information. In fact if I had anything to say about it I would direct development staff to use this "TTL" and all past ones year round for subjects and info on what to work on. I have submitted SPR's in the past and don't think that it works well. Incidentally, I got the split to work with a clean edge at a straight diameter by constructing the entire solid to do the "Cavity" feature from from surfaces and knitting them together. I have attached here if you or SOLIDWORKS STAFF would like to look at it. If I can do it with surfaces it should be do-able with solids. As for pinning our hopes on ZTG I believe that "Non-manifold geometry" would open up far more solutions than it would create problems and I won't be convinced otherwise. Sorry.

                                                         

                                                        Hi Brian,

                                                         

                                                        You can disagree with me all you want, but I worked at SOLIDWORKS for almost 23 years (before retiring 3 months ago) and know quite a bit about the modeler and SOLIDWORKS internal processes on development, so you can trust my advice. I have no motivations coming to this forum now other than to:

                                                        1. Help users with solving problems they are encountering.
                                                        2. Have fun trying to understand and solve problems users are facing with the software; especially geometry problems because they are good "brainteasers". This was one of my favorite part of running the technical support department for my first 4 years at SOLIDWORKS when it was actually part of my job and I didn't have as much time to do it in my other roles at the company, so I'm happy to have some time to do it now.

                                                         

                                                        ZTG: Maybe you have misinterpreted my stance on ZTG, so let me start with that:

                                                        Personally, I think the best user experience for users would be to allow ZTG, but have an option to choose the behavior, so for those users that don't want it, simply turn the option on to not allow it. That would provide the best of both worlds; users that want ZTG could use it, and those that see the benefit could allow it. Win/win right?

                                                         

                                                        But the reality is, actually allowing ZTG in SOLIDWORKS is an extremely difficult problem to solve and may NEVER be solved. Your statement of "I believe that "Non-manifold geometry" would open up far more solutions than it would create problems" is purely a statement from a user perspective. And while I somewhat agree with that from a user perspective, having an option to allow it or not completely mitigates the potential problem of whether a user thinks it is good or not; they can choose for themselves.

                                                         

                                                        But from the modeler standpoint, the statement of "Non-manifold geometry" would open up far more solutions than it would create problems" is very likely untrue. My understanding from all articles that I have read and people I have talked to is that whether a modeling kernel is manifold or non-manifold is fundamental to the underlying mathematics. It may be that it is not even possible to make ZTG optional/switchable in a modeling kernel; it either allows it or it doesn't. And there are very likely things that manifold modeling kernels can do that non-manifold modelers cannot. So let's say Parasolid could go back and change the underlying mathematics to be non-manifold instead of manifold (which may be an extremely difficult, if not impossible task in the first place), it may be that now that the modeler uses non-manifold calculations, some of the old calculations that used to work when it was a manifold kernel no longer work. So when your regenerate an old model that worked with the manifold kernel, some features may fail now that it is a non-manifold modeler.

                                                         

                                                        So again, my stance on ZTG is yes, it would be great to have as an option for users, but from a modeler standpoint is extremely difficult if not impossible to implement and may introduce more modeler problems than it solves.

                                                         

                                                        SOLIDWORKS development/support processes:

                                                        You say:

                                                        "In fact if I had anything to say about it I would direct development staff to use this "TTL" and all past ones year round for subjects and info on what to work on."

                                                        This is probably the crux of our disagreement. You can say you'd like their processes to be a certain way, but they need processes that work for supporting over a million users. So you can continue to fight against their processes and be disappointed when your problems continue to exist in the software, or you can embrace the processes and you may find that your problems are solved much more quickly. To support that many users, they need to work from structured databases and statistics. That is exactly what the SPR system is; it is a way to track both software problems and enhancements in a database where they can track how many users are having the same issue and group like problems/enhancements together to find issues/projects to work on that will give the most users the most amount of benefit. In addition, it allows resellers and users to be notified when problems are fixed. The product definition and development teams are constantly analyzing the SPR system for issues to solve in the software. It is the primary driver for improvement, especially to these reliability problems. Yes, they also look at the TTLs for past years, but in its current form, it is just too unstructured to be used as the primary source for data; it is used as a secondary source to find things to work on and get additional information and user contacts for projects that have been identified through the SPR system. Forum threads are also used as a secondary source, but they are even MORE unstructured and difficult to find information from.

                                                         

                                                        As has been mentioned elsewhere, they are looking to replace the TTL and enhancement system with a new system that has all of the benefits of the SPR system that I mention and more, but I can't say when that will be available. And your problem is considered more of a bug than an enhancement so would have more exposure from a development standpoint in the SPR system even when the new enhancement system comes out. Bugs will continue to go through the SPR system even when the new enhancement system comes out because bugs are fundamentally different.

                                                         

                                                        So, my suggestion to you and others is:

                                                        • For bugs like this, be sure to submit it as an SPR through your reseller so you get an SPR#. Then the development staff has your data and description of the problem and it is categorized under the cavity functionality in the database. For these split line/cavity type problems, I would submit a different SPR for each case you run into (since it sounds like this is a common thing you encounter). What this will do is increase the number of SPRs in the cavity functionality and therefore, statistically, cavity will bubble up higher as an area that needs to be looked at.
                                                        • It is unclear if this is a problem only you are encountering because of the modeling workflow you are using or if other users are encountering it. For that, I would suggest that once you have an SPR, post to the appropriate part of the forum ("Plastics & Mold Design" in this case), and describe the workflow/examples/SPRs and ask that if other users are facing the same problem, have them submit their data to their reseller referencing the same SPR. That way, technical support will either create a new SPR for the other users problem if they find it to be different enough or they will add it to the same SPR with the additional user data on the SPR. In either case, the cavity SPRs will bubble up higher because they look for both quantity of SPRs in an area and number of customer "hits" on those SPRs.

                                                         

                                                        Doing these things will take less time than the amount of time you've spent going back and forth with me on the forum and has an infinity better chance of getting recognized as something for development to look at. If it is in the SPR database, it even has a chance be looked at and fixed for SOLIDWORKS 2020 if statistically, the cavity functionality bubbles up as something to look at as they are working on "quality projects". If you wait until next year's TTL, you've wasted an entire year and I very much doubt this issue will bubble up very high in the TTL list with other user votes so it will be way down on the list of 1000 other enhancements. In such case, it will probably be read by the person responsible for the cavity area but it wouldn't bubble up in priority to actually be fixed unless there is other supporting data like SPRs.

                                                        In your last message you say:

                                                        " I have attached here if you or SOLIDWORKS STAFF would like to look at it."

                                                        But guess what; that is very likely not going to happen. Having it here relies on someone actually seeing the conversation as it happened or finding it later through searching if something else like a large number of cavity SPRs triggers a product definition engineer to search the forum for additional examples/information; that may or may not happen. And since your thread is titled ZTG and not in the "Plastics & Mold Design" section, it is less likely to be found in searches anyway.

                                                         

                                                        By the way, I was at SOLIDWORKS headquarters last night for their annual holiday party as a guest and I happened to mention this thread and discussion to the head of Product Definition (the team who has primary responsibility for researching/deciding what projects go into each release of software and researching the details/writing the specifications for what gets implemented in those projects) and he was in full agreement with what I've said above, especially since SOLIDWORKS releases are now more and more concentrated on finding and solving reliability and performance issues in the software. Your best chance of getting the issue looked at/addressed is to get it in the SPR database.

                                                         

                                                        I apologize if any of this comes across as harsh, but again, truly my only motivation for coming here is to help SOLIDWORKS users solve their problems (primarily) and stimulate my brain with troubleshooting challenging problems. It frustrates me severely when users want to continue to beat their head against a wall instead of taking advice that has an infinitely better chance of getting their problem solved. If you won't decide to take advantage of those processes, then hopefully someone else reading this will learn from it and help improve the software for everyone when they encounter issues.

                                                         

                                                        Thanks,

                                                        Jim

                                                        Jim, who should we talk to in order to turn your post into a sticky?

                                                         

                                                        This is absolute priceless information!

                                                          • Re: ZTG
                                                            Jim Wilkinson

                                                            Alin Vargatu wrote:

                                                             

                                                            Jim, who should we talk to in order to turn your post into a sticky?

                                                             

                                                            This is absolute priceless information!

                                                            Which part do you mean? The support/processes stuff or my thoughts on ZTG? On ZTG, really these are just my thoughts on it and not "gospel" so I don't think should be sticky. But I could perhaps do an FAQ on the support/processes stuff and make it sticky. I'm sure as a reseller, and one of the best ones, you already know that those are the best processes to follow.

                                                             

                                                            Thanks,

                                                            Jim

                                                              • Re: ZTG
                                                                Glenn Schroeder

                                                                Jim,

                                                                 

                                                                As soon as I saw Alin's post, and before I saw your reply to it, I was thinking a FAQ on this subject might be a good thing.  The only reason I'd be hesitant is the fear it would turn into another big debate like the one currently going on in the Idea.

                                                                 

                                                                Glenn

                                                                • Re: ZTG
                                                                  Alin Vargatu

                                                                  Jim Wilkinson wrote:

                                                                   

                                                                  Alin Vargatu wrote:

                                                                   

                                                                  Jim, who should we talk to in order to turn your post into a sticky?

                                                                   

                                                                  This is absolute priceless information!

                                                                  Which part do you mean? The support/processes stuff or my thoughts on ZTG? On ZTG, really these are just my thoughts on it and not "gospel" so I don't think should be sticky. But I could perhaps do an FAQ on the support/processes stuff and make it sticky. I'm sure as a reseller, and one of the best ones, you already know that those are the best processes to follow.

                                                                   

                                                                  Thanks,

                                                                  Jim

                                                                  The processes mainly. You are right, they can be found in many places, but they are not presented as clear and with as much passion like in your post.

                                                                    • Re: ZTG
                                                                      Jim Wilkinson

                                                                      Alin Vargatu wrote:

                                                                       

                                                                      The processes mainly. You are right, they can be found in many places, but they are not presented as clear and with as much passion like in your post.

                                                                      OK, agreed. I'll write up an FAQ on it when I get a chance.

                                                                       

                                                                      Thanks,

                                                                      Jim

                                                    • Re: ZTG
                                                      Brian Brazeau

                                                      Sorry just realized I put Hi Matt instead of Hi Jim. I must be High.

                                                      • Re: ZTG
                                                        Ryan McVay

                                                        Jim Wilkinson Thanks for the clarification! That is what I was thinking as well. You explained it much better than I.

                                                        • Re: ZTG
                                                          Paul Salvador

                                                          Hello Jim,.. this imho, is very good content.. and I believe many would like to see SW Corp dedicate a site which fully explains kernel topology issues, in detail, All examples geometry faults known within the solidworks/parasolid kernel,.. ways to,.. identify, define, isolate, delete, repair,.. so ALL users will understand the errors and limits of the kernel and so we ALL can educated and communicate with understanding what we are working with and sending to to fixed. ... then we can all be truly Kumbaya.

                                                            • Re: ZTG
                                                              Jim Wilkinson

                                                              Paul Salvador wrote:

                                                               

                                                              Hello Jim,.. this imho, is very good content.. and I believe many would like to see SW Corp dedicate a site which fully explains kernel topology issues, in detail, All examples geometry faults known within the solidworks/parasolid kernel,.. ways to,.. identify, define, isolate, delete, repair,.. so ALL users will understand the errors and limits of the kernel and so we ALL can educated and communicate with understanding what we are working with and sending to to fixed. ... then we can all be truly Kumbaya.

                                                              Yes, that would be nice, but that is assuming that information is all known in a way that can actually be documented. I'm not sure Parasolids makes any of that information available to SOLIDWORKS. I've done research on the web trying to find some of that sort of information myself and haven't been successful. Parasolid may keep it proprietary but I am not completely sure. In many cases, savvy users such as yourself know more about these limitations than SOLIDWORKS themselves since you use the software in actual practice much more than anyone internally. SOLIDWORKS is such a general toolset that can be used for so many different things in so many different ways, to me it is hard to come up with generalizations of geometry issues that should/could be documented. As has been shown on the model in this thread, some approaches work, some don't even to try to make the same geometry. So where is the generalization that can be documented? To me most all of these approaches SHOULD work so I consider them bugs (and from my experience, SOLIDWORKS developers would too).

                                                               

                                                              And now that I don't work at SOLIDWORKS any longer, please don't take what I say as an official statement from SOLIDWORKS; I no longer work there so these are my own thoughts on the subject based on my experience. It's a bit of a blessing and a curse; I can be a bit more free in interacting with people in the forums and voicing my opinion since I no longer represent the company, but on the flip side it is important for users to understand that this is not the official word from SOLIDWORKS.

                                                               

                                                              As an example, and as I just replied to Alin, don't take my word as gospel or the official SOLIDWORKS statement on the difficulty of implementing non-manifold/ZTG in Parasolid. Some of that is my own speculation from researching on the web about Parasolid and zero geometry and years of experience working on solid modeling development. So it is a well informed opinion, but with all opinions it could very well be proven wrong eventually (but my opinion on that is to not hold your breath ).

                                                               

                                                              Thanks,

                                                              Jim