Is there a straightforward way to get names or IDs of signals recorded using Outport blocks in Simulink Real-Time?

I have a big model where I am logging a large number of signals. I currently use Outport blocks, then look at the data in tg.OutputLog in the workspace after stopping the simulation. However, OutputLog contains only the signal data in columns, no labels. In order to know what each column corresponds to, I have to go through my model and keep track of how the signals are ordered and bundled before ending up at the root-level outport blocks. This is difficult and tedious for a large model with muxes going into other muxes in various subsystems, and made worse by the fact hat the model is frequently being changed/updated.

Is there an easier way to figure out what the tg.OutputLog data corresponds to?

The normal Simulink signal logging functionality (where you can enable logging through a signal's properties or through the Model Data viewer) would be ideal, since signal names are included in the logged data, but this does not work for real-time since logsout is not saved -- the documentation states "the data logging variables tout, xout, yout, and logsout are available only when you use Simulink to simulate the model in non-real-time."

I also know signal groups can be created and saved in the SLRT explorer but that seems to be for monitoring only, I don't see an option for logging ( documentation ).

The only other option I can think of is to have a script where I feed in a list of signal names and it adds them to file scopes (using the SimulinkRealTime.fileScope.addsignal function). However, this is still quite tedious and requires me to maintain a list separate from my model, and also the documentation states SimulinkRealTime.target.getsignalid (IDs are needed to add signals) is being deprecated in future releases.

Answer 1

[Jon Lobo]

Hello, I have a few recommendations for you. First off, I would suggest using file scope over tg.OutputLog as the output log is limited by RAM size whereas filescope uses the hard drive. Additionally, the output log has the limitations you mentioned above.

You can use the file scope without going the command line route (SimulinkRealTime.fileScope etc). There is a block in the Simulink Real-Time library to do this. (see: Target Scope). Please note there are three kinds (target, file, and host).

While getsignalid is marked for deprecation, you don't actually need it anymore since you can add signals to the file scope by knowing their path in the model. When you use the tg object and explore the list of signals (tg.ShowSignals = 'on'), you'll see the available signals in your model. You can double check the path syntax by using tg.getsignal(signalpath) where signalpath is the path to your signal of interest.

Now, these are just some options pertaining to your current workflow. Depending on which version of MATLAB you are using, it may be significantly easier for you to explore using the Simulink Data Inspector as that works with Simulink Real-Time as well. (see: Inspect Simulink® Real-Time™ Data with Simulation Data Inspector)

[EP]

Thanks for the reply Jon. I wasn't aware of the output log RAM size limitation, that's good to know.

For the time being I ended up implementing the file scope option. I do know that file scopes can be added from the library, the main reason I'm adding signals programmatically is so that I can keep track of the correspondence between signal name and the data column in the final file. That way I avoid having to keep graphically keep track of the signal lines and their order as they make their way to the outport block (or file scope).

I can attach my code in case this isn't clear, but my current workflow is basically:

1. a list of signal names to log is stored in an Excel file (no duplicate signal names allowed)
2. the model as built has a single file scope that is not connected to anything
3. the StartFcn model callback runs a script that imports the signal names from the Excel file
4. for each signal name, the script gets its signal ID ( getsignalidsfromlabel(tg, signalname) ) then uses that ID to add the signal to the file scope ( addsignal(scope, id) )
5. since signals are logged by the file scope in the order that they are added, the original list of signal names also serves as labels for the data columns in the saved file.

Would you happen to know when getsignalid will be removed? It's good to know that the above workflow can still work without it, though needing to know the paths (rather than just the signal name itself) will be less convenient than it is currently.

Finally, I haven't used the Data Inspector yet as I was using an older MATLAB version until fairly recently but it looks like it might be a nicer solution. 2 questions regarding that:

1. We're logging ~50 signals so I'm assuming buffered logging mode will be necessary to avoid data loss. Is there a way to enable this globally? I can only find how to enable it on a per-signal basis.
2. Are there any memory limitations I should be aware of, i.e. with RAM again? Or (assuming buffered logging mode is on) is the same as the file scope, where the main limitation is maximum 4GB file size on the target machine?