Multiple OK boards being accessed from the same application

I’m trying to overcome an issue of not being able to access the board from two separate pipes simulateously. What I have is two boards being initialized in one application, and two threads running pipeR/W tests, where each thread accesses a different board. All calls (within a single thread/device) are protected to avoid multiple calls to the same device. What I see is similar to the situation whereas you have multiple threads accessing the same board with multiple pipes. It does not work, and seems to deadlock on calls. I would think I could access two boards at the same time from one application, no? Or, does the DLL simply only allow access from one board at a time? Would multiple applications (one for each board) allow for simulateous pipes to run?

On another note, if I poll the board (wireins/outs) from a thread will that too block the pipeR/W calls?

This is a 6310-LX150

Thanks,
Rich

Rich–

Multiprocess access (and multithread) should be fine if you have different instances of okCFrontPanel.

In fact, we regularly demo our XEM6310 and Shuttle LX1 attached to respective camera modules and capturing real-time images on both simultaneously.

ALL transactions to a given instance of okCFrontPanel are blocking and can interfere with each other. You cannot poll wires and operate pipes simultaneously. You will need to mutex the FrontPanel instance.

Hello,
So I’ve created a modifed PipeTest with mutiple threads to test a multiple board configuration. These threads use different instances (MyID[numBoards].dev = new okCFrontPanel) for each board. I’ve individually mutexed the instances to protect them from stepping on calls to themselves. There is no cross calls betwen threads, but what I find is one interfers with the other (blocks the other threads access to a second board). Any thoughts? From what I read above I should have no problem doing this.

One more detail. These are on two different buses (I tried to isolate them completely). One is USB 2.0, one USB 3.0. I get the same result if they are on the same bus (USB 3.0) though.

Thanks,
Rich

Rich–

We’ve run multiple instances of our EVB100X Camera Application on multiple boards (USB 2.0 and USB 3.0) simultaneously for hours on end at demos without any issues.

We’ve also run multiple instances of PipeTest to USB 2.0, USB 3.0, and PCIe boards simultaneously without issue.

What do you mean by “blocks the other threads access” ? There is nothing in our API implementation to block access or otherwise mutex resources.

From my earlier post

So I’ve created a modifed PipeTest with mutiple threads to test a multiple board configuration. These threads use different instances (MyID[numBoards].dev = new okCFrontPanel) for each board. I’ve individually mutexed the instances to protect them from stepping on calls to themselves. There is no cross calls betwen threads, but what I find is one interfers with the other (blocks the other threads access to a second board). Any thoughts? From what I read above I should have no problem doing this.

This is one application, with two instances to two separate boards each running in it’s own thread. I think your testing involved multiple applications, one for each board, correct? Is there an issue with multiple access from the same application?

Thanks,
Rich