I'm running a data acquisition application on a cRIO-9039 (if that shall be of interest) with LabVIEW 19, and appropriate versions of FPGA and RT modules.
Since the last set of measurements, I made some modifications to the FPGA code. I used to be a big fan of local variables, as they, if used properly, may save you some spaghettis. However, of course, I agree local variables are bad in general. What happened now was that local variables, which had been in the code already for the last set of measurements as well (and working correctly), suddenly started acting as constants instead of reading their respective values. Precisely, the local variables would now always yield the initial value of the respective front panel element, instead of the current value. In this case, probing the variable output with another indicator read from the desktop VI shows the initial value, instead of current. Reading the front panel element owning the local variable directly from the desktop VI however gives the correct, actual value.
The most strange thing about this is the sudden change in the behavior of the local variable, that occurred somewhere along the process of modifying the FPGA code.
I got the issue solved by replacing the local variables by the front panel elements directly, which have been partially disconnected before. Any ideas how this may be explained?
A guess from my side: The whole thing happened somewhere when the FPGA started running low on slices. Maybe, by that time, LabVIEW started an optimization process and replaced any front panel elements, which are not modified (or read) within the FPGA VI itself, by constants. Greatly overlooking the fact that the front panel elements were modified by values set in the desktop VI...
Now that I'm done writing this, my own guess seems to make even more sense than before. Still interested in your suggestions on this!
AFAIK, LabVIEW FPGA cannot replace or remove FP elements as this is an essential part of the API to the bitfile you are creating. That would certainly be an invalid optimisation and it would surprise me very much if that would be part of the problem.
How are you accessing the locals? Are you aware that clock-domain-crossing can lead to some minor headaches with locals, with propagation of values requiring sometimes 3 cycles to occur.
If you can show some code how you're accessing the controls / locals, maybe we can help.
Of course, what can never be completely ruled out is just a corrupt VI or FP control. These can create absolutely infuriating problems.
First of all, thanks for your reply.
I wouldn't say that LabVIEW removes the front panel elements, but probably either LabVIEW or the Xilinx compiler replaces their local variables by constants to save resources, as the front panel element seems unchanged throughout the code (but is in fact modified from the desktop VI).
The local variables were not accessed inside any SCTL, but only within the main while loop. Imagine just an unwired terminal in front of the while loop, and just one local variable set to read mode inside the while loop. That's really all to it.