Unit mismatch in Expression

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
edwilliams16
Posts: 249
Joined: Thu Sep 24, 2020 10:31 pm
Location: Hawaii

Unit mismatch in Expression

Postby edwilliams16 » Tue Apr 06, 2021 6:16 pm

OS: macOS High Sierra (10.13)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24276 (Git)
Build type: Release
Branch: (HEAD detached at 0.19.1)
Hash: a88db11e0a908f6e38f92bfc5187b13ebe470438
Python version: 3.8.8
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.4.0
Locale: C/Default (C)


I have two cubes (primitives from Mesh Design) and am attempting to tie them together with an Expression.

Code: Select all

Cube.Height + Cube.Placement.Base.z
This fails with a unit mismatch. But it shouldn't! Both quantities are mm.

The same expression works within a Part Design primitive Box.
User avatar
Roy_043
Posts: 2735
Joined: Thu Dec 27, 2018 12:28 pm

Re: Unit mismatch in Expression

Postby Roy_043 » Tue Apr 06, 2021 6:34 pm

edwilliams16
Posts: 249
Joined: Thu Sep 24, 2020 10:31 pm
Location: Hawaii

Re: Unit mismatch in Expression

Postby edwilliams16 » Tue Apr 06, 2021 7:30 pm

I saw no discussion of a work-around, but I found one

Code: Select all

Cube.Placement.Base.z / 1mm + Cube.Height
The result shows in mm in the editor and works correctly. This of course makes no sense, since the units of Cube.Placement.Base.z certainly aren't mm^2. I doubt this works with imperial units, but that's another problem.

Before the OP, I had tried

Code: Select all

Cube.Placement.Base.z  + Cube.Height*1mm
which makes a bit more sense, but that didn't work.
User avatar
Roy_043
Posts: 2735
Joined: Thu Dec 27, 2018 12:28 pm

Re: Unit mismatch in Expression

Postby Roy_043 » Tue Apr 06, 2021 7:51 pm

Which of the 2 solutions works depends on the target property. The 1st will work for the Height of another mesh cube (which is unit-less), the 2nd will work for the Z coordinate (which does have units) for example.
edwilliams16
Posts: 249
Joined: Thu Sep 24, 2020 10:31 pm
Location: Hawaii

Re: Unit mismatch in Expression

Postby edwilliams16 » Tue Apr 06, 2021 8:09 pm

Roy_043 wrote:
Tue Apr 06, 2021 7:51 pm
Which of the 2 solutions works depends on the target property. The 1st will work for the Height of another mesh cube (which is unit-less), the 2nd will work for the Z coordinate (which does have units) for example.
That would make sense, but isn't true.
For setting the height or the z-coordinate without reported errors, both require the

Code: Select all

Cube.Placement.Base.z / 1mm + Cube.Length
form.
It's a confusing mess. The code has no consistent view of the units here.
Attachments
unitmismatch.FCStd
(223.53 KiB) Downloaded 2 times
User avatar
Roy_043
Posts: 2735
Joined: Thu Dec 27, 2018 12:28 pm

Re: Unit mismatch in Expression

Postby Roy_043 » Wed Apr 07, 2021 8:19 am

For the Z coordinate both solutions work here:

Code: Select all

OS: Windows 8.1 (6.3)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24219 (Git)
Build type: Release
Branch: master
Hash: 8c26baebab320b8c1c3279bc8eb34a1eb6c7a363
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Dutch/Netherlands (nl_NL)

Code: Select all

OS: Windows 8.1 Version 6.3 (Build 9600)
Word size of FreeCAD: 64-bit
Version: 0.20.24587 (Git)
Build type: Release
Branch: master
Hash: 1f62d4666102d8efd4d8f3ba58a1037456a3bcfb
Python version: 3.8.6+
Qt version: 5.15.1
Coin version: 4.0.1
OCC version: 7.5.0
Locale: Dutch/Netherlands (nl_NL)
chrisb
Posts: 33587
Joined: Tue Mar 17, 2015 9:14 am

Re: Unit mismatch in Expression

Postby chrisb » Wed Apr 07, 2021 8:57 am

If I set the length of a mesh cube I get these results

- set to Cube.Placement.Base.z + Cube.Length is not allowed, with the message of a unit misatch
- set to Cube.Placement.Base.z + Cube.Length * 1mm is accepted, but shows the message "(Warning: unit discarded)"

Setting the Z component of the placement works with Cube.Placement.Base.z + Cube.Length * 1mm.

This means that the placement has units, while the dimensions have not. As far as I know at least the stl format doesn't have units either.

OS: macOS 10.16
Word size of FreeCAD: 64-bit
Version: 0.20.24612 (Git)
Build type: Release
Branch: master
Hash: f525904c1be10a0f55aa3502151c2c55e5054259
Python version: 3.9.2
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.1
Locale: C/Default (C)
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
wmayer
Site Admin
Posts: 17264
Joined: Thu Feb 19, 2009 10:32 am

Re: Unit mismatch in Expression

Postby wmayer » Wed Apr 07, 2021 10:47 am

This fails with a unit mismatch. But it shouldn't! Both quantities are mm.
No, they aren't. All mesh primitives still use raw float properties and not quantities. You can easily see this fact in the property editor when you create e.g. a mesh cube. The values of Length, Width and Height are displayed as 10.00 and not 10.00 mm.
which makes a bit more sense, but that didn't work.
It works! When you set the expression for the Length property

Code: Select all

Cube.Placement.Base.z  + Cube.Height
then this error is shown Quantity::operator +(): Unit mismatch in plus operation
and the OK button is greyed out.

When you change the expression to

Code: Select all

Cube.Placement.Base.z  + Cube.Height*1mm
then a warning is shown: 10.00mm (Warning: unit discarded)
but the OK button is active in order to accept it. The warning makes perfectly sense because the expression has a unit but the Length property is dimensionless.
It's a confusing mess. The code has no consistent view of the units here.
The code works correctly. The point is that the code for the mesh primitives is very old (> 15 years). So it was written long before we implemented the unit framework but we never moved the mesh primitives from using raw float properties to quantity properties.
edwilliams16
Posts: 249
Joined: Thu Sep 24, 2020 10:31 pm
Location: Hawaii

Re: Unit mismatch in Expression

Postby edwilliams16 » Wed Apr 07, 2021 6:06 pm

Snip macro screenshot-59b6dc.png
Snip macro screenshot-59b6dc.png (11.19 KiB) Viewed 101 times
OK. I understand things now. What threw me was the above which shows a dimensionless quantity as mm. Looking more carefully, when you actually enter the quantity it shows as "185", then on closing the dialog it shows as 185 mm. This is obviously trying to be helpful, defaulting the dimensionless quantity to the default unit, but it did confuse me.
wmayer
Site Admin
Posts: 17264
Joined: Thu Feb 19, 2009 10:32 am

Re: Unit mismatch in Expression

Postby wmayer » Thu Apr 08, 2021 12:17 pm

OK. I understand things now.
Exactly. The property type PropertyPlacement has a Base::Placement as data type and that consists of a Base::Rotation (that is implemented as a quaternion) and a Base::Vector3d. The class components of the Rotation and Vector3d are all doubles.

So, actually all values of a PropertyPlacement are dimensionless but for the expression engine (see PropertyPlacement::getPathValue) and the property editor (see PropertyPlacementItem) a dimension is shown to the user.