From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
How to Create, delete and save DAQmx task programmatically
Solved!
What sort of code do you use in your project? How exactly do you want to control it?
You can definitely do this using for example an OOP hierarchical structure, but it might be as simple as having a few different SubVIs which you can put in a case structure and toggle via Enum Control on the front panel. This could later be extended to a Class based system (in the OOP sense!) if you wanted to make it more robust.
Work out (and if you want, tell us) what sorts of inputs and outputs you have from your device, in each configuration. Determine how much things change from one type to the next. Perhaps you have already some 'scaling' style subVIs which convert the raw measurement data into a unit that is more useful for your graphs or display formats. Maybe you do this with the built-in scaling options.
Once you know what the ins and outs should look like, it becomes easier to determine what you need to put inside your 'black box', which is effectively what you're trying to create when you have code that changes between different types transparently to the user.
I think it sounds like you should definitely consider an object-oriented approach. Have you previously used any object-oriented code, either in LabVIEW or another programming environment/language?
The idea here would be to define some overarching class which defined an API, or Application Programming Interface, with VIs like "Initialize", "Make Measurement", "Close" and similar. These should be things that all of your different measurement types do - so they might be quite generically titled.
Then, you create a different child class for each type of measurement: Voltage, Current and so on. These classes implement overrides of the same VIs defined in the parent class, but now the VIs are no longer generic - they have specific code to make that measurement, or to initialize that type of measurement, and so on.
On your main VI, you can then have a case structure wired to the enum, and in each case you only need to provide a Class Object constant corresponding to the appropriate child class. The wire type will be of the parent class, but the actual object will be a specific child. You then wire it into Initialize.vi, or Measure.vi, or Close.vi, and those VIs are dynamically dispatched - the code chooses which method to call based on the specific type of the object wired into the method.
Child classes can have additional VIs that are used inside the API - these are typically private methods that shouldn't be directly called in your main VI. They might including things like "Convert Counter Measurement to RPM.vi", or similar - this makes sense for a counter measuring RPM, but for an analog input channel connected to a DMM, it would be ridiculous. You could put calls to these kind of specialized VIs inside the Measurement.vi, to make the appropriate output without needing to have enormous block diagrams.
National Instruments has an online training course that's available with (some?) active SSP subscriptions - if you have access to this you should take a look. It's categorised as one of the more advanced modules.
If you don't want to use OOP, then I suppose you'll need to make do with duplication of case structures everywhere.
If you put each operation into a subVI that takes the enum as one of its inputs, then you can at least have reusable SubVIs, but really by that point you're 90% of the way to OOP code. The advantage is if you're careful in the way you write the SubVIs then you can write a non-OOP program and convert it later if you want to using more or less copy and paste.
