Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

Renamed 3 network-shared variables into subVI on RT startup VI, now they won't write?

Solved!
Go to solution

Hi Everybody,

 

I've been working on a deployed RT program for our cRIO-9024 with custom FPGA, and I changed the way data is written to these three 1D DBL types. I renamed the shared variables ("shvars") in the RT project's shvar library and also changed the target to PC for some debugging of the function of the code that writes to them. I used a conditional compile struct to disable them, and something got corrupted along the way and the second shvar node broke (node dragged directly from project, not programmatic style) and caused a hard compile failure in this subVI. I got the compile error to go away after deleting the shvar node entirely and placing it again from the project and all seemed well.

 

Soon, I move the subVI back to the RT application instance and build my RT exe and deploy it. On the host PC now, that second shvar is not getting written to at all. I chase and chase and decide that something is wrong with the deployment of the shvars. I redeploy all and go so far as to delete all 3 of these shvars' nodes in the subVI and place them again. Now, all 3 aren't getting written to! My next step is to move the shvars out of that subVI I put them in, but is this recommended? Note that sometimes they seem to get written to once, then are forever silent after that. Is this because I'm using the nodes instead of the programmatic access function with the shvar addresses?

 

Thank you.

 

Edit: note that the same top-level RT vi successfully writes to 19 other shvars that I haven't touched.

____
Ryan R.
R&D
0 Kudos
Message 1 of 3
(3,983 Views)

Ok, so I may have been barking up the wrong tree here. I found a bug in my FPGA code that may have caused this issue. The code that writes to the shvars in the RT vi after reading from the FPGA FIFO will not write the shvar if the data doesn't make sense, but there was a timeout in the FPGA code that feeds the FIFO that is supposed to trigger once when the timeout happens, but was instead being triggered ever after the timeout (level triggered instead of edge triggered), flooding the FIFO at a drastically higher rate than normal and breaking the subVI's logic. I'm compiling the (hopefully) corrected FPGA now and will see if I've fixed it.

____
Ryan R.
R&D
0 Kudos
Message 2 of 3
(3,973 Views)
Solution
Accepted by topic author RnDMonkey

Alright, so I shot myself in the foot and was indeed barking up the wrong tree. Putting the shvar nodes in a subVI was fine and not at all related to the problem.

 

The problem was that I had a bug in my FPGA code that in a particular case would cause it to stop putting out valid data. Once I fixed that bug, everything went back to normal. I would delete this thread, but a little embarrassment is good for you. 🙂

____
Ryan R.
R&D
0 Kudos
Message 3 of 3
(3,959 Views)