CAD Forum

Looks like @mattpeneguy and I would like to say thanks to the people who came up with the idea to enhance the functionality of the Coordinate Systems in SW2022.

I stress-tested this functionality and I am very excited about the potential use cases. Read about my whole experience here:
https://www.engineersrule.com/coordinat ... -and-axes/

The funny thing is that the more I dug, the more use cases I found. As a result, the title of the article published today by engineersrule.com changed 8 (eight) times) as I was writing!

Just to give you an idea about some of the titles I considered:

• Shrink the FeatureManager with the New Coordinate Systems

• Freedom from the Tyranny of the Model Origin

• 3D Sketching Simplified in SOLIDWORKS 2022

• Another Tool for Top-Down Modeling in SOLIDWORKS 2022

• A Potential Revolution in the SSP (Skeleton Sketch Part) Method

• New Entities for Mating – 2022 Coordinate Systems

• A Revolution in SOLIDWORKS Modeling?

• Coordinate Systems Are Now Mightier than Origins, Planes and Axes

Of course the functionality can be further improved, so let's brainstorm on what would you like to see in the next service packs and future versions. Usually such big enhancements require further refinements over a couple more service packs or even releases.


My Initial Suggestions for Future Improvement:

1. Allow users to apply colors to the coordinate systems. That would dramatically improve their visibility on the graphics area.

2. Make dimensions used in defining coordinate systems visible, selectable and editable in the graphics area. That would drastically improve user speed when revising the model.

Imagine, if you could, simply double-clicking on the coordinate system and its dimensions would pop-up on the screen. Then double-click any of them to edit.

3. Allow the numerical values used in defining coordinate systems to be driven by equations, custom properties or design tables. Adding this functionality will further enable users to automate their design.

4. Allow coordinate system planes to be used in the definition of the intersect feature.

5. Allow the patterning of coordinate systems.

6. Allow sketch dimensions to be attached to a Coordinate System's origin and axes.

7. Fix the bugs shown listed in the article above.

8. Add ability to redefine the Front/Top/Right default orientations based on a Coordinate System

9. When sketching on a Coordinate System Plane, allow the user to redefine the Horizontal and Vertical directions based on the Coordinate System. Thus, the Horizontal and Vertical relations could be used in the sketch.

I'm wondering why number seven isn't number one. Or is bug fixing no longer a priority?

Wow @Alin,
That was quick! When do you sleep?

Kidding aside, I'm only on B of your article, but it occurred to me that maybe to free people from the tyranny of the origin, someone could just "replace origin with coordinate system" as a feature? I haven't fully thought it out, but it may be useful for some workflows.

mike miller wrote: ↑Fri Oct 29, 2021 7:58 am I'm wondering why number seven isn't number one. Or is bug fixing no longer a priority?

I finished part B.
I see you've concluded to not use horizontal or vertical sketch relations, which deals with how the functionality is now...But, should we ask for vertical and horizontal to be redefined with respect to the coordinate system being used, whether that's the origin or an added coordinate system? Draw a sketch on the top plane of a coordinate system and everything is horizontal and vertical with respect to that coordinate system's xyz?
That's how my brain works, and it almost got me into a little trouble a few weeks back when I was working with something that was rotated slightly. I was thinking horizontal and vertical were with respect to the plane I was working on, but nope, it's in relation to the origin. It's pretty obvious when the angle is more than something like 5 degrees, but when it's 1 or 2 degrees those horizontal and vertical relations can throw everything off and leave you scratching your head.

Alin wrote: ↑Fri Oct 29, 2021 8:31 am

I'm not downplaying the significance of the enhancement, but it seems fixing bugs on existing functionality should take precedence over more new stuff. Remember ONE and TWO?

Honestly, we can't justify going to 2022 because every time we upgrade we get so badly burnt by new bugs that we lose all the time we could have gained. I wish it wasn't true but it is.

mattpeneguy wrote: ↑Fri Oct 29, 2021 8:36 am I finished part B.
I see you've concluded to not use horizontal or vertical sketch relations, which deals with how the functionality is now...But, should we ask for vertical and horizontal to be redefined with respect to the coordinate system being used, whether that's the origin or an added coordinate system? Draw a sketch on the top plane of a coordinate system and everything is horizontal and vertical with respect to that coordinate system's xyz?
That's how my brain works, and it almost got me into a little trouble a few weeks back when I was working with something that was rotated slightly. I was thinking horizontal and vertical were with respect to the plane I was working on, but nope, it's in relation to the origin. It's pretty obvious when the angle is more than something like 5 degrees, but when it's 1 or 2 degrees those horizontal and vertical relations can throw everything off and leave you scratching your head.

