Cannot specify minimum or maximum of signal value

[sebi2k1]

KCD doesn't allow the user to specify a minimum/maximum value which is used to limit the physical value after the conversion (y = mx + b) was applied.

[dschanoeh]

Yes you are right. Nevertheless I don't think this is a problem. When we created the format we didn't find it useful to add this feature. We did something different: You can add labels to a value describing specific values or ranges. This can be used to mark values that shall not be transmitted and it's also possible to define functional labels:

• An integer value has a default value that indicates something wrong --> label that
• Think of fill levels. You can easy label regions where the level is too low, too high and normal

Do you have a specific use case that would make these minimum / maximum values necessary because you can't model it with labels? If it's just because .dbc supports it I wouldn't want to add it ;).

[sebi2k1]

KCD format is quite signal visualiziation centric. Signal processing using the label description is not very easy. Thus I want the feature, basically because I need it in restcan. ;-)

[julietkilo]

First of all, let me say that I like the idea of restcan :-) and reuse of KCD. After checking examples in our CAN database I found the feature request useful. I suggest to add min/max values to the "Value" element of the XML format as shown in examples below:

        <Signal name="OutsideTemp" offset="18" length="12" endianess="little">
          <Notes>Outside temperature.</Notes>
          <Consumer>
            <NodeRef id="12"/>
          </Consumer>
            <Value type="unsigned" slope="0.05" intercept="-40" unit="Cel" min="0" max="100"/>
          <LabelSet>
            <Label name="init" value="0"/>
            <LabelGroup type="error" name="Sensor error" from="4090" to="4095"/>
          </LabelSet>                   
       </Signal>

    <Message id="0xDA7E" name="DateTime" format="extended">
        <Producer>
            <NodeRef id="8"/>
        </Producer>
        <Signal name="Day" offset="0" length="8">
            <Value unit="d" min="1" max="31"/>
        </Signal>
        <Signal name="Month" offset="8" length="8">
            <Value unit="mo" min="1" max="12"/>
        </Signal>
        <Signal name="Year" offset="16" length="8">
            <Notes>Year starts with offset 2000. 2012 would be value 12.</Notes>
            <Value unit="a" min="0" max="100"/>
        </Signal>
        <Signal name="Weekday" offset="24" length="8"/>
        <Signal name="Hour" offset="32" length="8">
            <Value unit="h" min="0" max="23"/>
        </Signal>
        <Signal name="Minute" offset="40" length="8">
            <Value unit="min" min="0" max="59"/>
        </Signal>
        <Signal name="Second" offset="48" length="8">
            <Value unit="s" min="0" max="59"/>
        </Signal>
    </Message>

[sebi2k1]

Thanks. Did I mentioned I can need some help for restcan? ;-)

Back to topic, your proposal is exactly what I meant. I find it essential to declare a valid value range.

[ghost]

Hi.

Just to throw in my 2 cents out of interest. I am actually in favor of a value range (optionally of course), even if it is just a special case of a label/labelgroup.

The initial request was for a value range for the values (after conversion). The proposed solution by julietkilo is for the raw data, isn't it? Maybe to make this clearer, something like rawmin/rawmax as attribute names would be better? Otherwise valmin/valmax or something similar?

Or maybe I am just too easily confused.

nautsch

[julietkilo]

Sorry, to be confusing. The proposed solution are optional min/max for values after conversion by slope/intercept (see example above, line 6). Thus, they are attributes of element, intended for interpretation how to handle the raw data of the element itself. For me should have the same effect as .

I agree that a label or labelgroup can also be used to restrict value range. That was the original idea for using the KCD format. But unfortunately in real life DBC users use both min/max and VAL labels to restrict ranges. Having CANBabel in mind as translator to different CAN formats we need that feature.

[dschanoeh]

Alright I'm ok with that. It seems we really missed a feature. @julietkilo will change the example .kcd and the schema. I will then update both Kayak and CANBabel to support the new attribute.

[dschanoeh]

@julietkilo changed the format (see 6dd0bd02f939f20b732b77286290cc211ceca8fd ) and I just merged the pull request. @sebi2k1 please check if this is all you needed and implement the updated format in your application. I will do the same with Kayak in the following days.

Cheers Jan

[sebi2k1]

Thanks.