Re : dynamic vi

[MouradBen]

Voilà je suis nouveau à LabView et j'ai besoin d'un avis sur la faisabilité de ce que je veux faire en LabView avant que je m'embarque dans un long apprentissage!

J'ai besoin de créer un VI principal, paramétrable à l'exécution. Selon les paramètres de ce VI principal, il va charger un ou plusieurs sub-VI (semblables ou différents) dont il a besoin pour réaliser sa fonction. J'ai besoin que le VI principal puisse accéder aux données de ces sub-VI (en lecture et/ou écriture). 

Quelle est la meilleure approche pour réaliser ce genre de solution?

Merci

[MouradBen]

-------------

I am new to LabView and I need an opinion on the feasibility of what I want to implement in LabView before I embark on a long learning!

I need to create a main VI, configurable at runtime. Depending on the parameters of the main VI, it will load one or more sub-VI (same or different) it requires to perform its function. I need the main VI to access the data of thesesub-VI (read and / or write).

What is the best approach to achieve such a solution?

thank you

[DFGray]

There are several options, all would work well, but all require some advanced knowledge of LabVIEW.

1. Your main VI is a shell containing one or more subpanels.  At run time, depending on the code you wish to execute, you load the correct subpanel(s).  You can find an example of subpanels here.  You may want to read the previous part of the series first.
2. If the functionality change is bounded and you know it will stay that way, you can add all the controls you need to a single front panel and show or hide them (using VI server) depending on the functionality you want to achieve.  This is probably a simpler method, but does not scale well, so avoid it if you do not have strictly bounded functionality needs.
3. Your main VI is a splash screen which launches another VI based on a configuration file.  This is similar to the first idea, but a bit easier to implement.  It makes it harder to dynamically switch functionality without relaunching, however.

The first option is the most scalable and reusable, but also requires the most LabVIEW knowledge.  Give us some more info on your application so that we can make more specific recommendations.  There are other options than those above, but they are more special purpose and will depend on your application.

[MouradBen]

Here are more details about what I want to achieve with LabView.

The problem:

In order to complete a test platform, I need to simulate some hardware, which is roughly Modbus Slave. This hardware is modular, so its Modbus table is changing with the kind of module you put in there.

The solution:

I split my Modbus Slave model in data structures that are similar to the real modules.

-          VI_Card witch will have these parameters: Type (IN/OUT/DATA_TYPE), Nb_Ch (int), Data_table (array of DATA_TYPE), Start_@ (int)

-          VI_Rack witch is composition of VI_Card s, and have these parameters: @IP, Node, List of VI_Card, Data_table that is the composition of all the data_tables pf the VI_Cards.

-          VI_Duplex_Slave witch a super-ensemble of two VI_Rack with logical coupling (whena data changes in one table, it should change in the other table) between the two Modbus tables of VI_Rack

In my readings, I found that a LabView’s VI can have Sub-VIs, so, I thought may be it will be easy to implement my solution in LabView. But I soon realize that I should load the sub_VIs dynamically depending on the configuration file of my Modbus Slave I want to simulate.

I hope this is clear enough. (I will try to add a schema). 

PS: I think your third proposition is very interresting, and should be enough to solve my problem. Have you some tutorials, examples showing how to implement this?

Thanx

[DFGray]

If you need to change which module you are simulating at run-time, option 1 would be best.  Otherwise, go with option 3.  The example I pointed you to above is one of a series about using dynamically called VIs/subVIs.  It should give you the info you need, with examples (read all the posts, I missed some code in some of the original posts, so the first example will not work; corrected farther down).

[MouradBen]

Thank you,

One last thing, I want just to be sure that with this implementation I can have multi-instances of the same sub-VI, the number of instances is dependent of the configuration file, running in parallel under the same master VI.

[DFGray]

Yes, you can.  The trick is to make your subVIs reentrant.  I believe the example shows this.  Also make sure that your subVIs do not access any common state data, such as globals, named queues, etc.  The subVI copies need to be truly independent.  I got burned by this many years ago, so typically limit my state data to wires in shift registers and data value references.  You can also use dynamically launched reentrant action engines, but data value references will outperform them in most cases and you still need to pass a reference wire around.