NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

How to set the Lock in parallel sequeces?

Solved!
Go to solution

dug9000,

Thanks for your help.

 

We have an NI FPGA board that mutliple threads in multiple executions want to access and we have to control it.

 

We enter through Test UUTs and in this entry point execution A is launched on GaugeRead.seq that has a sequence running forever that occasionally needs to read data from the FPGA that it will get in FPGA.seq. 

In our Testprogram.seq there will be a sequence that will want to read from FPGA.seq but hang on to control of that board for longer periods of time.  While this is happening there will be yet another thread in Testprogram.seq that was previously started which will make a call to Controller.seq which will have a call to FPGA.seq.  I'd want the calls that come from GaugeRead.seq and Controller.seq to timeout after a short period of time and come back later to try again.

 

It was my thought that FPGA.seq would take care of creating the Lock and keeping up with when different executions/threads wanted it by using an Object Reference for lock lifetime.  The fileglobals of FPGA.seq are set to share across executions. 

0 Kudos
Message 11 of 13
(968 Views)

@CoastalLabVIEWER wrote:

dug9000,

Thanks for your help.

 

We have an NI FPGA board that mutliple threads in multiple executions want to access and we have to control it.

 

We enter through Test UUTs and in this entry point execution A is launched on GaugeRead.seq that has a sequence running forever that occasionally needs to read data from the FPGA that it will get in FPGA.seq. 

In our Testprogram.seq there will be a sequence that will want to read from FPGA.seq but hang on to control of that board for longer periods of time.  While this is happening there will be yet another thread in Testprogram.seq that was previously started which will make a call to Controller.seq which will have a call to FPGA.seq.  I'd want the calls that come from GaugeRead.seq and Controller.seq to timeout after a short period of time and come back later to try again.

 

It was my thought that FPGA.seq would take care of creating the Lock and keeping up with when different executions/threads wanted it by using an Object Reference for lock lifetime.  The fileglobals of FPGA.seq are set to share across executions. 


This is what I'd recommend:

 

1) Do not use the object reference lifetime at all for the lock operation.

2) Use the sequence lifetime for the lock operation and lock it at the top level sequence in which you want to use or reserve the usage of the FPGA. It's ok to nest locking. A thread can acquire the same lock multiple times (nesting is supported and ownership of the lock is reference counted).

3) For the timeouts, just have a timeout on the lock's lock operation and have a step after the lock operation check to see if a timeout occurred. If so, it can then do whatever you want it to do in that case (but it should not access the FPGA or call EarlyUnlock because it didn't acquire the lock).

4) If you need to unlock a lock prior to the end of a sequence in which you locked it, use the EarlyUnlock operation on the lock.

 

Another alternative if you don't want other sequences besides the FPGA ones to deal with the lock is the following:

 

1) use object reference lifetime for the lock operation ONLY where you want to hang onto ownership of the lock for longer than the lifetime of the sequence, pass the object reference back to the caller as a parameter instead of storing it in a file global (the caller should store it in a local variable).

2) When the caller no longer wants ownership of the FPGA it can set its object reference variable that stores the reference it got to Nothing. That will effectively release its ownership of the lock.

 

Hope this helps,

-Doug

0 Kudos
Message 12 of 13
(960 Views)

dug,

 

Thanks for your help.  I got impatient and implemented VIs that are called out of the FPGA sequences.  If we get some time I'll see about using your suggestions

0 Kudos
Message 13 of 13
(921 Views)