How to handle interchangable VIs

[gustav]

Well, my problem is like this:

I have one (or in fact several) (sub)VI that read measurement data from specialized hardware. During development I want sometimes want to replace this VI with another one that has exactly the same interface, but gets the data from somewhere else, most likely a file. I might want to switch back and forth between those two VIs during development, but when deploying the application only the one that gets the actual measurement data should be available. I can see several ways to achieve this:

1) Use dynamic loading of the VI, deciding which one to load depending on some configuration constant or something.

Pros: Easy to switch

Cons: Seems a bit complex, in the deployed version dynamic loading would be used even though it is not really necessary. Also I'm worried that using dynamic loading could affect performance.

2) Have two versions of the VI, and a proxy VI that selects which of the VI's to use based on some constant. All calls are made to the proxy VI.

Pros: Easy to switch.

Cons: Adds an extra layer of Proxy VIs (could introduce a little overhead? ) . Deployed version will have to include also the 'fake' VIs ( allthough perhaps this could be avoided if the 'fake' VIs are loaded dynamically in the proxy VI? ).

3) Have two versions of the VI. For switching, close the main VI and replace the VI on disk.

Pros: No overhead or unneceasry code in the deployed version

Cons: Switching will be uncomfortable

None of these options seem really elegant to me, is there some other way that I have missed? Otherwise, which one does people think is the most effective/elegant ?

Thankful for any help!

/Gustav

[JDave]

2) Have two versions of the VI, and a proxy VI that selects which of the VI's to use based on some constant. All calls are made to the proxy VI.

Pros: Easy to switch.

Cons: Adds an extra layer of Proxy VIs (could introduce a little overhead? ) . Deployed version will have to include also the 'fake' VIs ( allthough perhaps this could be avoided if the 'fake' VIs are loaded dynamically in the proxy VI? ).

Why not modify #2 and instead of having a proxy VI, just use a case structure. Wire your constant or control to the case structure and place the appropriate subVIs in the appropriate cases.

Note: In LV8.x you can use a Conditional Disable structure so that all switches of this nature are handled at the project level.

David

[gustav]

Why not modify #2 and instead of having a proxy VI, just use a case structure. Wire your constant or control to the case structure and place the appropriate subVIs in the appropriate cases.

Because there are something like 10 different VIs that each would have to come in a different versions, and they are called in maybe 50 places in total. So that would amount to a lot of case structures if I put one in every place where one of the VIs were called.

Note: In LV8.x you can use a Conditional Disable structure so that all switches of this nature are handled at the project level.

Yeah, unfortunately this project is in labview 7.1 .

Thanks for your reply!

[Mellroth]

Because there are something like 10 different VIs that each would have to come in a different versions, and they are called in maybe 50 places in total. So that would amount to a lot of case structures if I put one in every place where one of the VIs were called.

Yeah, unfortunately this project is in labview 7.1 .

Thanks for your reply!

HI,

I think David meant that you could add a case structure within the VIs in question, not where they are being called.

This way your VIs contain both your development code and your release code.

You would still have to add some switch mechanism to select which case to use, maybe a GLOBAL (oops, did I say that, sorry ) that is set when you initialize your program.

/J

[gustav]

HI,

I think David meant that you could add a case structure within the VIs in question, not where they are being called.

This way your VIs contain both your development code and your release code.

You would still have to add some switch mechanism to select which case to use, maybe a GLOBAL (oops, did I say that, sorry ) that is set when you initialize your program.

Ah that does make some sense. Guess I could also put the development code in a dynamically loaded subVI if I dont want to include it in the release. Thanks .

[LAVA 1.0 Content]

Well, my problem is like this:

I have one (or in fact several) (sub)VI that read measurement data from specialized hardware. During development I want sometimes want to replace this VI with another one that has exactly the same interface, but gets the data from somewhere else, most likely a file. I might want to switch back and forth between those two VIs during development, but when deploying the application only the one that gets the actual measurement data should be available. I can see several ways to achieve this:

1) Use dynamic loading of the VI, deciding which one to load depending on some configuration constant or something.

Pros: Easy to switch

Cons: Seems a bit complex, in the deployed version dynamic loading would be used even though it is not really necessary. Also I'm worried that using dynamic loading could affect performance.

2) Have two versions of the VI, and a proxy VI that selects which of the VI's to use based on some constant. All calls are made to the proxy VI.

Pros: Easy to switch.

Cons: Adds an extra layer of Proxy VIs (could introduce a little overhead? ) . Deployed version will have to include also the 'fake' VIs ( allthough perhaps this could be avoided if the 'fake' VIs are loaded dynamically in the proxy VI? ).

3) Have two versions of the VI. For switching, close the main VI and replace the VI on disk.

Pros: No overhead or unneceasry code in the deployed version

Cons: Switching will be uncomfortable

None of these options seem really elegant to me, is there some other way that I have missed? Otherwise, which one does people think is the most effective/elegant ?

Thankful for any help!

/Gustav

Another possibility would be polymorphic VI's. If the interface is the same, you could use the equipment reference vs Path reference to get the write instance from the poly vi. If you have a shift register that you get your reference from you could initialize with path or Equipment reference depending on what VI's you want. When you do the build you have an option to not include unused VI's from the polymorphic VI.