nasa/fprime

fpp-to-xml unable to compile telemetry limits with boolean types

Opened this issue · 3 comments

kubiak-jpl commented
F´ Version v3.4.3
Affected Component fpp-to-xml

Problem Description

Unable to use telemetry limits with boolean types. The fpp-to-xml script is unable to generate an XML file. Here is an example built from the Ref deployment

Version 1:

telemetry test2: bool id 7 \
low { \
  orange false \
}

fpp-to-xml
/Users/kubiak/Documents/fprime/Ref/SignalGen/Telemetry.fppi:26.10
  orange false \
         ^
  included at /Users/kubiak/Documents/fprime/Ref/SignalGen/SignalGen.fpp:69.13
error: cannot convert bool to a numeric type

Version 2:

telemetry test2: bool id 7 \
low { \
  orange 0 \
}

fpp-to-xml
/Users/kubiak/Documents/fprime/Ref/SignalGen/Telemetry.fppi:26.10
  orange 0 \
         ^
  included at /Users/kubiak/Documents/fprime/Ref/SignalGen/SignalGen.fpp:69.13
error: cannot convert Integer to bool

Context / Environment

Execute fprime-util version-check and share the output.

Operating System: Darwin
CPU Architecture: arm64
Platform: macOS-14.4.1-arm64-arm-64bit
Python version: 3.12.2
CMake version: 3.27.4
Pip version: 24.0
[WARNING] Cannot import 'pkg_resources'. Will not check tool versions.

Also observed on

Operating System: Linux
CPU Architecture: aarch64
Platform: Linux-6.5.0-26-generic-aarch64-with-glibc2.35
Python version: 3.10.12
CMake version: 3.22.1
Pip version: 22.0.2
Pip packages:
    fprime-tools==3.4.4
    fprime-gds==3.4.3
    fprime-fpp-*==2.1.0a5

How to Reproduce

  1. Add the following line to SignalGen.fpp
telemetry test2: bool id 7 \
low { \
  orange false \
}

fpp-to-xml
/Users/kubiak/Documents/fprime/Ref/SignalGen/Telemetry.fppi:26.10
  orange false \
         ^
  included at /Users/kubiak/Documents/fprime/Ref/SignalGen/SignalGen.fpp:69.13
error: cannot convert bool to a numeric type
  1. Rebuild the Ref deployment. Observe the following error

Expected Behavior

Expect to be able to use telemetry limits with Boolean telemetry types

bocchino commented

This isn't a bug; it's in the language specification. Limits are for numeric types only. In particular, it is not clear what a low or high limit should mean for a Boolean value. Boolean values are not ordered. Consider switching the output to a numeric type if you want to define limits for it.

kubiak-jpl commented

Maybe this a feature request then. I do think there would be value in telemetry limits for non-numeric types. I don't think of these as numeric limits so much as warnings to the GDS user that a telemetry value requires attention. In that sense it would make sense for boolean and enumeration channels to have channel limits.

bocchino commented

Sure, we could add the feature of specifying red, orange, and yellow values (as opposed to limits) for any telemetry channel type. Can you open a discussion topic on this, to get input from others? Then we can close this issue.