Great minds think alike. Check item #9 on this list:

https://r1132100503382-eu1-3dswym.3dexp ... NJjqu20FVg

Alin wrote: ↑Fri Oct 29, 2021 9:01 am Great minds think alike. Check item #9 on this list:

https://r1132100503382-eu1-3dswym.3dexp ... NJjqu20FVg

I wonder if SWX could do something similar to the way NX handles sketch and plane orientation? Maybe project an origin or coordinate system on a sketch plane and control orientation based on that?

I don't know much about NX but maybe @SPerman or @HerrTick could enlighten us plebeians.

Nice article Alin! Thank you for exploring this and finding some of the ups and downs of the new stuff, it really helps guide if and what to try to implement as common practice.

I had heard about changes to coordinate systems and was thinking maybe there was a chance that Z could be up but doesn't look like it.

I'm nowhere near excited as Scott is but the shrinking of feature tree application sounds nice. I dislike clutter like Alin's example showed as it's difficult to see what the person was trying to accomplish with all the planes and axis just to define a plane at some location.

I was curious about using a coordinate system in place of origin. But, since some of the sketch relations go back to the origin instead of the plane that the sketch is on, we're not truly "free" from the origin. This shortcoming undermines the usefulness of this application in our usage.

Alin wrote: ↑Fri Oct 29, 2021 9:01 am Great minds think alike. Check item #9 on this list:

https://r1132100503382-eu1-3dswym.3dexp ... NJjqu20FVg

Wouldn't setting these to follow the plane that the sketch is on be better? Not all sketches are created on coordinate systems. Apply a solution that solves the problem in as many cases as possible, not just today's case. Or am I missing something here?

bnemec wrote: ↑Fri Oct 29, 2021 9:16 am Wouldn't setting these to follow the plane that the sketch is on be better? Not all sketches are created on coordinate systems. Apply a solution that solves the problem in as many cases as possible, not just today's case. Or am I missing something here?

Good point. I agree.
Is there any use case that we are not considering where you'd want to maintain horizontal and vertical to the origin or coordinate system of a derived plane as opposed to horizontal and vertical to the plane itself? I can't think of any off the top of my head.

SW beginning to catch up to where NX and Creo were over 25 years ago.

mike miller wrote: ↑Fri Oct 29, 2021 8:51 am I'm not downplaying the significance of the enhancement, but it seems fixing bugs on existing functionality should take precedence over more new stuff. Remember ONE and TWO?

Honestly, we can't justify going to 2022 because every time we upgrade we get so badly burnt by new bugs that we lose all the time we could have gained. I wish it wasn't true but it is.

@mike miller,
I'm with you on 1 and 2. But, every once in a while they add new features that do make that upgrade worthwhile. With some improvements, this looks like it will be one that meets that criteria for us. Off the top of my head, a couple others were, Dynamic Reference Visualization and Performance Evaluation. (The drawing speed improvements may also meet that criteria, but I haven't had a chance to play with that.)

I was hoping the "use envelope components for external references only" would be one of those, but it had a flaw when it was released. Though, I have to give the SW team credit here, they mostly fixed it and they did that quick...But, I haven't had a chance to revisit it. Since I haven't retested it, I'll explain how helpful this may be. You can use envelope components as your SSP sketch parts. Then it all but makes it impossible to get part to part external references you don't intend. Maybe you wouldn't have to use "Isolate" as much? I may start a new thread on this because I don't want to have this thread to go off topic.

Autocad finally wins. We spent 25 years telling people that moving the origin shows how unsophisticated they are, and now, as the company is pushing the 3dx version, they cave in to the Autocad way of doing this. Is there anyone who doesn't believe that the long drawn-out Autocad style skid has started? Sure, it's shiny, but is it really substantial enough to make you ignore everything else that's happening?

mike miller wrote: ↑Fri Oct 29, 2021 9:05 amI don't know much about NX but maybe @SPerman or @HerrTick could enlighten us plebeians.

