Ordering of CAN signal ports, when CAN Pack/Unpack is using "CANdb specified signals"

Regardless of the order in the CANdb file or the bit order assigned to signals, CAN unpack will show its outputs in alphabetical order. This causes a horrible listing of R1, R11, R12, R2, R3... and so on, which makes the onward processing links untidy and less readable. Worse, the case where the name is changed, causing the order to be altered, the output signals are all incorrectly connected.

Is there a way of forcing the order they are displayed, either by start bit number or the order they appear in the file? (Or by any other meta data attribute such as comment)

Answer 1

[Anshuman]

In Simulink, when using the CAN Unpack block to decode CAN messages based on a CAN database (CANdb) file, the signals are typically listed alphabetically in the block's output. As of R2023b, there is no built-in feature within the CAN Unpack block to customize the order of the displayed signals based on start bit number, order in the file, or any other metadata attribute.

However, here are some workarounds that you could consider:

• After unpacking, manually reorder the signals using Selector blocks, Goto/From blocks, or Bus Creator blocks.
• Write a custom MATLAB function or a Simulink Function block that decodes the CAN message based on the signal definitions in the CANdb file. You can then order the outputs of this function as desired.
• Preprocess the CANdb file outside of Simulink to reorder the signals as needed before importing it into the CAN Unpack block.

[Graham Cotgreave]

Thank you - I think the first workround has the most merit, an intermediate block.

Whilst the 2nd would give you exactly what is required, it does seem to defeat the object of using supplied Simulink functionality. I have not tested the third, option, but as noted the order in the file does not seem to make any difference, as Simulink insists on reordering alphabetically. The worst case is not realising that altering a signal name in a CANdb file (not its position) can then render the model incorrect as it could now connect to a different output line! I would think that bit position ordering would be a logical feature to add to a future release, it is likley to be the most "stable" in a CANdb file and a change request changing a bit position (rather than simply a label spelling) is more likely to trigger full trace check of the signal in a model.