Support MIN/MAX in limits

[shonigmann]

What is the use case or problem this feature would solve?

Our team has noticed that the limit set notation is relatively rigid. e.g. to add a limit set for a telemetry point:

• there must be a DEFAULT limit definition, before a limit set can be defined
  • at least as of our testing in OpenC3 6.4.2, the DEFAULT limit must come first in the telemetry definition, e.g. the following is rejected:

        LIMITS SET_A 1 ENABLED -10 -5 10 20
        LIMITS DEFAULT 1 ENABLED -10 -5 10 20
    

    with:

    Error: DEFAULT limits set must be defined for XXX YYY ZZZ before setting limits set SET_A
    

  • we haven't yet tested in OpenC3 v7
• require all 4 red and yellow high and low states

What we haven't figured out how to do is:

• one-sided limits (e.g. only yellow_high / red_high, leaving the low side unbounded)
• no-op DEFAULT limits (e.g. only apply limits when a set is loaded)

Are either of the above possible?

Describe the solution you'd like

• OpenC3 supports 1-sided limits (e.g. by supporting MIN/MAX like in command parameter constraints or otherwise make red/yellow limits optional
• OpenC3 supports optional or no-op DEFAULT limits

Additional context

No response

Screenshots

No response

[crawlchat]

Thanks for the detailed issue! Let me address both questions clearly.

📋 Current Behavior & Constraints

1. DEFAULT must come first
This is a known, confirmed behavior — DEFAULT must be the first LIMITS entry for any telemetry item. This was also reported in issue #3402 against v7.1.0, so it still applies in v7.

2. All 4 values are required
The LIMITS keyword requires all 4 boundary values: Red Low, Yellow Low, Yellow High, Red High. There is no current support for one-sided (e.g., high-only) limits in the configuration file syntax.

❓ Are one-sided limits or no-op DEFAULT possible?

One-sided limits — not natively supported in the config file syntax. There is no MIN/MAX equivalent for LIMITS. The only workaround would be to set the low-side values to an extreme value (e.g., -1e300 for a float) to effectively make it unbounded on that side — but this is a hack, not a real solution.

No-op DEFAULT limits — not currently supported. The DEFAULT set is always required and must be defined first, meaning you cannot have limits that are inactive until a specific set is loaded.

🔧 Workaround via `set_limits` scripting API

If you need more dynamic control, the set_limits scripting API does allow you to set limits at runtime for a specific limits set. You could potentially script a workaround where DEFAULT has very wide/permissive values and the active set is switched when needed:

set_limits('TARGET', 'PACKET', 'ITEM', -1e300, -1e300, 100.0, 200.0, limits_set='DEFAULT')

---

These are genuinely good feature requests:

• One-sided limits (high-only or low-only) would be useful for many real-world sensors
• Optional/no-op DEFAULT would allow cleaner configuration when limits only apply to specific operational modes

I'd recommend leaving this open as a feature request for the COSMOS team to consider. Could you also clarify — are you primarily targeting v6 or v7 for this use case? That context may help prioritize the work. 🙏

[shonigmann]

We are ultimately targeting v7, though some teams are still working with v6

[jmthomas]

We've always required a DEFAULT limits set because effectively an item either has limits or it doesn't. There are limits processing steps that occur when an item has limits. I could see logically not having a DEFAULT set and just showing the value as black (no limits) unless a specific set was chosen. Not sure what side effects that would have.

We've basically handled the "no low" or "no high" limits by setting huge values like crawlchat suggested. However, this could be more explicit like having a NONE keyword for low or high. If yellow low/high is NONE then the corresponding red would be NONE. However, I could see setting yellow low/high to a real value and setting red to NONE to only have a yellow limit (no red).