Handling 2 or more USRPs

[mirac]

Hello everyone,

I am dealing with a problem when handling multiple USRPs with LabVIEW 2020. I have 3 x USRP-2943R and these are connected to the pc via MXI-Express cables. I would like to control these 3 USRPs individually at the same time but somehow I keep failing.

I have a simple VI which includes niUSRP Open Rx Session.vi and the rest of the RX chain. When using only one USRP with one RX chain, I successfully control the USRP. But when it comes to two or more USRPs with multiple chains of algorithms, niUSRP Open Rx Session.vi function works for one USRP and keeps in running state for the second or the third chain. It is not about the Reenterancy and stuff. I think that it is about the niusrp2.lib which fails to handle multiple USRPs simultaneously. 

You might also suggest to use only one chain for all the USRPs ( where the device names contains all USRPs) but it is no good for me. I need them seperately. 

I am adding the simple VI picture that I have mentioned, and waiting for your replies.

Have a great day.

[psisterhen]

The driver should certainly support that.  Is there a particular error reported?  Are you saying that the calls never return from the Fetch Rx Data VIs in the second and third sessions?

As an alternate approach, you could create a single session containing all three devices.  Give the device names as a semi-colon separated list to Open Rx Session.  Then, you can fetch data using the multi-channel VI option.

[mirac]

Unfortunately, the drivers failed in my case. There is no error coming from the VIs or DLLs. I am saying that when one USRP is active, opening a new sessions makes the first USRP stop and wait until the second USRP is active. The same goes for the third one. If I attempt to open their sessions at the same time in one VI, the waiting time takes too long. 

The latter suggestion of you is not a good solution for me. The study that I am working on requires different controls and sessions. I dont know what to do. Thanks for your reply. 

[psisterhen]

I see.  Yes, the driver is re-entrant for most calls... however, the exception is the Open Rx (or Tx) Session because it (briefly) locks out other threads to access a global session registration space.  That brief lock could certainly interfere with a Fetch loop from other sessions, causing them to wait and miss data/overflow.

The solution in this case is to Open all of the Rx sessions you need first, before letting any one of them continue.  You can serialize the process of opening sessions, then once all are open, the rest of your code can run concurrently.