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

[aRCo]

Hi,

I'm working on a project that consists in a HMI which should be able to send/receive data to/from one or more drivers.

Basically, the HMI consists in an compiled executable based on a VI named "HMI_main", whereas a driver consists in a compiled LabVIEW packed library (lvlibp) containing at least a VI named "Driver_main".

Here are two basic needs:

 - Improve the code maintainability. The HMI code should be completely independent from the driver code and the other way around.

 - Reduce the integration effort. The only thing the user must do to make use of a driver is to specify the lvlibp file path before to start the HMI.

In your opinion, which is the best method (in terms of ease of implementation and optimization of performances) to exchange data between the HMI and the driver?

Thanks!

[crossrulz]

Just call the driver VIs directly from the PPL.  When you have driver updates, you just have to update the PPL and rerun the main application.

[aRCo]

Thanks crossrulz for the answer.

Attached, a zip containing a possible implementation (LV 2015 and above). In this case, the "Driver_main" VI relais upon a set of variables stored inside a VI named "Driver_globals".

Is the method "Get/Set Control Value" by name and VI reference the only one to get/set the value of a global? Can the use of globals affect performances negatively? Which could be the advantage to use (and call) locals directly on the "Driver_main" front panel?

[crossrulz]

1. You will need your driver to be in a separate project.  In your HMI project, you have the PPL that you built from the driver project.  If you don't do this, the HMI executable will have VIs from the driver library and will not look at the PPL you are building.

2. Setting the front panel controls on a parallel VI is just a bad idea.  Assuming your driver VI actually needs to be constantly running (very few actually do), make public VIs for your driver that your HMI VI accesses.  These are your API.  Inside of those VIs, I recommend using queues to send data back and forth.

[aRCo]

Hi crossrulz,

for info, any driver will be constantly running, producing and consuming data with a custom rate.

Then, in your last post you wrote: "In your HMI project, you have the PPL that you built from the driver project". This does not match with the first need.

The fact is that I would like to avoid, during the developement phase, any kind of interference between the developer1 (the one that develops the HMI) and the developer2 (the one that develops the driver).

In other terms, the builded HMI (named for example "HMI.exe") should be able to call directly any newly builded driver (named for example "Driver-X.lvlibp") without the obligation to be rebuilded by developer1.

This means that a standard interface should be defined between developer1 and developer2 to allow the exchange between the HMI and the driver. For example the developers could decide to name the variable that contains the data sent to the driver "Data Var In" and the queue that contains the data received from the driver "Data Queue Out".

Coming back to the previous question (slightly modified), is the method "Get/Set Control Value" by name and VI reference an efficient method to exchange data between HMI and driver?

[aRCo]

Here an example of the "Control value:Get" method called inside the HMI

[crossrulz]

---

@aRCo wrote:

Here an example of the "Control value:Get" method called inside the HMI

---

Again, I do not recommend doing that.  All you need is for somebody to change the label and everything breaks.  Use queues inside of a public API that the driver has defined.

[aRCo]

Thanks Crossrulz,

probably I miss the "Use queues inside of a public API that the driver has defined" concept.

Ok for replacing globals with queues (if the developers name the queues in the same exact way), but what is for you a "public API that the driver has defined"? In what does a public API consist practically? And how can the HMI acces it dynamically during run-time by only knowing the driver library path?

[tyk007]

I agree with crossrulz on this. While it sounds like a good idea to just try and reference controls/indicators by name you are actually still binding to an API (by names) just ones that are not properly typed. So your developers, in this scenario, still need to agree on what names mean what and additionally what their data types are. The only advantage you get with this technique is that the connector pane assignment is not required to be known - but frankly if you need to know all the names and data types anyway the connector pane is just semantics to enable connection via data flow in which case you can agree on this up front too (since its probably less likely to change compared to names and types).

I suggest that the developers agree on an interface for the call to driver (its public API). The developer working on the 'driver' creates VIs that represent this API but contain no logic on the block diagram and then builds the PPL. The second developer working on the HMI uses this prototype PPL and its public API members in their code, knowing that calls to these PPLs will initially produce no results. Then the driver developer is free to continue developing, occasionally passing on new builds of the PPLs to the HMI developer as functionality is implemented.

If you want to get 'clever' you could try OOP here and have each driver API implement a common interface. You could then programmatically load in an instance of the driver class from the PPL file and treat it as a subtype of the common interface (search for the LVOOP Factory pattern via Google).  I'd suggest though, given drivers likely wrap different hardware, you'll probably find that each drivers API will have some differences. In that instance you might find you need to relax your interface APIs (such as adding in variants instead of typed data). I would only go this route if I thought that, at runtime, I would need to substitute one driver PPL with another (by filename) for the same type of hardware. In my experience I have found this need to actually happen far less than I originally supposed and ended up releasing a new application build either way, defeating the extra effort.

[crossrulz]

---

aRCo wrote:

Ok for replacing globals with queues (if the developers name the queues in the same exact way), but what is for you a "public API that the driver has defined"? In what does a public API consist practically? And how can the HMI acces it dynamically during run-time by only knowing the driver library path?

---

1. Do not name your queues.  I have seen this cause all kinds of issues.

2. The HMI developer should never see the queue.  The public API VI will have whatever parameters that specific task needs and handles all of the communications with the parallel process.

3. Just directly call the public API VIs from the PPL.  You will just make things way too difficult on yourself if you try to get in with dynamic calling.