Table Of Contents

Common Issues with Models in VeriStand

Last Modified: June 10, 2021

If your model crashes or does not execute as expected, isolate the issue and determine if its source is within the model or due to your system definition.

To identify the source of an issue, replace your model in the system definition with a simple model, and then redeploy the system definition. If the simple model executes as expected, the source of the issue is within your model. However, if the simple model also experiences issues, the source of the issue is due to settings for your system definition.

The following table lists common model issues and solutions.

Issue Solutions
Model is crashing

Models often crash when an inport receives a value of 0 and the model attempts to divide by the inport value. This issue will occur during deployment if the initial state of the model is to run and the default value for an inport is 0. Depending on your system, complete the following troubleshooting solutions:

  • Change the default value for the inport.
  • Rewrite the model to remove the possibility of dividing by 0.
  • Change the initial state of the model to be paused in System Explorer and implement a start-up procedure that ensures that the inport values are acceptable before you start the model.
Model runs too fast or slow

If your model is unstable because it runs too fast or too slow, ensure the actual model rate matches the rate at which the model was compiled to run. If the rates do not match, adjust the settings that determine the actual model rate until the following expressions are correct:

actual model rate = compiled model rate

actual model rate = PCL rate / decimation
Adjust the model timing by configuring the following settings where specified:
  • Compiled loop rate—Displays on the Model Configuration page, in Simulation model info.
  • Model decimation—Set on the Model Configuration page, in the Decimation control.
  • PCL rate—Set on the Controller Configuration page with the Target Rate control.
Model generated data is delayed

If other parts of your system that are mapped to your model do not receive data when you expect, consider adjusting the following system definition settings:

  • PCL execution mode—Change the execution mode to low latency if data from models must be available for mapping during the same PCL iteration the model generates the data. The default mode, parallel, applies a one-cycle delay between when a model executes and when the data it produces is available for mapping.
  • Execution order—Multiple models in a system execute in parallel unless you define an execution order. If you map an outport from one model to an inport of a second model and you want the second model to wait until the first model finishes executing before it runs, you must define the execution order.
Decreased system performance

If you suspect that models are causing your system to run slower than you desire, consider the following solutions to improve performance:

  • Import only parameters and signals your system requires. Importing many parameters and signals can have a negative impact on the performance of the model even if the model is not running.
  • If you do not need data from models to be available to the rest of the system on the same iteration of the PCL, set the PCL execution mode to parallel instead of low latency. Parallel mode causes a one-cycle delay between when a model executes and when the data it produces is available to the system, but increases the execution speed of the entire system.

If you continue experiencing issues with your model, contact NI Support.

Recently Viewed Topics