Using "printf" and "scanf" in External Mode

I am generating an executable from my model for External Mode simulation that I will run on a target machine and connect to from my host computer. The executable has "printf" and "scanf" statements included in it to monitor its error status and provide yes/no inputs, for example:

1) “X is doing Y”

2) “Do you accept [y/n]:"

The documentation below states that target application error and information messages can be shown on the target hardware display by using "printf" calls:

https://www.mathworks.com/help/ecoder/ug/external-mode-simulation-with-tcpip-or-serial-communication.html#bqo0__w-1

Hence, for the moment, we are using SSH to the console on the target to interact with the "printf" and "scanf" statements. Is there a way for the input/output of these statements to show up in Simulink on the host computer?

Answer 1

[MathWorks Support Team]

Unfortunately, there is no way to interact with "printf" and "scanf" statements directly from Simulink at the moment. These functions can be used in the generated code, but they only provide interactions through the console where the executable is running.

You can still interact with the External mode execution directly from Simulink using tunable parameters, dashboard blocks, and instrumentation blocks (e.g. displays, scopes, to workspace, etc.). For more information, please refer to the link below.

https://www.mathworks.com/help/ecoder/ug/external-mode-simulations-for-parameter-tuning-and-signal-monitoring.html

How you choose to use these blocks depends on your use case. For your application, to have an equivalent of "X is doing Y", you might want to add a block whose output provides the information. You may also consider using a Manual Switch block for the "y/n" inputs.

A different approach you may consider is printing output to a file instead of printing to the console. However, this may not satisfy your use case if you want to deploy to a separate target (i.e. not running the executable on the host).

As the final workaround, you may connect to the console running the executable via SSH, as mentioned.