Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom properties and default value association #93

Open
Adhara3 opened this issue Sep 20, 2024 · 5 comments
Open

Custom properties and default value association #93

Adhara3 opened this issue Sep 20, 2024 · 5 comments
Labels
public API This request involves user API question Further information is requested

Comments

@Adhara3
Copy link
Collaborator

Adhara3 commented Sep 20, 2024

Hello,

I have a question regarding .CustomProperties property. From what I can tell, it is meant to store custom properties individually for a message/signal/node based on names/IDs, but when printing out these values, for example: foreach (var message in dbc.Messages) { foreach (var kvp in message.CustomProperties) { var key = kvp.Key; Console.WriteLine(key); } Console.WriteLine(string.Empty); }, I would get all of the attribute names existent in the dbc file for each message, repeatedly. It does not appear that the custom properties they store are unique to them, but just generally present in the dbc. I have checked the dbc file I am parsing, and it does not have all of these properties assigned to every message. The same problem appears with signals and nodes.

I am trying to avoid opening a new issue on this because it might just be my misunderstanding. Could somebody explain please? Thank you in advance

Originally posted by @sToman967 in #91 (comment)

@Adhara3
Copy link
Collaborator Author

Adhara3 commented Sep 20, 2024

Originally written by @Whitehouse112

Hi,
I think it all depends on how this sentences (from documentation) are interpreted:

"User defined attributes are a means to extend the object properties of the DBC
file. These additional attributes have to be defined using an attribute definition with
an attribute default value. For each object having a value defined for the attribute
an attribute value entry has to be defined. If no attribute value entry is defined for
an object the value of the object's attribute is the attribute's default.
"

In particular:
"If no attribute value entry is defined for an object the value of the object's attribute is the attribute's default."_"

If a specific obejct could store a unique custom property this means we should have a DBC-Keyword that allows to assign a custom attribute definition to a specific object, but looking at BA_DEF_ and BA_ sintaxes:

  • BA_DEF defines a new custom property. It's only a definition, which means you have to assign a name, a data type and a generic target object type (Node, Messages, Signals, EnvVar)
  • BA_ is intended to assign to a specific object (e.g. Message with ID x) a specific custom property value (potentially the same value of the default one but I assume is intended to specify a different one, otherwise what is the purpose of the BA_DEF_DEF_ keyword?). Moreover the custom property value is mandatory.

So there is no a DBC-keyword that allows a specific object-attribute linking. I mean, the documentation is not clear about this points, these are my thoughts and reasoning about that but it's my own interpretation.

@Adhara3
Copy link
Collaborator Author

Adhara3 commented Sep 20, 2024

So basically

BA_DEF_ SG_  "SPN" INT 0 524287;
BA_DEF_DEF_  "SPN" 100;
BA_ "SPN" SG_ 2364540158 EngineSpeed 190;

is interpreted the following way:

  • A property called SPN is defined for signals. The type is INT and the acceptable value range is 0 - 524287
  • The default value for SPN is 100.
  • All signals in the dbc inherit SPN with value 100 (default)
  • Signal EngineSpeed form message 2364540158 overwrites the SPN value with 190

This looks fine and coherent to me.
We could think of adding a property to indicate if the property was inherited or explicitly set by a specific object, i.e. all signals will have Inherited except EngineSpeed above that will have Set.

See also #43

Please note that the underlying implementation on how to propagate properties to items is going to change in version 2. No change in behaviour, just implementation detail.

Cheers
A

@Adhara3 Adhara3 added question Further information is requested public API This request involves user API labels Sep 20, 2024
@sToman967
Copy link

Hi,

okay I understand. Thank you for taking the time to explain, appreciate it.

@Adhara3
Copy link
Collaborator Author

Adhara3 commented Sep 21, 2024

Implémentation wise, the current one is a bit messy especially the FillWith* part when building the DBC.
It became apparent during last refactoring that this is error prone. So the idea for upcoming releases is to do as follows:

  • While parsing the definitions are stored in one indexed or multiple containers per type (message, node, signal, etc). Almost as it is today
  • Each object (message, node, signal, etc) will be built with a full copy of the stored definitions
  • Each object will contain a separate list of properties with specific explicit values

The reading process will then be something like (psudocode)

// Imagine we are in a message
foreach(var globalProperty in m_globalProperties[Object type.Message])
{
  if(m_explicitProperties.Contains(globalProperty))
  {
    // The explicit wins, return it
  }
  else
  {
    // Return the global one with the default value
  }
}

This should help understand what's going on, be less error prone and be more efficient

@sToman967
Copy link

Looks good. Will be looking forward to the updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
public API This request involves user API question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants