ERR (-61017) in Labview program

[anandsa]

I have an error that causes my labview program to be stuck indefinitely once every few times I run the program. I suspect this has something to do with the FPGA startup since I see ERR (-61017) on the output line from the FPGA VI reference block inside my host program's block diagram. I was able to observe this error when running the host program in debug single stepping mode. The only way to resolve this condition seems to be restarting the labview environment and running the program again. But since I need to be able to run this host program smoothly from a custom C++ application, this error needs to be avoided. Any ideas on how to proceed would be much appreciated.

P.S: The function of the host program is data acquisition using FPGA from 6 channels (3 each from two NI-9239 analog input modules connected to the board). Please find the labview project, vi files, and screenshots of the observed error attached here.

[Claire.C]

Can you try to go into the Open FPGA VI Reference and configure it to use the bitfile instead of the VI? If you right-click on that function the option should be there.

[anandsa]

Hi Cullen,

I tried configuring the Open FPGA VI reference block to use a bitfile instead of the VI. I was able to reproduce the same results. I tried running in single step mode and nothing has changed except for the error code. I get ERR (-61202) now from the FPGA reference block and the host VI is still stuck indefinitely. I have attached a screenshot of the error. Is there anything else I can try?

[anandsa]

Update: I modified the Delta Sigma Continuous Acquisition (pipelined) project that comes with the LabVIEW software package by adding my host VI to the project under my sbRIO board. I also modified the existing FPGA program in the example to accomodate 6 channels from two modules (3 each from two 9239 AI modules) instead of 4 channels from one module. The existing host program in this example project seemed to work with 6 analog input channels when I ran it. But after I ran my program and got to the dysfunctional state, I tried running the original host program in the example again. I could see the program gets stuck in the inner polling loop where it waits for data to come into the FIFO from the FPGA. And I see no data coming into the FIFO. This is why I'm stuck indefinitely. Any ideas as to how I can locate the root cause for this issue?

P.S: The example program that I am referring to can be found in LabVIEW's example library for cRIO. It is named Delta Sigma Continuous Acquisition (pipelined).

[Claire.C]

Can you try to close the FPGA reference upon exit? That can can sometimes cause this error if a second reference is opened before the first is closed.

[anandsa]

Hi Cullen,

Yes, there is a missing close FPGA reference block. Even after adding it, there are some problems with the functionality. I can see that the labview program sometimes gets stuck in the same unresponsive state when started. But now I am able to resolve the issue by stopping the program and running it again from the front panel. However, I need to be able to run the labview program from an external application without having to interact directly with the front panel interface. For this, I have enabled this as a startup application on the sbRIO board. But I have the same error that I reported in my first post here every time I try to restart the board or stop/start the labview real-time environment.

Anand

[anandsa]

Update: . The issue is not only with the startup app setup. We are able to see the same condition when running the labview program through the proper front-panel method. Each time we run the program immediately after the board has booted up, the program goes to a hang state. While this was happening, we tried going to the block diagram and selecting the options for ‘Highlight execution’ and ‘Retain wire values’ to examine. We could see that our setup to initialize a shared memory at the beginning of the program was not getting executed. For some reason, the program was moving straight to the data consumption loop where we write the acquired data to the initialized shared memory. But in this case, the variables storing the shared memory addresses seemed to have some values stored in them already (maybe from a previous run of the program). Since the data acquisition loop was also not executed, there is no data in the queue for the data consumption loop to work with. So the program gets stuck in this loop and doesn’t come out. The only way to come out of this state seems to be to stop and restart the program from the front panel. All subsequent runs of the program were successful after this. We tried adding a wait sequence of 60 seconds before the fpga reference block suspecting that the RTOS was not able to load all required services before execution. But this did not change anything. I have attached the latest version of our VI’s and project for your reference.

[Claire.C]

You say that shared memory initialization is not executing correctly, can you describe in more detail what you are seeing in Highlight Execution mode?

In addition, can you tell me the exact place where the Data Acquisition loop/before the data acquisition loop hangs? Is there a certain node at which it stops?

It seems that the program is not getting to the "Release Queue" function, which is why there is still data in the queue. For now, I would put a "Flush Queue" immediately after the "Obtain Queue," just to prevent this from happening while we work to on what is preventing this loop from running.

[anandsa]

We were able to resolve the issue when running the labview program from the front panel by making a small change to the FPGA VI. There was a wire missing in between the data rate blocks and the module start blocks. Now the program seems to run without problems when it is run from the front panel interface. But the same problem persists when we try to run the program as a startup application on the sbRIO board. Also, there is no data getting written to the shared memory from the queue. So the issue is probably not related to the queue. It is also much more difficult to debug the program when we try to run it as a startup application as opposed to running it from the front panel.

[Claire.C]

That is more difficult, yes. Just for clarity's sake, can you reiterate which error you are seeing now when you run as a startup application, and how you are verifying that your program is running?