CANdb++ compliant handling of long names (> 32 characters)

[Adhara3]

Very low priority, food for thoughts.

Long names support and handling

As per spec

DBC-identifiers used in DBC files may have a length of up to 32 characters

Old softwares can truncate names.
The CANdb++ workaround, as already done for other special attributes

To ensure the compatibility the CANdb++ editor always stores C-identifiers for object names with a maximum length
of 32 characters and stores the long object names in user defined attributes. The following attributes are used to store
names of network nodes, messages, signals, and environment variables longer than 32 characters: "SystemNodeLongSymbol", "SystemMessageLongSymbol", "SystemSignalLongSymbol", and "SystemEnvVarLongSymbol".

At the moment we read this parameters but

• they do not override names
• we do not check names' length

This may be fine now, it may become more of an issue if we allow writing/saving

Other special names

GenMsgCycleTime

Contains the cycle time of the message or the relation node-Tx message. With the default settings in CANdb++
("PropsFromUserAttrs=1" and "AttrMsgCycleTime=GenMsgCycleTime" in CANdb.ini) this value is mapped to
the system attribute cycle time. In the default setting, therefore, the system attribute cycle time of a message
(e.g. on the "Message - Definition" page) cannot be processed directly; instead, it is determined via the userdefined attribute.

GenMsgSendType

Describes the transmitter type of the message or the relation node-Tx message. The available values are user or
OEM-specific. With the default settings in CANdb++ ("PropsFromUserAttrs=1" and "AttrMsgSendType=GenMsgSendType" in CANdb.ini) this value is mapped to the system attribute transmitter type (Tx
method). In the default setting, therefore, the system attribute transmitter type of a message (e.g. on the "Message - Definition" page) cannot be processed directly; instead, it is determined via the user-defined attribute.

GenSigInactiveValue

Describes the value of a signal for which the signal is in the inactive state. Signals that are sent with the transmitter type (GenSigSendType) 'IfActive' are sent as soon as the signal assumes a value not equal to the inactive value. Signals that are sent with the transmitter type 'IfActiveWithRepetion' are normally sent cyclically.
However, if the signal value assumes the inactive state, the signal must not be sent.

GenSigSendType

The GenSigSendType attribute specifies the send type of a signal.

GenSigStartValue

Describes the start value or initial value of a signal.

NmStationAddress

A node that uses the OSEK NM (network management) must have a NM-ID that is unambiguous on the network
(within a vehicle, the NM-ID does not have to be unambiguous). This NM-ID is managed in the attribute NMStationAdress. In the CANdb++ default setting("PropsFromUserAttrs=1" and "AttrBusType=NMStationAddress" in
CANdb.ini), this value is mapped to the system attribute 'address' of a node.

Network attributes ProtoclType and BusType

Are used to eventually allow advanced multiplexing in CANdb++

Currently extended multiplexing is limited to…

• J1939/NMEA2000/ISO11783 DBC databases (network attribute ProtocolType must contain
  the value ‘J1939’, ‘NMEA2000’ or ‘ISO11783’)
• CANopen DBC databases (network attribute ProtocolType must contain the value
  ‘CANopen’)
• Aerospace DBC databases (network attribute ProtocolType must contain the value
  ‘Aerospace’)
• Ethernet DBC databases (network attribute BusType must contain the value ‘Ethernet’).

[Uight]

while searching some stuff i found this: https://doku.pub/documents/dbc-file-format-documentation-z06oj144jy0x
seemingly a newer version of the spec (1.05) which has some changes to this topic and most notably defines the extended multiplexing.
The change to the spec doesnt seem to apply here tough as the info is pretty much the same still.

[Adhara3]

Hi,

the doc linked in home page was already the 1.0.5 version (now the link is broken, I checked with wayback)

Cheers
A