NX and Creo have had fully-functional coordinate systems ("CSYS") since I first laid eyes on them (as UG and Pro/E) back in the 90s.

A CSYS can be defined and redefined in just about any way one can imagine one might need. Each CSYS consists of three functional principle planes and three principle axes, plus an origin. All parts are selectable and useable as references for features, sketches, constraints, etc.

It is a huge advantage to have all these elements combined in one definition. Having perpendicular and normal planes and axes simultaneously defined saves hours of agony.

Also, the ability to transform entire sets of sketches and features by redefining a single CSYS is invaluable.

Creo also lets one define views based on a CSYS, and updates view orientation when the CSYS changes.

Fully functional CSYSs are a godsend when doing in-place design (i.e. design where all components have common absolute coordinate systems). Often, the absolute is not square with the part's intuitive CSYS. Sometimes, context changes. Ability to respond to these conditions is greatly simplified. In SW, it was an arduous chore, with additional uncertainty of lack of control of sketch and datum directions.

I have no idea why SolidWorks is taking so long to provide such a basic and essential capability.

matt wrote: ↑Fri Oct 29, 2021 10:50 am Autocad finally wins. We spent 25 years telling people that moving the origin shows how unsophisticated they are, and now, as the company is pushing the 3dx version, they cave in to the Autocad way of doing this. Is there anyone who doesn't believe that the long drawn-out Autocad style skid has started? Sure, it's shiny, but is it really substantial enough to make you ignore everything else that's happening?

I am not sure about that. First of all this use case (freedom from origin) was most likely not part of the developer’s scope of this enhancement. They probably wanted to give users access to the axes and planes of the CS.

It is up to us, the users, to come up with use cases and engage with SW to further improve the functionality to fit our needs.

HerrTick wrote: ↑Fri Oct 29, 2021 11:54 am NX and Creo have had fully-functional coordinate systems ("CSYS") since I first laid eyes on them (as UG and Pro/E) back in the 90s.

A CSYS can be defined and redefined in just about any way one can imagine one might need. Each CSYS consists of three functional principle planes and three principle axes, plus an origin. All parts are selectable and useable as references for features, sketches, constraints, etc.

It is a huge advantage to have all these elements combined in one definition. Having perpendicular and normal planes and axes simultaneously defined saves hours of agony.

Also, the ability to transform entire sets of sketches and features by redefining a single CSYS is invaluable.

Creo also lets one define views based on a CSYS, and updates view orientation when the CSYS changes.

Fully functional CSYSs are a godsend when doing in-place design (i.e. design where all components have common absolute coordinate systems). Often, the absolute is not square with the part's intuitive CSYS. Sometimes, context changes. Ability to respond to these conditions is greatly simplified. In SW, it was an arduous chore, with additional uncertainty of lack of control of sketch and datum directions.

I have no idea why SolidWorks is taking so long to provide such a basic and essential capability.

@HerrTick, you explained it so much better than I did in the article. May I quote you going forward?

Great detailed article, @Alin ! This is the first workflow enhancement that I have been excited for in a long time, especially thanks to your detailed unpacking of it. I can imagine the gloss-over that this may have gotten in the What's New presentations that you mentioned. I have some questions which raise further questions. That's a good thing.

Coordinate Systems are reference entities, so are they visible and selectable in lightweight component status in assembly context?
I currently (2018) don't even get Origin to show up in an assembly unless I resolve the component. I am one of the frequent users of reference entities that you mention in the article, but I have never found coordinate systems useful before. So, I am relatively unfamiliar, and apologize if any of these questions are self-evident. Maybe they can be future content if not already tested.

Of course, you can have many coordinate systems in one component like a SSP, right?
That is * *huge* * to me b/c my SSP is more SPP with many planes and intersectional axes derived from those, and only a few (mostly obsolete) sketches. Each of my reference 'sets' can be grouped into a fully useful coordinate system here, there, and so on. Furthermore, drastic reorientation is now simplified. Before, I'd have to alter planes and break its children in the reorientation process, or what's worse, abandon the previous references and create new versions of them. I'm pretty sure that you should still be able to automatically generate errors with some stress tests, but less.

