is it possible to design Labview applications in a kind, that it is possible to generate "demo versions" of it ? Demo version in the means of feature-limited crippled versions of a full instrumentation software, where SOME hardware access is denied, but you can load and view and analyse data.
Of course it might be useful to compile this demo version with the Labview Application Builder,
What might be the business modell for demo versions: A hardware manufacturer creates a Labview application which controls the manufacturer's components, and allows instrumentation and data recording. The application is not free but sold for extra money.
As pre-sales benifit, the manufacturer would like to send the (compiled) Labview application to future customers.
Now the problem is, that the customer has not (all) the external devices or PCI/USB devices, on the other hand the hardware manufacturer does not want to give the "full application" as gilft to the customers.
Now with traditional software development with C++, Java, C#, either a demo version is gained from the full version by replacing some module with hardware access by modules wth "empty" function body or with function body which return constant values instead of accessing the hardware.
In the world of process industry, usual process control systems may supply "alternative" values if the original device is not available.
What kind of software structure must I build with Labview, to do the same ?
Now the problem with Labview applications is
Labview applications depend on drivers. Drivers depend on hardware.
So if the FULL commercial version of the Labview program accesses a DAQmx driver, GPIB driver or any other hardware driver by a VI, and often this means that a special manufacturer VI is used in the Labview program which does the actual hardware access,
how to modify the software to make a demo version a) so that IF the customer buys the hardware and gets the hardware driver, he still does not have the full version b) so if the customer neither has the hardware nor the driver, he still can run the Labview software and load an view data, push buttons, can execute menu items even can manipulate data ect, can use the manufacturer's VI ?
Unfortunately, it is no solution just to delete "some" of the VIs with hardware access from the distribution of the demo version, as this just causes error messages during the loading of the (compiled) Labview demo application.
Message Edited by hemmerling on 01-11-200712:35 AM
Message Edited by hemmerling on 01-11-200712:37 AM
Anyhow, as such "suspended" VIs are often the *source* of signals, so there must be an addtional method how to provide "alternative" signals for the demo version, which does not make the administration / further development the full version too complicated...
For example: The VI for an external signal generator device is disabled, but alternatively it would be nice if the users of the demo version can get a fixed sinus signal instead... How to do that with Labview and the "Conditional Disable and Diagram Disable Struktures",
and can I test this all even without Labview Application Builder, in the full development system ( so that I don´t need the compiler for frequent checking ) ?
Btw, with what version was this "Conditional Disable and Diagramm Disable" feature introduced ? Is ist already available with Labview 7.0, /.1 ?
Sorry, in lv7 only the constant disable structure is available for FPGA, maybe dynamically calling VI's might be something. Use a name structur like: FunctionA_demo.vi FunctionA_Hardware.vi FunctionA_Full.vi
I got a demo version, a compiled Labview 7.1 program, and when starting, the Labview 7.1 Runtime looks for a DDL FPLVMgr.dll
but doen't find it, and complains about that the VIs FPopenVI
Then the application starts, with the menu screen, but starting the action in the activation by clicking on a "run" menu item, this causes the error messages "Missing subVI FP Open.vi in VI Test Initialisierung.vi
Missing subvi FP Create Tag.vi in VI Test Initialisierung.vi"
( Initialiisierung [german] = Initialisation ) So is this a goo or bad example of a "demo made with Labview" ? Maybe the FPxx stuff for a Fieldpoint device.