black box application

[User002]

Okay that seems like what I am trying to do. I imported a shared library file from the .h files which contained all the necessary functions. Am I correct that you are saying to take these functions and implement them in a driver so that a user would be able to interact with the driver, which would be like setting certain values, or if the output is not desired, telling the hardware to create a pre and post trigger on the data collected?

[mr_builder]

One alternative  option that I can think of is having your Main VI with the BlackBox Loop that starts doing its thing once called. And a Seperate set of VI's to send or receive commands to your Main VI by a send and receive queue.

The user call's the Main.vi. and then uses your Instruction VI's to send commands.

Internally in your Main.vi you have maybe a while loop with a case structure for the statemachine, and you handle your device while also checking for any incomming messages in the queue.

- User still does not have to know the internally functionality of the blackbox

- User can still interact with the blackbox while it is running.

Commands can be :

- Get Status

- Stop Loop

- Set Output 

Even better ( more advanced ) would be to "start" your Main VI by reference so that it is running like an "engine" instead of calling the VI in code. When called by ref you don't have to wait until it is done and can continue with other things.

Even more more advanced - Setup you Main.vi engine to start as a clone which would allow multiple instances of your device handler ...

[Dennis_Knutson]

Instrument Drivers have been around since the beginning of LabVIEW and have not changed much except for how they are packaged. The shipping example for the 34401 DMM from Keysight is a perfect example. It starts with an initialize function to establish communication. Then there are set-up functions (measurement type, range, etc), reading functions (single, multiple results, etc), and then a close to terminate communication. All LabVIEW users should be familiar with the concept when using external instruments.

Most drivers use fairly high level communication such as VISA for serial, Ethernet, USB, PCI, or GPIB communication.

[Sam_Sharp]

---

@User002 wrote:

Okay that seems like what I am trying to do. I imported a shared library file from the .h files which contained all the necessary functions. Am I correct that you are saying to take these functions and implement them in a driver so that a user would be able to interact with the driver, which would be like setting certain values, or if the output is not desired, telling the hardware to create a pre and post trigger on the data collected?

---

Pretty much yes.

mr_builders suggestion is also perfectly valid - if you need to continuously communicate with the device, or you need to perform more advanced actions, then launching an asynchronous process as part your 'start' or 'initialise' VI is perfectly valid. You would then create VIs which use a communications method (e.g. message queue) that the user of your library can put on their block diagram to retrieve the data.

[User002]

Basically this is my design flow:

Open device

While StartInput is off

              Set sample rate

              If TimeDomainEnabled is true

                           Set time domain parameters

              If FrequencyDomainEnabled is true

                           Set frequency domain parameters

While StartInput is on

              Wait until frames are available

              Read frames

When StopProgram is pressed

              Device closes

              Program ends

StartInput and StopProgam is a bool stop button control respectively. All the other things are functions from the .h file. I was planning on using a state machine for when StartInput is on or off. It will allow users to change values (for example changing the sample rate) while StartInput is off.

The device is connected via usb, but I do not need to do any implementation for this connection. It sounds like both methods would be viable for what I am trying to do. I am just trying to figure out which one would be better. It seems like that actions I am performing are not very advance. Mostly just allowing a user to change control values, set variables, and get the outputed data. What I am implementing is determining what is happening based on the control values, setting variables based on the user input, allocating memory, and error checking all of the implemented functions.

[User002]

I looked more in-depth at the driver tutorial and also looked at blackbox testing in labview (this is essential what I am doing). I have come to the conclusion that a turning my labview code into a subvi is the best for what I am trying to do.

[Sam_Sharp]

Black box testing is to do with software testing and has nothing to do with what you are doing. Once you have written your VIs, you could then use unit tests / use black-box testing to test that they work correctly.

[User002]

They would not be performing blackbox testing, but they would be interacting with the subvi in the same way as someone would if they were blackbox testing.

I think I am having a hard time trying to explain what I am trying to do without saying too much, but I hope you are able to understand the jist of it.

[Sam_Sharp]

Not really no - this is normally where you would hire a LabVIEW expert/consultant under an NDA to assist you with your project. It's hard to help if you're being vague.

[User002]

I am now thinking of it like a much more complex version of the square root subvi example where I will have no idea how the square root function is implemented, but I can input certain things, get the output, and even build my own application on top of it.