Linking an evaluated sensor value to custom property or global variable

[TRKemp]

So in this example shown, I’ve got a tapered helical spiral. Solidworks provides a quick method for assigning a value to the total developed length of the spiral, via the “sensor”, but does not allow me a simple way to link a custom property or a global variable from the value.

Has anyone had any experience with this? This seems like it could be a very powerful feature, especially considering how easy it is to create these complex evaluations just using the measure tool. All of my searches imply that API is the only way to make it happen.

Am I overlooking something?

Thanks for your help.

[SPerman]

I thought you might be able to use the “measure” feature of a Global Variable, but it won’t work on the helix.

[jcapriotti]

Create a 3d sketch and “Conert Entities” on the helix. Then exit the 3d sketch and add a reference dimension to the converted spline. You can then add that to a custom property value by selecting it.

[TRKemp]

@SPerman

I thought you might be able to use the “measure” feature of a Global Variable, but it won’t work on the helix.

Came to the same conclusion.

@jcapriotti

Create a 3d sketch and “Conert Entities” on the helix. Then exit the 3d sketch and add a reference dimension to the converted spline. You can then add that to a custom property value by selecting it.

Thanks! This is interesting. I could never apply a dimension to the spline while in the context of the 3D sketch, however using your method of applying a “reference geometry” dimension outside of the sketch does work. Great tip

**

I would still like to see if there’s a way to convert a sensor into a property, simply because you can take several individual segemnts or curves and combine them into one measurement that would always update. I could see it being useful in so many applications!

[SPerman]

I can find posts going back a decade asking for that functionality. The only solution I’ve seen are AI hallucinations that don’t work.

[TRKemp]

lol. Sounds like typical SW. Seems like a no brainer to take your most useful measuring tool and allow it to generate variable data. They are seemingly halfway there.

There are some really talented users on here, so I will wait and see if anyone takes a crack at it.

[mihkov]

As far as I understand, the part of the API that works with Sensors was created by someone who doesn’t really enjoy their work.
You described a practical way to create a Dimension Sensor using the Measurement tool - Select a set of suitable objects - Create Sensor. This method creates an “SldWorks.Sensor” with .SensorType = 4, and the Help file states that this type is no longer supported as of version 2009.

For such a sensor, you can get swSensor.GetSensorFeatureData, but it won’t be DimensionSensorData, it’ll be something unknown (to me), and I don’t know how to work with it.
This is where everything breaks down.
If your sensor is a Dimension, then creating a link is no problem, and there’s no point, because you can already get the value from the dimension.

What is needed here is not experience, but secret knowledge.

Below is the code for you to play with. Don’t forget to create the “Measurement1” Measurement Sensor in the Details.

Option Explicit

Const SENSOR_NAME As String = "Measurement1"
Const PROPERTY_NAME As String = "Measurement"

' If the sensor returns a value in meters, and the property needs to be written as mm:
Const VALUE_FACTOR As Double = 1000#
Const VALUE_SUFFIX As String = " mm"

Sub main()

    Dim swApp As SldWorks.SldWorks
    Dim swModel As SldWorks.ModelDoc2

    Set swApp = Application.SldWorks
    Set swModel = swApp.ActiveDoc

    If swModel Is Nothing Then
        MsgBox "No active part.", vbCritical
        Exit Sub
    End If

    If swModel.GetType <> swDocPART Then
        MsgBox "The macro is for a SolidWorks part.", vbCritical
        Exit Sub
    End If

    If UpdateMeasurementProperty(swModel) = False Then
        MsgBox "Failed to update property '" & PROPERTY_NAME & "'.", vbCritical
    Else
        MsgBox "Property '" & PROPERTY_NAME & "' updated.", vbInformation
    End If

End Sub

Function UpdateMeasurementProperty(ByVal swModel As SldWorks.ModelDoc2) As Boolean

    On Error GoTo ErrorHandler

    Dim sensorValue As Double
    Dim propValue As String

    If GetMeasurementSensorValue(swModel, SENSOR_NAME, sensorValue) = False Then
        UpdateMeasurementProperty = False
        Exit Function
    End If

    propValue = FormatNumberInvariant(sensorValue * VALUE_FACTOR, 3) & VALUE_SUFFIX

    Dim swCustPropMgr As SldWorks.CustomPropertyManager
    Set swCustPropMgr = swModel.Extension.CustomPropertyManager("")

    Dim res As Long
    res = swCustPropMgr.Add3( _
        PROPERTY_NAME, _
        swCustomInfoText, _
        propValue, _
        swCustomPropertyReplaceValue _
    )

    swModel.SetSaveFlag

    UpdateMeasurementProperty = True
    Exit Function

ErrorHandler:
    UpdateMeasurementProperty = False

End Function