You defined a CS from the Origin. Can you define a new CS from a CS? Is the 2nd CS then a child of the 1st? Is that even advisable?
I'm thinking of some applications where I have a linear thing (piping or patterns) with start and end conditions, and I'd want a CS at each end (and likely more in between) that are tied to each other in the same SSP, so that I could move one and others follow. I'd also love to extract such a related CS into an independent state as needed without deleting and recreating it, as if one of the middle items moves out of line, or the whole line gets split into multiple segments like elbows or even a switchback layout. Maybe I'm asking for cake and eating it by such divergent flexibility: both tied down and releasable.

SSP could reiterate and self-complicate as necessary into a SSA containing multiple mated SSP's, if CS are not interrelated in the same component. That sounds like a daunting mess, but potentially useful to some. Your suggestion of applied colors would help clarify this imposed complexity.

- Speed Round -
Can you pattern a CS?
Can you implement a series of chained CS like you can create a quantity of series planes in one command?
Can you define a CS related from entities, such as the apex of a conical curve, or the lowest point of a dome, around this circle and facing outward, or centered between these faces/edges? Or, is it exclusively numerical entry that creates these?
Can you copy a CS and alter its new variables, like its mirrored condition or an opposite-orientation reference?
Can you name sub-entities of the CS, or only the CS itself? Do mates automatically recognize its same-named mate entities in the Replace Component command? I greatly rely on mated reference entity naming standards to very easily replace similar components.

You showed mating a coordinate system to a coordinate system. Did you show mating an origin to a coordinate system? I'm considering how many library components I would like to go back and redefine: the ideal answer is none. I'd like to use what I have, and improve it as necessary. I'll use new features in new items and apply old things upon them. Then again, I could quickly redefine misoriented library components without actually reorienting them, but rather creating its better 7-aspect reference CS.

Tom G wrote: ↑Fri Oct 29, 2021 12:06 pm Great detailed article, @Alin ! This is the first workflow enhancement that I have been excited for in a long time, especially thanks to your detailed unpacking of it. I can imagine the gloss-over that this may have gotten in the What's New presentations that you mentioned. I have some questions which raise further questions. That's a good thing.

Great questions. It would take some time to answer them property.
Would be great to add Nick Birkett-Smith to a brainstorming session on this. @matt do you know if he is a user here?

Alin wrote: ↑Fri Oct 29, 2021 11:59 am@HerrTick, you explained it so much better than I did in the article. May I quote you going forward?

Properly attributed, contextually-correct quotes allowed and welcome for all.

These are all of the options available for defining coordinate systems in NX. For most of these, the references can be associative (unless chosen otherwise). This includes points, vertices, parametric point-on-curve, surface normals (even normal-at-point), and edge direction at point. As I recall, Creo is similar (maybe even better).

@HerrTick

Not as many options as NX, although you could accomplish some with some helper geometry I suppose.

Alin wrote: ↑Thu Oct 28, 2021 7:00 pm
Of course the functionality can be further improved, so let's brainstorm on what would you like to see in the next service packs and future versions. Usually such big enhancements require further refinements over a couple more service packs or even releases.

• The ability to expand the Coordinate Sys in the tree to expose it's underlying planes, axis, and origin. Useful for tree selecting when its hidden.
• Convert the existing origin and planes to a new global coordinate system with the above options.

jcapriotti wrote: ↑Fri Oct 29, 2021 1:18 pm

• The ability to expand the Coordinate Sys in the tree to expose it's underlying planes, axis, and origin. Useful for tree selecting when its hidden.
• Convert the existing origin and planes to a new global coordinate system with the above options.

Cool. Will add them to the list!

Alin wrote: ↑Fri Oct 29, 2021 12:32 pm Great questions. It would take some time to answer them property.
Would be great to add Nick Birkett-Smith to a brainstorming session on this. @matt do you know if he is a user here?

I am not in a rush to merely satisfy curiosity at this time, and did mock my own dense wall-of-text format by including the Speed Round, acknowledging its length and breadth. Maybe I added some use ideas or permutations, or novice questions for those who haven't used it before. Test things out and share what you find when you can. Thank you.

I'm particularly interested in the Replace Component tests, which could be as complicated (i.e. time consuming) as the number of ways to mate to this complex multi-entity. I could impose this feature upon all current library parts, at a distinct contextual effort and cost which would need justified. It would fork my library and distinguish past designs from newly contemporary, which I have done before with its own learning curve and issues.

