Model the alarm limits better

[cnlklink]

          It seems like we could model the alarm limits better better. Something along the lines of:

abstract class AlarmLimit {
    double get nominal;
    double get tolerance;
    double get min_value;
    double get max_value;
}

class AlarmMinMax extends AlarmLimits {
    final double _min;
    final double _max;

    AlarmMinMax(this._min, this._max);

    double get min_value => _min;
    double get max_value => _max;
    double get nominal => (_min + _max) / 2;
    double get tolerance => nominal - _min;
}

class AlarmNomTol extends AlarmLimits {
    final double _nom;
    final double _tol;

    AlarmNomTol(this._nom, this._tol);

    double get min_value => _nom - _tol;
    double get max_value => _nom + _tol;
    double get nominal => _nom;
    double get tolerance => _tol;
}

Originally posted by @rneswold in #54 (comment)

[cnlklink]

I know we discussed this issue a bit in the last status meeting. Someone (was it @beauremus ?) asked if this should be handled by DPM. Seems to me that's the best spot for it. Thoughts?

[rneswold]

If the param page switches between NOM/TOL and MIN/MAX, does it resend the request to DPM? The modeling I proposed above would do the switch in the app and DPM would simply provide the data returned by the device.

I guess the question is: is it useful for DPM to provide the switch? I can't think of scripts or apps (besides param page) that actually care about the alarm limits. They may care that a device is in alarm, but not so much the limits. The param page cares because users may want to better understand the limits by switching between views.

But, then, I've never written an in-depth Python or ACL script. Maybe they do commonly access the limits and like to switch between the types.

[cnlklink]

Actually, what I've implemented so far displays all four values. I figured that the existing parameter page is asking you to toggle between the two because of limited screen space. But we can easily pack four values onto the page. And so, there's no switch to be done really.

What's stored in the database - nom and tolerance? And so min/max are calculated?

[beauremus]

I believe the white fields, highlighted in red, are the FE config and the cyan field, highlighted in pink, is the device DB config for what the user wants to see.

[rneswold]

But we can easily pack four values onto the page.

Something like:

    Max: 100.0
    Nom:  75.0   Tol: +/- 25.0
    Min:  50.0

[rneswold]

I'm going to tuck this thought at the end of this issue:

A parameter row could simply show the most general, useful stuff (name, description, setting, reading, status) and a details icon. Clicking the icon could animate the row to expand vertically to show details like basic status bits and alarm limits.