Maximum identifier length '31' does not provide sufficient space to make symbol names unique

57 views (last 30 days)
I am getting the following warning when generating code from my model:
  • Insufficient space for computing symbol names in model 'controller'. The maximum identifier length '31' does not provide sufficient space to make symbol names unique using the symbol format string in 'Global variables'. This is required when using model reference. Consider increasing the maximum identifier length. To eliminate this message enter the command set_param('controller', 'ModelReferenceSymbolNameMessage', 'none') at the MATLAB prompt
I have a similar warning for 'Global types' and 'Subsystem methods'. I believe some names are too long and it does not fit in identifier length '31'.
I do not want to increase the maxmum identifier length because it is required in certain standards. So I want to find and identify which names are too long. How can I find those?
Bogdan Bodnarescu
Bogdan Bodnarescu on 19 Apr 2022
Hello, like I said I am using CAN messages.
Is there any solution for my problem, outside from making the identifier names longer?

Sign in to comment.

Answers (2)

Bogdan Bodnarescu
Bogdan Bodnarescu on 12 Apr 2022
Omg this was exactly the name. Yes I am using some CAN libraries

Walter Roberson
Walter Roberson on 19 Apr 2022
@Bogdan Bodnarescu
This is not something that I have had to deal with.
I get the impression that you are using model reference to the CAN blocks in two different places in your model, and that CAN blocks have global variables. In such a case, in order to differentiate between the global variables for the different locations, Simulink would try to qualify the variable name with information about where in the model it was occurring -- for example it might take
/Project7/Control Loop/Subsystem1/CAN_Receive/Input::IO::CAN::ReadMsg::CleanupRTR
/Project7/Control Loop/Subsystem1/CAN_Receive/Input::IO::CAN::ReadMsg::MsgLength
/Project7/Control Loop2/Subsystem1/CAN_Receive/Input::IO::CAN::ReadMsg::CleanupRTR
/Project7/Control Loop2/Subsystem1/CAN_Receive/Input::IO::CAN::ReadMsg::MsgLength
and try to create variables
and then it would have a problem that these were not unique with the first 31 characters.
If that is what is happening, then you could proceed in a small number of different ways:
  • Increase the identifier length. MISRA warning about this are warnings that there might come a day when you want to port the code to a device but be unable to because the compilers for the device only support 31 characters (the minimum for C or C++ compliance) -- that the compiler might not even notice that the names are different. This is a hypothetical long-term problem but depending on your needs and business plans it might turn out to be irrelevant completely, or might be something that could be postponed for years until it becomes and actual need; or
  • copy the CAN blocks and change the variable names in the copy; or
  • turn off model referencing, so that these model-referencing messages go away (might cause different problems); or
  • rework your model so that CAN blocks are only used in one place. This could potentially be workable if what you are modeling is a system with a single central point that is processing all the CAN block messages -- but it might not be workable at all if you are modeling a system with multiple consumers of CAN block messages. For example do you have a single central location that is processing a number of messages and making decisions about spin rates for all four tires for 4WD? or do you have one processor for each tire each receiving much the same stream of messages but each making independent decisions about one tire for 4WD ? (Increase the number of drive wheels because it is a tractor or semi trailor, and ask yourself what happens if you have a single processor making decisions and that processor fails or is damaged... having multiple systems making semi-independent decisions might be important in some cases.)
Walter Roberson
Walter Roberson on 19 Apr 2022
Class hierarchies such as Input::IO::CAN::ReadMsg::CleanupRTR appear to be having the :: scope resolution operator transformed into _ characters, so when you see _ in the error messages, the first thing to try is substituting :: for each _ . Not fool-proof if the name itself happens to have _ in it, but should provide a starting place to look.

Sign in to comment.


Find more on Deployment, Integration, and Supported Hardware in Help Center and File Exchange




Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by