FPGA reference issues between development station and run-time? error code -63195

[queenlooners]

I will do my best to describe the issue I have been seeing.  Note, I have tried quite a few other posts that sort of touch on my issues but they never seem to have a final solution.

Background -

I have 3 VIs:

VI 1) opens/runs the FPGA bitfile reference and stores the reference to a file global so that I can call the reference from other VIs.  I need to do this as opposed to opening a new reference because I am using the FPGA for digital communication and it adds around 100 ms to to open a new reference every time I need to read/write to FPGA target from host (100 ms is a long time in digital world!).  Some people use Shift Registers.  I am ultimately calling all my FPGA host VIs from TestStand to run an automated test so it was easier to break up my open/close/read/write functions.

VI 2) calls the file global reference for FPGA then passes it to a read/write node to change parameters for the target then passes the output reference from the read/write node back to the file global reference

VI 3) calls close FPGA reference and the function is passed the file global reference.

Issue -

I don't understand why this method works just fine when either I am running from TestStand with station options set for developmental mode (not run-time) or when I have one VI opened that calls these 3 VIs individually in a sequential order but DOES NOT work when I try to run these VIs individually (Run VI 1 - open->write ref to file global reference -> Run VI 2 - read file global reference ->read/write control function ->receive error -63195)  or when I run them in the same TestStand sequence but set with station options for run-time.  Maybe I need to change TestStand sequence to load all modules upon startup?

Why does the reference get lost when switching between developmental and run-time and why can't labview file global keep the reference stored?  Is there a work around? 

[dnchen]

Hi there,

Could you clarify for me the situations where it is working and it is not? Here's what I understand from what you wrote:

1. Running from TestStand in Dev Mode - works
2. Running from TestStand in Dev Mode with one VI that calls the 3 VIs in sequential order - works
3. Running from TestStand in Dev Mode manually running each of the 3 VIs in sequential order - does not work
4. Running from TestStand in Runtime Mode - does not work

Is this correct?

Could you describe the specifics of the text from the error -63195 that you are seeing? A screenshot would be nice.

What versions of TestStand and LabVIEW do you have installed? 32 or 64bit? What about RIO drivers and any other drivers/modules?

Have you monitored the value of the file global while running the VIs? Particularly for situations 3 and 4?

[queenlooners]

Should have included this in the first post...hope it clears up some of the confusion.

WHEN RUNNING FROM LABVIEW ONLY:

Photo 1 works just fine….

Photo 2 (where I run DTL_OPEN.vi, standalone, first then I run DTL_READ.vi, standalone) does not work…

It is like the FPGA completely stops when there is not a thread running directly calling it…

WHEN RUNNING FROM TESTSTAND ONLY:

The TestStand issue is even weirder…I just figured out the repeatable trend when running in “run-time”.  Apparently, I call the DTL_OPEN.vi (it works), then I call the first DTL_READ.vi (it works), then I call the second DTL_READ.vi (it aborts with “Error:  LabVIEW:  VI was aborted.  [Error Code:  -18002.  LabVIEW reported an error…”).  After the VI aborts, the sequence is terminated.  I rerun the sequence and the second time I run the sequence, the first DTL_READ.vi no longer works.  The only way to make the first DTL_READ.vi work again is to File->unload all modules.  Rinse and Repeat problem…

Of course when I am running the test sequence in “developmental” mode in TestStand, I get no errors and FPGA works like a champ…calling DTL_OPEN.vi, then making multiple successive calls to DTL_READ.vi with no problem…This, to me, would be like running the VIs individually in LABVIEW ONLY (which did NOT work)…

Obviously I am missing something big on how the FPGA references is being stored/passed and how the FPGA is behaving after calling the "OPEN FPGA VI REFERENCE" node (I do have it checked to run the FPGA VI when opening the reference).  I had thought that the FPGA would continue to run the compiled code until it is reset and the reference closed.

[dnchen]

Hmm... that Error -63198 that you are seeing may be resulting from too many reference handles being open that aren't closed. Try doing this.

In your Open.vi :

1. Create an Open FPGA VI Reference
2. Set it to Run FPGA VI
3. Close the FPGA VI Reference
4. Right click set to "Close" (don't reset)

Then in your Read.vi : 

1. Create an Open FPGA VI Reference
2. Set it so there is no "run fpga vi"
3. do your read writes
4. Close the FPGA VI Reference, set to "Close"

In your Close.vi :

1. Create an Open FPGA VI Reference
2. Set it so there is no "run fpga vi"
3. Close the FPGA VI Reference
4. Right click set to "Close and Reset if Last reference"

You are right in that the FPGA VI continues to run until it is reset. I think our problem may lie within the references being passed around.

[queenlooners]

I believe what you are suggesting would work but the problem is that I am trying to avoid the extra open/close calls since they add time to my execution. Again, I am using the FPGA for digital communication (calling read/write nodes thousands of times).  The 100 ms to call open really does add up...this was what I did not want.  I still don't see why it works in development mode in teststand and not in run-time. 

Thanks for your help, I am still a little confused.  I know it is the reference that is the problem and calling it from a global VI is just not working in run-time.  I believe that is where the problem is, in getting the FPGA VI reference from the Global.VI. 

When running in TestStand, I proved out that the VI aborts after trying to grab the FPGA reference from the Global.vi (the error occurs before the read/write node).  I just don't understand why.

[dnchen]

Hmm I see. Is there any reason that you are calling your read/write VI a bunch of times instead of using a for loop? I'll look into if there's any other way to transfer the FPGA reference that wouldn't have the same problems as a global variable. 

[queenlooners]

I am not sure what you mean about only calling them from a for-loop instead of a bunch of times.  I call the host VIs from TestStand sequence steps executed one at a time (no multiple threads).  I sometimes will have the Host VI calls in a for-loop in my TestStand sequence but not always.

Any ideas on the problem with the gobal variable or a work around?

Thanks again for all of your help so far.

[Gloorious_Leader]

Rather than using a global variable, you might have better luck using a local variable (at least in TestStand). TestStand has a variable type for passing references (LabVIEWIOControl) that is intended for this sort of application. Take a look at this KnowledgeBase Article (Calling LabVIEW FPGA VIs From TestStand), it has an example attached that shows how you can open a reference and pass it between steps.

[queenlooners · Accepted solution]

Finally found a solution.  I don't understand why it is required when reading from the FPGA and not when writing (actually I don't fully understand why it worked at all) but I ended up changing the Step properties in my TestStand sequence for the step calling my DTL_READ.vi to be Properties->Run Options->Unload Option->"Unload after step executes".  This seemed to do the trick to get my TestStand test sequence to work in Run-Time engine.

I still don't understand why this was not required when running the same sequence in developmental mode and why it is not required when I call my DTL_WRITE.vi.

Both the DTL_READ.vi and DTL_WRITE.vi pass the labveiw global.vi parameter "FPGA VI reference" to a read/write node.  I don't know if the root of the problem is in my LabView FPGA host VI or in TestStand...

Thanks for all of you guys' suggestions!  I am happy I have it working but I am still confused by the solution.