Debugging Tools Available When Building C Models for VeriStand using the VeriStand Model Framework

Updated Sep 27, 2024

Reported In

Software

  • VeriStand

Programming Language

  • C

Issue Details

I am writing a model in C that I will compile into a .DLL or .SO shared library that will be called in VeriStand using the VeriStand Model Framework. I need to debug my model code while it is deployed to the VeriStand Engine on my NI Real-Time Target. What tools can I use to do so?

Solution

If you are writing and building your model code in LabWindows/CVI, refer to this page for more information on debugging your model. Please be aware that this process would not be supported if deploying your model to a Linux Real-Time target.

In general, C Models built for VeriStand can be tricky to debug because the models are compiled and being run dynamically by the VeriStand Engine. There isn't any way to add breakpoints to the model code or perform any signal stepping. However, there are some debugging options available to use:

Using model signals

The recommended method of debugging is to define signals in your model that will allow you to probe intermediary model signals and view them in VeriStand. You can refer to the Model Framework shipping examples located at C:\VeriStand\<version number>\ModelInterface\custom\examples to see how this can be implemented. For example, the sinewave.c model shows how 3 signals (sinewave, sum, and gain) can be defined and written to from within the model code.

Logging and printing to screen

The VeriStand Model Framework API does not have any functions for writing to the VeriStand logs or printing to a monitor connected to your target. However, it is possible to use standard C function calls to do so. For example, you could log data to a file on disk of your target using normal C file IO calls (such as fopen, fwrite, fclose), or print debug lines to the target's standard output using the printf command.

It should be noted that performing file IO within a model can affect the model's determinism and cause the VeriStand Primary Control Loop to run slowly. This should only be used for debugging, and should be removed from the final version of the model that is going to be deployed.