Programmatically turning on signal logging

I'm having a problem with programmatically turning on signal logging.

Specifically, I do the following sequence of commands.

• 1.load_system([model name])
• 2.run code that takes a list of signals and finds them in the model and programmatically turns on logging (commands execute without error).
• 3. use find_system to get a list of handles for all logged signals (valid list is returned).
• 4.open_system([model name])
• 5.Navigate to logged signals - logged signals are not highlighted with the traditional icon
• 6. use find_system to get a list of handles for all logged signals - an empty list is returned

I'm not sure what would be causing the above behavior. If the above was occurring, I would expect set_param/get_param to not be successful.

As an additional point, if I open up the model to the correct block and then run my log signals script - the appropriate icons appear.

The problem appears to be associated with turning on the signals when he system is invisibly loaded in the background.

[AJ von Alt]

Without the scripts and model it's tough to guess where things are going wrong.

From your description it sounds like there might be a model path issue. How are you calling "find_system"? e.g.

find_system( gcs  , ...
find_system( bdroot , ...
find_system( 'modelname' , ...

If you are using gcs, then find_system may return different results when you run the script after navigating to a subsystem.

[Stefan]

Thanks for the reply. I'm using find_system with 'modelname'.

I just ran a test case and found that the problem might be related to my use of configurable subsystems. As in the above example, the expected signal logging behavior was achieved outside of signals located in configurable subsystems.

As a couple added points - I'm using Matlab 2013b and I'm running on a mac.

[Stefan]

I just ran a test and my system will run and export a log structure (of the Dataset variety) but only signals not in configurable subsystems are logged. Originally, I was only logging configurable subsystem signals - so this led me to think the problem was more general than it might be. When designing a configurable subsystem, are there parameters/settings that impact the ability to programmatically turn on logs?

Thanks

Answer 1

[Stefan]

I've solved this problem. When programmatically turning on logging, it appears to require that all configurable subsystems be "set" prior to turning on logs.

Specifically, my tool chain would not touch a block if the default configuration was appropriate (so set_param would not be used to force the block choice). Under this condition, signal logs would not be properly activated.

Explicitly using set_param to configure each block prior to programmatically turning on any signal logging resolved the problem.

In the original question posted above, I believe I was observing shifting of the handle parameters based on the setting of the configurable subsystem. More precisely, if the default configurable subsystem was used (block not explicitly chosen), the detected handles would be different from those handles generated when the configurable subsystem was fully loaded (fully loaded referring to the case where one has navigated directly into the configurable subsystem).

This is a little bit of an odd behavior and I'm not this post fully resolved the nuance of simulink's behavior in this regard - but the solution does work.