Function GetMeasurementSensorValue( _
    ByVal swModel As SldWorks.ModelDoc2, _
    ByVal sensorName As String, _
    ByRef sensorValue As Double) As Boolean

    On Error GoTo ErrorHandler

    Dim swFeat As SldWorks.Feature
    Set swFeat = swModel.FeatureByName(sensorName)

    If swFeat Is Nothing Then
        GetMeasurementSensorValue = False
        Exit Function
    End If
    'Here we check that the Sensor is received by the name of the Feature
    Debug.Print swFeat.GetTypeName2 & " - " & swFeat.GetTypeName & " - " & swFeat.Name

    Dim swSensor As SldWorks.Sensor
    Set swSensor = swFeat.GetSpecificFeature2
    
    If swSensor Is Nothing Then
        GetMeasurementSensorValue = False
        Exit Function
    End If
    'We are trying to check the sensor type, but we get the value 4.
    Select Case swSensor.SensorType
        Case swSensorSimulation
            Debug.Print "Sensor type = Simulation"
        Case swSensorMassProperty
            Debug.Print "Sensor type = Mass Property"
        Case swSensorDimension
            Debug.Print "Sensor type = Measurement (dimension)"
        Case swSensorInterfaceDetection
            Debug.Print "Sensor type = Interference Detection"
    End Select
    
    swSensor.UpdateSensor
    ' Here we can get the Sensor Feature data as an Object but not as SldWorks.DimensionSensorData
    Dim sensorData As Object '  As SldWorks.DimensionSensorData
    Set sensorData = swSensor.GetSensorFeatureData

    If sensorData Is Nothing Then
        GetMeasurementSensorValue = False
        Exit Function
    End If
    

    Dim swDimSensorData As SldWorks.DimensionSensorData
    '<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<  ERRROOOOORRRR
    Stop 'There will be an error here because the Object type is different.
    Set swDimSensorData = sensorData

    sensorValue = swDimSensorData.sensorValue

    GetMeasurementSensorValue = True
    Exit Function

ErrorHandler:
    GetMeasurementSensorValue = False

End Function

Function FormatNumberInvariant(ByVal value As Double, ByVal decimals As Integer) As String

    Dim txt As String

    txt = Format$(value, "0." & String$(decimals, "0"))
    txt = Replace(txt, ",", ".")

    FormatNumberInvariant = txt

End Function

[mihkov]

I’ll add that this mysterious object, for example, has a Name property. So, it does implement some kind of interaction interface, or maybe it’s an inherited property—who knows.

Debug.Print "Name = "; CallByName(sensorData, "Name", VbGet)

Name = Measurement1

[TRKemp]

Thank you for your post, that’s alot of great information. The plot thickens.

I can only assume, that others whom have tried to utilize sensors for the same purpose, have come to the same conclusion.

I would be curious if you guys think sending this detailed explanation from @mihkov to my VAR is a good idea, for an explanation from SW as to why this particular function seems to break from the same logic used within the rest of the software.

[mihkov]

I don’t have access to official support at the moment, so please, feel free to use this information however you see fit. If sharing this with your VAR helps get some real answers, be my guest.

Personally, I suspect there’s a practical (or perhaps slightly lazy) reason why we can’t properly use these sensors in equations or properties. My guess is that they didn’t want to deal with the ‘ripple effect’ of error handling. If a measured geometric entity disappears and the sensor goes into an error state, it could easily break the entire equation solver or custom property tree. It seems they chose to keep it as a ‘read-only’ visual tool rather than building a robust system to handle broken references.

It feels like an age-old issue that the community has simply resigned itself to over the years.

[TRKemp]

That makes alot of sense. All good points.

I don’t utilize my VAR very often since I’ve always had better success at finding solutions to problems on the forum, but this may be a case where it’s just to get an explanation from SW, rather than a solution. I would wager a bet that what you’ve just mentioned is likely the same line of thought they’ve adopted.

I know there are other’s in here that might be able to review your info and contribute some thoughts / opinions, so you’ve provided a great starting point for further discussion.

[JimSculley]

There is an existing SPR (633058) requesting the ability to link sensors to variables/equations:

DS Support Knowledge Base

[TRKemp]

Thanks Jim. That was 6 years ago, so I am not feeling very optimistic.

[jcapriotti]

They need to do it like NX. HAve an option to add the sensor measurement to the feature tree and you can reorder it where it needs to be. Then expose the dimension so it can be selected by equations, custom properties, etc.

[TRKemp]

One can hope!

[mihkov]

I often think about how SolidWorks would look if it were designed today from scratch, without decades of legacy features, compatibility requirements, old APIs, macros, PDM workflows, and historical design decisions.

One area where this is especially noticeable is custom properties, equations, configurations, cut-list properties, global variables, design tables, and BOM-related data. All these systems are useful, but they feel like separate worlds that were added at different times. As a result, users often have to build complicated workflows, macros, or add-ins just to make model data behave consistently.

In my opinion, SolidWorks would benefit from a unified Variable Database concept.

Instead of treating custom properties, equations, global variables, configuration-specific properties, and cut-list properties as separate mechanisms, they could all become different scopes of the same system.