@jcapriotti's suggestion, "The ability to expand the Coordinate Sys in the tree to expose it's underlying planes, axis, and origin. Useful for tree selecting when its hidden." would help SO much in the replace mate entity process of Replace Component - because I can't always even see the obscured item, let alone fuss with the graphics interface to select something shown only graphically. I never select mate planes or axes in the display, but always from the tree. That's why I take the time to name them consistently and define them predictably.

Edit: Uh-oh, there's more. What can you do with it in a drawing? What an onion to unwrap.

Alin wrote: ↑Fri Oct 29, 2021 12:32 pm Great questions. It would take some time to answer them property.
Would be great to add Nick Birkett-Smith to a brainstorming session on this. @matt do you know if he is a user here?

Not sure.

Real-life example from recent project.

I had a large thickened set of B-surfaces. I had to repeat a number of multi-feature sets across the body, normal to the surface at each location with varying orientation.

In NX, I could create coordinate systems ("CSYS"), define the features from a seed CSYS, and pattern to any number of other CSYSs. Note that the draft and rectangle orientation also follow the CSYS for each instance. Holes in each boss are thru-holes, FWIW.

HerrTick wrote: ↑Mon Nov 01, 2021 12:11 pm image.png
Real-life example from recent project.

I had a large thickened set of B-surfaces. I had to repeat a number of multi-feature sets across the body, normal to the surface at each location with varying orientation.

In NX, I could create coordinate systems ("CSYS"), define the features from a seed CSYS, and pattern to any number of other CSYSs. Note that the draft and rectangle orientation also follow the CSYS for each instance. Holes in each boss are thru-holes, FWIW.

Just curious, what would you use them for? I never had the need to do what you're showing but I'm sure in some industry its needed or NX wouldn't have added it.

jcapriotti wrote: ↑Mon Nov 01, 2021 4:25 pmJust curious, what would you use them for? I never had the need to do what you're showing but I'm sure in some industry its needed or NX wouldn't have added it.

"Do not worry about your difficulties in Mathematics. I can assure you mine are still greater." --Albert Einstein

And, yes, that is my NX (then UG) handiwork. Every. Single. One. of those vent holes required individual attention.

The previous oversimplified example is from a current project, so I can't share detail or context. Suffice it to say features needed to be patterned on a set of very non-linear surfaces in a controlled manner.

There are indeed places where this capability matters more than a little. Respectfully, while it may be hard for some to imagine, it's where I work on a regular basis.

SW spends most of it's energy making things easier for those working under the tall part of the bell curve. Maybe they're not that interested in stepping out to where the leading edge starts to draw a little blood.

HerrTick wrote: ↑Mon Nov 01, 2021 4:51 pm image.png


And, yes, that is my NX (then UG) handiwork. Every. Single. One. of those vent holes required individual attention.

The previous oversimplified example is from a current project, so I can't share detail or context. Suffice it to say features needed to be patterned on a set of very non-linear surfaces in a controlled manner.

There are indeed places where this capability matters more than a little. Respectfully, while it may be hard for some to imagine, it's where I work on a regular basis.

SW spends most of it's energy making things easier for those working under the tall part of the bell curve. Maybe they're not that interested in stepping out to where the leading edge starts to draw a little blood.

SE has the same capability. Pretty cool.

HerrTick wrote: ↑Mon Nov 01, 2021 12:11 pm image.png
Real-life example from recent project.

I had a large thickened set of B-surfaces. I had to repeat a number of multi-feature sets across the body, normal to the surface at each location with varying orientation.

In NX, I could create coordinate systems ("CSYS"), define the features from a seed CSYS, and pattern to any number of other CSYSs. Note that the draft and rectangle orientation also follow the CSYS for each instance. Holes in each boss are thru-holes, FWIW.

Man, I want to go back to my UG/NX days (v17 to 8.5). Unfortunatelly I got stuck in this SW nightmare....plus PDM in this job. (sigh)

HerrTick wrote: ↑Mon Nov 01, 2021 4:51 pm image.png


And, yes, that is my NX (then UG) handiwork. Every. Single. One. of those vent holes required individual attention.

The previous oversimplified example is from a current project, so I can't share detail or context. Suffice it to say features needed to be patterned on a set of very non-linear surfaces in a controlled manner.

