Trying to add units and bounds for velocity... am I missing something?

darren_13

So I have this code:

export type VelocityBoundSpec typecheck canBeVelocityBoundSpec;

export predicate canBeVelocityBoundSpec(value)
{
    canBeBoundSpec(value);
    @size(value) == 1;
    for (var entry in value)
        isVelocity(entry.key);
}

/**
 * True for any value with velocity units.
 */
export predicate isVelocity(value)
{
    value is ValueWithUnits;
    value.unit == LENGTH_UNITS/TIME_UNITS;
}

export predicate isVelocity(value, boundSpec is VelocityBoundSpec)
{
    isVelocity(value);
    verifyBounds(value, boundSpec);
}

export const VELOCITY_BOUNDS =
{
    (meter/second) : [0, 100, 299792458]
} as VelocityBoundSpec;

This is based on the std featurescript, but I get all sorts of errors such as:
-Expected parameter id to be defined as a field on value
-Unexpected operator (EQUAL_TO) in feature precondition
-No matching predicate declaration for verifyBounds (I copied and pasted this in to be sure)

I don't know what is different between the std and what I tried but I seem to have messed something up

https://cad.onshape.com/documents/95877be3b17f49277e87a2c3/w/b503830fd20472014beb1221/e/034312f7fdec452704158115

folder Twist Calculator, feature scripts; Twist Calculator, Units

Thanks,
Darren

kevin_o_toole_1

As discussed here, Onshape's dialogs don't yet support inputs with custom units. The workaround is the same as it was then: If you want the dimension to be associated with meters always, you can use an isReal(definition.VelocityInMetersPerSecond) predicate and multiply by meter / second inside the feature.

For the behavior of automatically populating units (replacing a typed "1" with "1 m/s"), the cases of length and angle are the only ones recognized.

There are some complications in implementing generic inputs, e.g. sanely doing the automatic "fixup", determining how they interact with document units, determining how they work on mobile device input keyboard, etc. These aren't unsolvable problems, but they're non-trivial enough that we'd need a strong use case to get it prioritized. If we do implement it, I think the FS would look identical to the FS you have above.

darren_13

@kevin_o_toole_1 thank you, I have gone with the expect it always in meters per second and adding units manually. The use case was so that I could have definition independent of a particular unit (for example, rpm to be a valid input to spin speed, even though rad/s was the SI unit. similarly knots for velocity). Also, I noticed that second was not working I posted in a separate post. Without the ability to input into the script in different units there really isn't a need to include units in the calculation at all. I feel this reduces the power of units. But I'm happy with the work around.

Many thanks,
Darren