For example, variables could exist at different levels:

Document-level variables
Configuration-level variables
Body / Cut-list variables
Component instance variables
Assembly context variables
Calculated variables
System variables

Each variable would have a clear scope, type, value, and possibly a formula. Something like:

Name | Scope | Type | Value | Formula | Resolved Value | Status

For example:

DESCRIPTION | Configuration | Text | Bracket | - | Bracket | OK
THICKNESS   | Body          | Length | 4 mm | - | 4 mm | OK
AREA        | Body          | Area | - | SurfaceArea(Body) | 0.85 m² | OK
NUMBER      | Configuration | Text | - | DESCRIPTION + "-" + ConfigName | Bracket-01 | OK

This would be much more powerful than the current system, where custom properties are often just text fields, equations are handled separately, and cut-list properties have their own logic.

In such a system, an equation would simply be a calculated variable. There would be no need to separate “Equations” and “Custom Properties” as fundamentally different things. A numeric variable, a text variable, or a calculated value would all belong to the same database.
For example:

Length = 1200 mm
Width = 500 mm
Area = Length * Width
Designation = DESCRIPTION + "-" + ConfigName

One important improvement would be proper support for string functions . Today, forming property values like part numbers, descriptions, designations, BOM names, or configuration names often requires API macros, design tables, or complicated $PRP references. A modern variable system should allow formulas such as:

PartNumber = Prefix + "-" + Format(Number, "000")
DisplayName = Trim(DESCRIPTION + " " + VariantName)
Designation = IfNull(DESCRIPTION, "NO_DESCRIPTION") + "-" + ConfigName

Functions like these would be extremely useful:

Left(); Right(); Mid() .....

Another key feature should be a proper distinction between different value states. Currently, a missing property, an empty property, a failed expression, and an unresolved reference can sometimes feel too similar from the user’s point of view.
A modern system should clearly distinguish:

null          - value does not exist
""            - value exists but is empty
Error         - formula failed
Undefined     - referenced variable was not found

Then safe fallback expressions could be used:

Variable2 = Variable1 ?? "Default value"
Variable2 = Try(Variable1, "Default value")
Variable2 = If(IsNull(Variable1), "Default value", Variable1)

Another important concept is addressing variables by their full context path. For example:

Assembly1@Component1<2>@Configuration1@Body3@Variable55

This kind of path would make it clear whether the value comes from the document, configuration, body, cut list, component instance, or assembly context. Today, this is often one of the most confusing parts of working with properties through the API.

The system should also have strict and visible rules for priority and inheritance. For example:

Body variable
Configuration variable
Document variable
Assembly context variable
Global/default variable

Without clear priority rules, the system could become even more confusing than the current one. But with a good interface, the user could always see where the final resolved value came from.

Another major improvement would be stronger typing. Instead of only treating everything as text or number, variables could have types such as:

Text; Number; Boolean; Enum; Material; Date; Reference ....

This would prevent many common mistakes. For example, a thickness should not just be the string "4" . It should be a real length value, such as 4 mm . A surface area should be stored as an area. A mass should be stored as a mass. This would make BOMs, drawings, cut lists, and API automation much more reliable.

In practice, this could become a central Variable Manager in SolidWorks, replacing or unifying several existing tools:

Custom Properties
Configuration Properties
Cut List Properties
Equations
Global Variables
Design Table parameters
BOM variables

Of course, I understand why SolidWorks does not work this way today. It has a long history and must support old files, macros, add-ins, PDM systems, templates, drawings, and company workflows. A radical redesign would break too many things.

But conceptually, I think this is the direction CAD systems should move toward.

Custom properties should not be just text fields attached to files. They should be typed, calculated variables with scope, dependencies, inheritance, and safe error handling.

In short:
SolidWorks needs not only Custom Properties, but a real model-wide Variable Database.

Such a system would make CAD data cleaner, reduce the need for macros, make BOM automation easier, simplify configuration management, and give users much more control over engineering metadata.

I just hope Dassault Systèmes doesn’t decide to come after me and my family for saying this — my apologies in advance

[TRKemp]

You can tell there is alot of experience behind those ideas and I can very much appreciate the time and energy that you’ve spent compiling them. Clearly you have a passion for this; its exactly the type of feedback Dassault should be welcoming, rather than dismissing.

Its also a great example of why this forum is such an important resource.

On a much less thought provoking note: I’ve received a reply back from support.

• They agree its something that should in the software
• They found the same enhancement request
• They think I should submit an enhancement request
• No support for writing API code

[SPerman]

My gut feeling is this will never happen. Similar to using global variables in all dialogs. As I understand it, they were supposed to keep adding that functionality over time, but there are still many places that doesn’t work, and progress on that concept seems to have stalled.

It is obvious to me that Desktop is the red headed step child, and while it is getting new features, they don’t seem to care about finishing (and fully integrating) the features of the last 20 years.