LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best method to send/receive data to/from a LabVIEW packed library (lvlibp)

Hello,

I surfed a little bit on the net and used the Instrument Driver Project template. Then, using also the information you provided, I updated the previous version of the project, that now consists in two sub-projects, "HMI" and "Driver" (find them in the attached zip file). I ask you to please check the correctness of the method, in particular concerning the public API in the driver project and the "HMI_main" code in the HMI project.

 

Possible problem: in the HMI, the control "Data in" allows to set the period (in milliseconds) of the "Driver_main" loop in the execution state. Looking at the "Data out" indicator, it seemes that the lowest value that can be set is about 10 ms. Below that value, the indicator does not increment at the rate set with "Data in" control. This could be a clue that indicates a performance problem. Do you agree with this?

 

In general, for my application, performance is a major aspect to take care of. Following the suggestion about switching to OOP, I benchmarked (by adding some tick counters) the task approach VS the object approach found in the Board Testing example. The task approach is about 20-30 % faster than the object approach (1700 ms VS 2500 ms). Do you think that this result can be generalized when comparing task with object approachs?

 

Thanks

0 Kudos
Message 11 of 14
(702 Views)

There is no point in having your "Driver_" VIs in the HMI project.  Just call the VIs directly from the lvlibp.  You do not need to handle dynamic calling of them.  Just have the driver developer create the API and hand that over the the HMI developer who can use it directly.  When you update the PPL, the HMI code will not need to change unless you changed a connector page of one of the public API VIs.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 12 of 14
(695 Views)

Yes, in this case there's no need to call driver VIs dynamically, but in the final version of the application I'll have to manage different drivers which have the same public API. The idea is to allow the user to use the different drivers by simply selecting the different libraries paths. Attached a new version of the project which allows the use of multiple libraries. Can you just confirm me that the one I used is the right method to call driver VIs dynamically?

 

And what about performance issue?

 

Moreover, to avoid errors, I was forced to build the driver twice (in Driver\Builds, "Driver.lvlibp" and "Driver2.lvlibp"). Is it possible to use multiple instances of the same library?

 

Thanks

0 Kudos
Message 13 of 14
(687 Views)

@aRCo wrote:

Yes, in this case there's no need to call driver VIs dynamically, but in the final version of the application I'll have to manage different drivers which have the same public API.


This is where OO will make your life a lot simpler.

 


aRCo wrote:Moreover, to avoid errors, I was forced to build the driver twice (in Driver\Builds, "Driver.lvlibp" and "Driver2.lvlibp"). Is it possible to use multiple instances of the same library?

That depends on how you built your driver.  You could make the parallel driver loop VI reentrant, and then you can initiate multiple instances of it.  You will need to handle which instance you want to talk to in your API then.  That could be done with a string lookup or just using private data in a class.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 14 of 14
(684 Views)