There are indeed places where this capability matters more than a little. Respectfully, while it may be hard for some to imagine, it's where I work on a regular basis.

SW spends most of it's energy making things easier for those working under the tall part of the bell curve. Maybe they're not that interested in stepping out to where the leading edge starts to draw a little blood.

I would like to try that using the Variable Pattern in SW.

Tom G wrote: ↑Fri Oct 29, 2021 12:06 pmOf course, you can have many coordinate systems in one component like a SSP, right?
That is * *huge* * to me b/c my SSP is more SPP with many planes and intersectional axes derived from those, and only a few (mostly obsolete) sketches. Each of my reference 'sets' can be grouped into a fully useful coordinate system here, there, and so on. Furthermore, drastic reorientation is now simplified. Before, I'd have to alter planes and break its children in the reorientation process, or what's worse, abandon the previous references and create new versions of them. I'm pretty sure that you should still be able to automatically generate errors with some stress tests, but less.

You can have a multitude of coordinate systems in a SSP, we are a bit like you, so these changes will be delightful to us because the coordinate system could drive what we currently require an additional plane to drive. Here's an image of one of our SSP for instance.

You defined a CS from the Origin. Can you define a new CS from a CS? Is the 2nd CS then a child of the 1st? Is that even advisable?

We were advised to not define CS from other CS and instead to use elements such as sketch entities and planes.

You showed mating a coordinate system to a coordinate system. Did you show mating an origin to a coordinate system? I'm considering how many library components I would like to go back and redefine: the ideal answer is none. I'd like to use what I have, and improve it as necessary. I'll use new features in new items and apply old things upon them. Then again, I could quickly redefine misoriented library components without actually reorienting them, but rather creating its better 7-aspect reference CS.

We mate the origin of the frame of our dumping trailers to a coordinate system inside our SSP and never really had any issues. We started doing this because we figured we were better off using predefined coordinate systems such as the origin then recreating a new one.



What I was wondering though, @Alin , and I'm sorry if it was asked earlier, is what will happen of previously existing origins. Will they throw errors?

AlexLachance wrote: ↑Tue Nov 02, 2021 1:51 pm
We were advised to not define CS from other CS and instead to use elements such as sketch entities and planes.

Who advised you, and did they give a reason why not to drive a CS with a CS?
Why create additional reference geometry to drive a new CS when it can be driven from the CS directly?

SPerman wrote: ↑Tue Nov 02, 2021 2:01 pm Who advised you, and did they give a reason why not to drive a CS with a CS?
Why create additional reference geometry to drive a new CS when it can be driven from the CS directly?

I agree, if it's not robust to drive a CS with CS, it needs to be. I have stopped using sketch entities to drive anything unless I absolutely have to because it breaks so much and annoys me to have to keep fixing things. However this new functionality works, it needs to be very robust because the main use I can see is top down modeling.

SPerman wrote: ↑Tue Nov 02, 2021 2:01 pm Who advised you, and did they give a reason why not to drive a CS with a CS?
Why create additional reference geometry to drive a new CS when it can be driven from the CS directly?

These are the guys that advised us, they are also the ones that helped us transition from 2D to 3D.
https://www.solutions3dl.com/

I didn't really ask for the reason back then, but I'm guessing it's something about stability, as the guys that advised us are people that aim for stability.

Edit: Excuse me, I just noticed their website is only in french lol.

If it's driven solely by values offsetting it from the origin it better be rock solid. What could possibly happen to it?

If this feature loses references.......well, that would say all you need to know about Dassault. It makes me think of a quote from Thomas Allsup on the old forum:

mike miller wrote: ↑Tue Nov 02, 2021 2:38 pm If it's driven solely by values offsetting it from the origin it better be rock solid. What could possibly happen to it?

If this feature loses references.......well, that would say all you need to know about Dassault. It makes me think of a quote from Thomas Allsup on the old forum: 2021-02-03 13_19_26.jpg

I've seen countless value driven features be thrown off because of the value "reversing" itself.

I am assuming that is old, outdated advice. Considering CS aren't even in a released version of SW yet, I don't think anyone has developed a "best practice" for this software.

AlexLachance wrote: ↑Tue Nov 02, 2021 2:42 pm I've seen countless value driven features be thrown off because of the value "reversing" itself.

