A LabVIEW Simulation Interface Toolkit (SIT) host VI successfully updates a Simulink-generated DLL when an operator moves a mapped duty-cycle control. The same model stops producing updated voltage and current values when an FPGA interrupt-driven while loop writes that control through a local variable. Because signal probing shows that the DLL continues to execute, troubleshoot the data path and execution timing before treating the model as unloaded.
Separate Confirmed Behavior from Unknowns
| Observation | Engineering implication |
|---|---|
| Moving the mapped duty-cycle control updates voltage and current. | The model can process an interactive control change, and the resulting values can reach the PXI FPGA I/O path. |
| Writing through the FPGA-connected local variable does not produce the expected model output. | The failure is associated with the programmatic update path, its timing, or how SIT detects the mapped input change. |
| The DLL function appears to keep running when probed. | Execution alone does not prove that the DLL receives each new duty-cycle value. |
| The model was selected to run on a real-time target. | DLL deployment and target-side file discovery remain items to verify; the evidence does not confirm either one. |
Trace the Duty-Cycle Data Path
Instrument the value at three boundaries: immediately after the FPGA interrupt transfer, immediately before the local-variable write, and at the model input visible to SIT. Compare value and update sequence at each point. If the first two boundaries change but the mapped model input does not, isolate the SIT-to-control update mechanism. If the value is already stale after the interrupt transfer, troubleshoot the FPGA/host communication path instead.
Keep the working slider test as a control experiment. Feed the same duty-cycle sequence first through the slider path and then through the FPGA-driven path while observing the identical model input and voltage/current outputs. This comparison separates a model calculation problem from a difference in how the host VI delivers input changes.
Check Loop Timing and Dataflow
Compare the execution rate of the loop containing the model with the rate of the FPGA interrupt-driven loop. The available evidence does not establish either rate, so measure both rather than assuming they are synchronized. Record whether each FPGA value is written before or after the corresponding model execution; an unsynchronized local-variable update can obscure the required data dependency even while both loops continue running.
- Add sequence or timestamp diagnostics at interrupt receipt, duty-cycle acquisition, local-variable write, model execution, and voltage/current publication.
- Run the working slider path and capture the observed order of those events.
- Run the FPGA-driven path and compare its event order with the working capture.
- Confirm that each intended duty-cycle change reaches the mapped model input before evaluating the corresponding outputs.
Verify Real-Time DLL Deployment
Confirm that a copy of the Simulink-generated DLL exists on the real-time target and that the target can resolve it at runtime. Also verify where the probe data originates: host-side execution observed through the development environment is not, by itself, proof of target-side DLL execution. If deployment and loading are confirmed, return to the boundary trace because the strongest evidence points to input propagation or scheduling rather than the model equation itself.
FAQ
Why does the SIT model update from a slider but not an FPGA local variable?
The slider result confirms that the interactive mapped-control path works. Trace the FPGA value before the local-variable write and at the SIT model input to determine whether programmatic changes reach the model before it executes.
How do I verify that the Simulink DLL is running on the real-time target?
Confirm that the DLL was transferred to the target, that the target can locate it, and that diagnostics are observing target-side execution. Seeing the function run in the development environment does not alone identify where it executes.
Can loop timing prevent LabVIEW SIT outputs from updating?
Yes, timing is a supported diagnostic hypothesis in this case. Measure the model-loop and FPGA interrupt-loop rates, then verify that the duty-cycle write occurs before the model execution used to calculate voltage and current.