LabView dll parallel

[Porras]

Hi, all.

More LabView-dll issues... After searching in the forums and checking documentation, I'm not yet very clear, so I decided to post this question.

Is it possible to call an external function (using Call Library Function Node with a dll) and run two applications (LabView and the external function) in parallel?

Moreover, is it possible to exchange data between these two different loops?

I attach a chart so you can figure out better this problem.

Thank you very much,

Francisco

[Ben]

Yes search for Client Server architecture that uses queues to pass info back-n-forth. Call your dll from one loop and put your LV stuff in the other.

Ben

[Porras]

Hi, Ben.

Thanks for your reply.

I don't know anything about Client-Server configuration in LabView. I've seen Understanding Client-Server Applications -- Part I and Part II. There, is explained an example using TCP/IP methods and is mentioned that it's not the best way to work in Client-Server applications, and that is better to use Datasocket or VI Server.

Could you please tell me a good resource link to learn about this topic (and, of course, useful for what I want to do)?

Thanks,

Francisco.

Mensaje editado por Porras

[Ben]

Take a look at the "Queue Basics.vi" that ships with LV. It shows how to pass data between loops/threads etc.

See also here and here.

Ben

[Porras]

Thanks again, really good resources.

But, I think there is one important aspect I haven't cleared enough. There are two loops, but one of them is inside the dll function. I mean, the first loop is in LabView, and the second is a "C++ while" loop contained into the dll function. I don't want the dll function to be entered, executed and exited every iteration of the second loop, but I want to enter it one time (at the beginning), to run it parallelly to the "LabView loop", and send to and retrieve data from this dll function.

More about this application:

In LabView, I have the force controls of 3D physical objects. They are also displayed in the front panel. 

Dll function deals with physics simulation and 3D collisions detection. It needs to create a "physical world", define objects, physical properties and so on... This is a initialization process that only has to be executed one time. Then, inside this function, there is a simulation loop, that gets data from the force controls (LabView), processes the information and returns the new 3D positions of the objects, that need to be represented in LabView again.

I don't think it is possible to remove the "C++ while" loop, change it for a while loop in LabView and execute the dll function each iteration, because the simulation process needs to be running continuously.

So, is it possible to run a dll function and send to and retrieve data from it while it is running?

Thanks,

Francisco.

[Jarrod_S.]

How does the C++ DLL expect its parameter data to be updated? Does it somehow expose the raw pointers to the parameter tables or something? If so, how does it expect to synchronize access to this data? Does it define any semaphores or anything? Was the C++ DLL really built to be accessed in such a parallel fashion?

If LabVIEW does know the address and data layout of data allocated by the C++ DLL, it can write to that data. But it is very dangerous to read and write to data at the same time with no control. And in this case, that control (in the form of a semaphore, or queues, or whatever) would have to come from your C++ DLL, because LabVIEW can't control how the C++ DLL accesses its own data.

[rolfk]

With the caveats as mentioned by Jarrod, while yo could do it the way you described, this is usually done a bit different. You have several functions into the DLL. The first spawns a thread to run on its own and passes this thread any intilialization parameters. Other functions are used to communicate through some means (queues, events, protected (semaphore) global variables, etc.) inside the DLL with that thread. One last function is used to send the thread an terminate event, so the thread properly shutdowns.

While your simple C loop seems easier in the short term, it does depend entirely on LabVIEW having a thread availalable that your DLL can sort of suspend as far as LabVIEW is concerned. This can work until you add more and more stuff to your LabVIEW application where at some point you saturate the available thread pool in LabVIEW and get into performance issues since the application is starving for thread resources.

[Ben]

Threadconf (?name?) will let us configure the number of threads.

It is Is it possilbe to turn things inside out and wrap the queue operations in a dll which in turn is called for the C++ dll ?

Ben

[Porras]

Hi, all.

Dear Rolfk,

let me see if I have understood what you stated. I've attached a flowchart with the ideas: the C++ dll includes an independent thread with the calculations and the simulation loop, and different functions for certain tasks (Initialize, Communicate and Stop Thread) that control this independent thread. This functions are called from LabView via Call Library Functions Nodes. The Communicate function, the one that sends and retrieve data from the independent thread loop, is called every cycle by LabView.

The dataflow would follow this route:
Join controls --> sent parameters as arguments for Communicate function (dll) via Call Library Function Node --> send parameters inside the dll (queues, for example) to Physics Engine --> dll simulation loop --> obtain parameters from Collision detection --> send them to Communicate function (queues, for example) --> send parameteres to LabView as returning values of Communicate function --> check for alarms (Generate alarm) --> correct settings (Join controls) ...

So, does it mean that is not needed to deal with read and write problems between LabView and the dll, because the data is exchanged via a simple Library function node called every LabView execution cycle?, and that these problems only have to be treated inside the dll (between the independent thread loop, and the Communicate function)?

Thank you very much, your support is invaluable,
Francisco.

PS. Happy Thanksgiving for American people 🙂

[rolfk]

The scheme you describe is indeed what I had in thought myself. That is the most logical, albeit maybe not necessarely the most trivial setup, to tackle the problem as you described it. PErsonally I think it is at least discutable if you need to do anything in C at all, but if this is the decision you have made, then I would go for the setup as you described it in your post.