But a coordinate system has vectors along each axis, that's what negative numbers are for. Seriously, if SWX decides to use a direction toggle button to boycott the "horror" of negative numbers, that would take the cake. Sure, build in a problem child for the sake of making it "easier" for newbs.

I can't believe they would do that, and yet.....

SPerman wrote: ↑Tue Nov 02, 2021 2:44 pm I am assuming that is old, outdated advice. Considering CS aren't even in a released version of SW yet, I don't think anyone has developed a "best practice" for this software.

Coordinate systems exist already Scott, I'm not sure why you'd think they don't..? My above screenshot even shows that there are 4 in one of our SSP.

EDIT: I guess I was in the mood for an argument when I first replied.

SW coordinate system is so useless that I forgot it even existed. For me, a functional (Cartesian) Coordinate exists of 3 planes, 3 axis and an origin. SW may call that a coordinate system, but that does not make it one.

But that does bring up an interesting question. Is this new functionality, or did they just add the missing parts to what already existed.

@Alin, Are polar/cylindrical coordinate systems an option? Is there any other solidworks functionality that could make use of them?

AlexLachance wrote: ↑Tue Nov 02, 2021 2:35 pm These are the guys that advised us, they are also the ones that helped us transition from 2D to 3D.
https://www.solutions3dl.com/

I didn't really ask for the reason back then, but I'm guessing it's something about stability, as the guys that advised us are people that aim for stability.

Edit: Excuse me, I just noticed their website is only in french lol.

Enough reason to question anything they told you....

SPerman wrote: ↑Tue Nov 02, 2021 3:33 pm EDIT: I guess I was in the mood for an argument when I first replied.

SW coordinate system is so useless that I forgot it even existed. For me, a functional (Cartesian) Coordinate exists of 3 planes, 3 axis and an origin. SW may call that a coordinate system, but that does not make it one.

But that does bring up an interesting question. Is this new functionality, or did they just add the missing parts to what already existed.

@Alin, Are polar/cylindrical coordinate systems an option? Is there any other solidworks functionality that could make use of them?

They are still pretty limited. You can only define one by attaching it to a sketch point/endpoint or a model vertex. 2022 added the ability to type in coordinates to define its location but you can't using those dimensions in equations as they don't expose the dimensions to select. And they add the CS axis, plane, origin as selectable items now.

2021 and less 2022 I haven't had much need of coordinate systems in my line of work. Mostly for exporting which seems to be their only purpose in SolidWorks, and using in measurements and mass properties.

It's disappointing that the functionality is so limited, but it is a step in the right direction. The sad part is by the time this is a feature that has value, my Solidworks workflow will be so ingrained that it will be difficult to make us of it.

jcapriotti wrote: ↑Tue Nov 02, 2021 5:01 pm They are still pretty limited. You can only define one by attaching it to a sketch point/endpoint or a model vertex. 2022 added the ability to type in coordinates to define its location but you can't using those dimensions in equations as they don't expose the dimensions to select. And they add the CS axis, plane, origin as selectable items now.

2021 and less
image.png

2022
image.png

I haven't had much need of coordinate systems in my line of work. Mostly for exporting which seems to be their only purpose in SolidWorks, and using in measurements and mass properties.

That kinda sucks. So they STILL haven't caught up to where SE was 20 years ago, let alone where it is today.

yep.. just add more $$$$ here...

I asked a friend at my old company for an example of how we used CS in NX.

This is a welded stainless steel oil line for the engine. In this first shot you can only see a single CS. That is the origin for the block. You can bring this oil line into the engine assembly, lock that CS to the main CS in the parent assembly, and it is properly located.
Here it is showing the CS for the fitting locations, along with the CS that define the bends in the tube.
And here's a shot of just the CS and the construction geometry.
(ETA:) The sketch is driven by the coordinate systems, not the other way around.

Coordinate systems were a big deal 25 years ago when everybody moving from Autocad felt deprived, but we all learned to live without them and moved on. Why were they added now? It's not an innovative idea, and it doesn't add anything to the software that we haven't been able to accomplish. With all of the ways they are trying to limit access to the desktop version, I don't get the point. Plus, I agree, why would you trust a new feature like this when stuff that has been in the software for decades still flips orientation?