I've played around with this a little bit trying to understand it better. Here's what I think I've learned.
A velocity is a derived unit from two base units, time and distance. So grepping for 'mm/s' probably wouldn't find anything.
A velocity unit is always going to be converted to and stored in FreeCAD base units (mm/s). But the user can input in any format and it'll be converted. So '25 in/min' becomes 10.5833 mm/s'
There's no FreeCAD preference for storing a derived unit. User can choose metric or imperial but not how velocity will be expressed. In fact, there's no preference for time units at all. So velocity always appears in mm/s.
The desired output is achieved with
Code: Select all
>>> cutspeed = FreeCAD.Units.Quantity('25 in/min')
>>> cutspeed
10.5833 mm/s
>>> displayspeed = cutspeed.getValueAs('in/min')
>>> displayspeed
25
I think the postprocessors need a property for the desired format. The property would store a string like 'in/min'
It would assume that the value it's processing is always in the FreeCAD base unit for velocity (mm/s) and act accordingly.
To summarize if I understand correctly.
Unit handling internally works fine.
Unit output through the post could be made to work fine quite easily.
Displaying the units on the screen in the same format the user entered is a problem because the current unit schemas don't do derived units/time.
In my opinion, solving the last one would solve everything and make the Path velocity much more flexible and maybe we shouldn't purge the App::PropertySpeed at all.