My DAQ app uses "Plugins". A Plugin is a VI which conforms to a particular terminal configuration.
Here is the complete diagram of a simple one:
The idea is that a plugin is another channel: This one takes the value of TORQUE (in N-m) and the value of SPEED (in RPM), performs some computation, and produces a result POWER (in kW).
The user can then think of this as just another channel - it shows up in the datastream and the user can plot it, record it, set alarms on it, convert it to an output and send it out the CAN bus, anything he can do with a real channel, he can do with this plugin channel.
So the above is exactly equivalent to having a POWER transducer.
They can get much more complex than this.
My code organizes these so that the prerequisite channels are run first, and then the dependent ones. (a prerequisite channel could also be a plug-in).
If plugin B depends on plugin A as a prerequisite, I make sure that A runs first, regardless of which comes first in the CONFIG file.
So the actual DAQ code samples the hardware channels, and then the plugins in a particular order.
The DAQ is sampling at 10 Hz, and so these plugins run at that rate too. There may be 100 different plugins, maybe 50 at a time in one test.
The DAQ runs on a PXI box, running RTOS. The host is an ordinary PC, running Windows.
Even though the PXI is running a compiled RTEXE, it still loads the source-code VIs and runs them.
My data file includes all the recorded data, all the config stuff used to set that up, AND THE PLUGIN VIs THEMSELVES.
The plugin VI files are read as strings and stored in the datafile as strings, along with their names.
When reading a data file, I read this string, and store it in a "sandbox" folder with a .VI extension.
This guarantees that the version I have is the version the data was originally recorded with.
The user can EDIT the data files, for example changing the scale factor on the SPEED channel from 307.3 RPM/V to 308.5 RPM/V.
That causes a re-calculation of the SPEED channel.
It ALSO causes a re-calculation of the POWER channel: My code detects that POWER depends on SPEED and since SPEED changed, I have to run every sample back through the POWER VI to get a new value. (Remember they're not all as simple as this example).
THAT is why the VIs are stored in the data file.
ALL OF THAT WORKS.
100%
Like a dream.
For 8-9 years now.
EXCEPT...
When it comes time to change LABVIEW versions.
MY client has 10,000+ data files, each with 5-50 VIs embedded. Files are spread among 30+ machines, with a central server backup.
We need to hang on to this data.
I have a File Updater, which will take datafiles and update them (they are a DataLog file).
THE TROUBLE IS:
If I take a recent datafile, recorded with LV2010 (where we've been for 3+ years) and open it with the EXE built with LV2013, there's a problem if it tries to reprocess it. The error comes out as
Error Code 1126 occurred at Open VI Reference in HDT Open PlugIn.vi->HDT Find Calc Prerequisites.vi->HDT DataFile Prerequisite Manager.vi->HDT DataFile Viewer.vi->HDT.vi<APPEND>
An error occurred loading VI 'BSFC.vi'.
LabVIEW load error code 10: VI version (10.0) is too old to convert to the current LabVIEW version (13.0).
The EXE code, having no COMPILER handy, cannot use the old VI.
My FILE UPDATER, has a recompiler built into it (it reads the VI string, saves it as a VI file, opens it as a VI, saves it as a VI, then reads it as a string and puts it back where it belongs.
But if THAT is built into an EXE, it doesn't work either. Same problem, same error.
If I run the FILE UPDATER from the LV2013 DevSys, then it's OK. The re-compile process works fine, and then the EXE can read it and use the VI.
BUT:
1... That's painfully slow. I have a cache handler where I recompile each VI only once and recognize it if I see it again, but still it's a long process.
2... That doesn't work from an EXE. My client has 2-3 DevSystems and 30+ computers with just the EXE. But that's where the data files are.
3... Backup up Data Files on CD or DVD doesn't work.
SO............ TO make a long story even longer.......
I'm looking for an alternative.
REQUIREMENTS:
1... String-based, I suppose. I want to type in "Power = Torque * Speed / 9545" and have the code know to fetch the value of "Power", the value of "Torque", do the math, and produce the result.
2... Has to execute quickly. I have a zillion things to do at 10 Hz.
3... Has to be able to re-order itself. If I have ANOTHER plug-in channel called Fuel per Watt, and it calculates "FuelPerWatt = FuelFlow / Power * 10.34", then it has to know to execute POWER before it executes FUELPERWATT.
4... Musr work from an EXE and an RTEXE.
I've looked at a thing called MathToG, and it works OK for creating a VI from an equation, but it needs VI scripting, and therefore won't work from an EXE
Any ideas?