Direct connection CutList Property to the Custom Property

[mihkov]

I ask for a clear answer!
As of May 2024, no version of the Solidworks software product can establish a direct relationship between a user property value from a cutlist and a user property? (without add-ons and without API)
I have determined that only expressions starting with "SW-" can be associated, however these variables are not actually user created properties. If I manually create an unrelated property in the Cutslist for example: "PARTNUMBER" and the value is "PartNo1", then there is no way I can get this value into the Custom or Configuration Specific?

This syntax works for getting variables from a cutlist (but not native properties) in both Custom and Configuration Specifics:
A working option for obtaining the value of an available SW- variable without configuration:
"SW-Material@@@Sheet<1>@PRT.SLDPRT"
With configuration"
"SW-Mass @@@@00 @@@ Sheet<1>@PRT.SLDPR"

Does not work:
"PARTNUMBER@@@Sheet<1>@PRT.SLDPRT"
"PARTNUMBER@@@@00@@@Sheet<1>@PRT.SLDPRT"
"PARTNUMBER@@00@@@Sheet<1>@PRT.SLDPRT"
Here
PARTNUMBER is a property that I manually created in the Cut List
00 – configuration name
Sheet<1> - name of the cut list element.
PRT.SLDPRT – File name with extension

* Cut list created and updated.

[JSculley]

What should SOLIDWORKS do when two cutlist items have the same user defined property? Which one gets to populate the file property? What you are asking for doesn't make sense.

[AlexLachance]

The way our CustomTools is set-up does this but as JSculley pointed out, when there are multiple instances of body within a part, the dimensions become somewhat more confusing then referencial. To "avoid" the confusion, the company distinguishes between an assembly and a weldment and therefore when it is a weldment the person on the floor knows not to think too much of the dimensions displayed by it.

Edit: Now that I think of it, there could be an expression added to the source code to say that If more then 2 bodies then do not transfer properties to the top level.

[mihkov]

What should SOLIDWORKS do when two cutlist items have the same user defined property? Which one gets to populate the file property? What you are asking for doesn't make sense.

Apparently I don't understand something. Because it makes sense to me.
In Solidworks there cannot be two bodies with the same names in a part.
If we create a sheet part with several sheet bodies, then they will have Sheet<1> Sheet<2> or whatever you want.
Even if in a part with Structure bodies you have 2 identical pipe bodies, they are grouped into one element of the cut list (however, even in this group the bodies themselves have different names Pipe[1] Pipe[2]). Ok - these are 2 geometrically identical bodies, therefore they have the same properties (and the system property QUANTITY = 2)
And now if we assume that the link to the Configuration Properties works from the Cut List Properties in this syntax:
"My custom property@@@@configuration name@@@name of the cut list element@File name.SLDPRT"
This uniquely determines which body we take from and which custom property and in which configuration. Where is the ambiguity?

[mihkov]

Edit: Now that I think of it, there could be an expression added to the source code to say that If more then 2 bodies then do not transfer properties to the top level.

This is exactly what I implement using the API. I need to decide what the Engineer does:
- Makes a regular sheet metal part with one body
- Makes a single-body pipe into a part design
- I decided to assemble the Structure into parts from several bodies of the Structure + add several sheets to them.
- A part with one “simple” body - for example a turned part
- I decided to add documentation to the assembly (instructions) as an empty part with properties.

[JSculley]

Apparently I don't understand something. Because it makes sense to me.
In Solidworks there cannot be two bodies with the same names in a part.
If we create a sheet part with several sheet bodies, then they will have Sheet<1> Sheet<2> or whatever you want.
Even if in a part with Structure bodies you have 2 identical pipe bodies, they are grouped into one element of the cut list (however, even in this group the bodies themselves have different names Pipe[1] Pipe[2]). Ok - these are 2 geometrically identical bodies, therefore they have the same properties (and the system property QUANTITY = 2)
And now if we assume that the link to the Configuration Properties works from the Cut List Properties in this syntax:
"My custom property@@@@configuration name@@@name of the cut list element@File name.SLDPRT"
This uniquely determines which body we take from and which custom property and in which configuration. Where is the ambiguity?

The ambiguity is that there is no restriction on the number of bodies in a configuration. If I have a part file with one configuration and two bodies (and therefore two cut list items), and I give each body a different value for a the same user defined cut list property, just what do you expect to appear in the configuration specific properties?

[mihkov]

The ambiguity is that there is no restriction on the number of bodies in a configuration. If I have a part file with one configuration and two bodies (and therefore two cut list items), and I give each body a different value for a the same user defined cut list property, just what do you expect to appear in the configuration specific properties?

This logic with a cutlist in the part and configurations completely repeats the assembly logic with parts and configurations.

There is configuration A and B in the part.
Configuration A has cut list elements: Sheet1 and Sheet2
Configuration B has cut list elements: Pipe1 and Pipe56
Each of these elements has a custom property: "customPRP"
In the configuration specific, this is how I would access them from Any property:
"customPRP@@@@A@@@Sheet1@Part1.SLDPRT"
"customPRP@@@@A@@@Sheet2@Part1.SLDPRT"
"customPRP@@@@B@@@Pipe1@Part1.SLDPRT"
"customPRP@@@@B@@@Pipe56@Part1.SLDPRT"

This path (well, it can be different) completely takes into account both the body (cut list elements) and configuration.

[JSculley]

We are talking around each other. Let's look at it a different way. If you could do what you are asking, how would you use it? In other words, why do you want to be able to do this?

[mihkov]

We are talking around each other. Let's look at it a different way. If you could do what you are asking, how would you use it? In other words, why do you want to be able to do this?

If only I could do it. Then for parts with one sheet body, or with one construct body, I would do: I made a direct link between the auto-updating sheet metal thickness property from the body and the Special Configuration Properties (yes, there is a Thickness global variable, but there are constructors that, when creating a sheet body, check the box to change the default thickness), and getting from the body this is exactly what is needed. Now is the time to remember about the API, but it is less automatic; you need to run the app and update the data.
I could create a property containing a string with formatting from a combination of properties to fill the drawing frame. Yes, there are a lot of things you can come up with.
I think it’s a crime that there is no connection between these property tables, this is especially difficult for those injured in Excel.
To be honest, I would also like functions for working with strings in Solidworks, like: Left, InStr, LTrim, etc.
Apparently we are just at different levels of interaction with Solidworks. I am still at the Bargaining stage, and you are already at the Acceptance stage.

[JSculley]

If only I could do it. Then for parts with one sheet body, or with one construct body, I would do: I made a direct link between the auto-updating sheet metal thickness property from the body and the Special Configuration Properties (yes, there is a Thickness global variable, but there are constructors that, when creating a sheet body, check the box to change the default thickness), and getting from the body this is exactly what is needed. Now is the time to remember about the API, but it is less automatic; you need to run the app and update the data.

You can use macro features, embedded in your part/assembly/drawing templates that can update things like this automatically on every rebuild.

I could create a property containing a string with formatting from a combination of properties to fill the drawing frame. Yes, there are a lot of things you can come up with.
I think it’s a crime that there is no connection between these property tables, this is especially difficult for those injured in Excel.
To be honest, I would also like functions for working with strings in Solidworks, like: Left, InStr, LTrim, etc.
Apparently we are just at different levels of interaction with Solidworks. I am still at the Bargaining stage, and you are already at the Acceptance stage.

Again, macro features give you the full capability of VBA/VB.NET/C#, so all of the functions (string, math, I/O, etc ) become available to you.