Question on parameter IDs

[Pete9008]

Just looking at adding another parameter and noticed the following (taken from param_prj.h on github master):

Code: Select all

#define VALUE_BLOCK1 \
    VALUE_ENTRY(version,     VERSTR,  2039 ) \
    VALUE_ENTRY(hwver,       HWREVS,  2036 ) \
    VALUE_ENTRY(opmode,      OPMODES, 2000 ) \
    VALUE_ENTRY(lasterr,     errorListString,  2038 ) \
    VALUE_ENTRY(status,      STATUS,  2044 ) \
    VALUE_ENTRY(udc,         "V",     2001 ) \
    VALUE_ENTRY(idc,         "A",     2002 ) \
    VALUE_ENTRY(il1,         "A",     2003 ) \
    VALUE_ENTRY(il2,         "A",     2004 )

and

Code: Select all

#define VALUES_FOC \
    VALUE_ENTRY(id,      "A",     2003 ) \
    VALUE_ENTRY(iq,      "A",     2004 ) \
    VALUE_ENTRY(ifw,     "A",     2048 ) \
    VALUE_ENTRY(ud,      "dig",   2046 ) \
    VALUE_ENTRY(uq,      "dig",   2047 ) \

This looks like il1 and il2 are sharing the same parameter IDs as id and iq.

Does this matter? If so what would the effect be?

[johu]

Oh! It means you can't properly Can-map them...
would be a good idea to make them unique

[Pete9008]

Would it affect reading il1 or il2 via the Param::Get(Param::il1) function in foc code?

The binary logging was using a parameter read on them and I wasn't convinced they were reading out right. The problem seems to have gone away now they have unique IDs but then I've changed other things too.

Edit - don't think so, it's the order in the param_prj.h file that determines the order of parameters in the internal arrays so the ID shouldn't affect this at all.

[davefiddes]

That's a good spot. Should have been able to pick them up with openinverter_can_tool if I'd tested it more thoroughly.

I have a cunning plan for how to detect this error automatically at compile time. Look for a libopeninv PR later.