Sharing variables between llbs or lvlibp in

[littlesphaeroid]

I am designing my first test sequencer using dynamic dispatch to load and run tests. I thought I would deploy my tests as vilibp (packed vi library) files, but I have a few problems.

1. I use globals (or an equivalent) to store confiuration and communication variables, which are read from an ini file. 

2. Some tests produce data that are used by subsequent tests. I have been using globals to store those values as well.

I am not interested in a discussion of the merits of global variables in their various incarnations. This question is about how best to share data between my calling applicaiton and the test modules, and between one test module and another. 

I can also deploy my tests as .llb files, which I think will allow me to handle the above test cases, but for which I will have to be more careful about file naming. (I belive the scoping of vilibp's is such that you can have duplicated vi names, and this does not apply to llbs).

Thanks!

[gdrag]

Could you tell me more about what exactly you are trying to do? It is a little unclear what the exact question is.

Are you trying to pass data through diffrent .llbs or through different VIs in one single .llb?

What "test modules" are you using?

[littlesphaeroid]

Hi Galin,

I am making a test sequencer. The tests are called dynamically from some sort of code library, so that tests are standalone bits of code separate from the sequencer code. I need to pass data from test to test and/or from the main application to the test. Mainly the former. So, for example, if a test initializes some hardware, the hardware settings (com ports, AI channels, etc) can be used by subsequent tests. I am currently using globals for this sort of static configuration data, but I don't think that is possible with vilibp's. I think it is posisble with llb's.

Basically I'm trying to figure out the best approach so I can hone a test template.

[gdrag]

It's easiest to just pass the data with wires.  You can just include the tests as Sub VIs in your main VI, and pass data into and out of it using wires, which would be the most reliable way to transfer data.  Is there a specific reason that won't work?

Also, is there a specific need for a packed project library or a llb?

Also, you may want to look into TestStand. It may be a product you find helpful if you are interested in building a test sequencer: http://www.ni.com/teststand/.

[littlesphaeroid]

Thank you for your reply, even though it's entirely clear that you did not read my post or understand my application. 

having someone form Ni post a reply like this is slightly less than cool. This is not a sales forum. 

[Tanner!]

In gdrag's defense, TestStand is built from the ground up for the exact use case that you're defining. I don't think it was a sales pitch so much as questioning whether you're using the right tool for the task at hand.

That said, if I were approaching your design problem I would use an object-oriented approach to this. If you were to create a abstract class--for arguments sake let's call this Test.lvclass--that includes common test data and defines a set of common functionality that any Test in your system must implement, you can then create child classes from Test that are concrete implementations that override the Test class for their specific instance. This would give you a modular and expandable framework and a means of encapsulating data that allows you to work at the Test level but define individual implementations for an individual test.

Packed Project Libraries have a unique namespace from the application that uses them. This creates several advantages and disadvantages. Like you mentioned, you don't have to worry if you have two VIs with the same name, they are two separate instances. The other side of this coin is that the global variable in your PPL can only share data with other VIs in that PPL.

I'm unsure what the use case would be for not directly passing data between sequential steps using dataflow. If you provide us more information about what the purpose of passing data asynchronously between two sequential steps we're happy to brainstorm other solutions.

[Tanner!]

Additionally, here's a good paper on Designing LabVIEW Applications Using Plugins for Scalability and Flexibility

https://decibel.ni.com/content/groups/large-labview-application-development/blog/2011/05/08/an-appro...

[littlesphaeroid]

Thanks Tanner. I find that TestStand is overkill for our purposes, costs a lot of money for deployment (we depoly on dozens to hundreds of testers), and has a significant learning curve that our all LV shop wants to avoid if possible. For our reduced set of testing needs, a custom solution seems appropriate and not terirbly difficult. And I'm just plain interested in doing it.

Your suggestion to do an object oriented approach is probably the best solution, but probably will not be our first-pass solution. I find that a majority of LV developers do not have OO skill and experience, and a great deal of additional training would be required to bring that solution online with our group of developers. But I'm aiming that way.

Hence the basic choice I'm currently making. It looks like llb's, which I thought I'd never use again, are the best choice where using globals (or their equivalent) is desirable. Since the llb's are only a method for test deployment, I'm open to them for this purpose.

Here's an example of passing data from one test module to another: Test A gathers device serial numbers from a barcode scanner. Test B reads serial numbers for device memory and compares to values gathered in Test A. No other test needs this Test A data. There are many ways one could pass the data, such as writing to a temporary file. I use a global, as it is a write once/read once operation. It's safe and effective. I have also considered passing the data around on a variant wire, allowing any test to put data on the wire, and any subsequent test to read from the wire. But this has, again, some training difficulties and seems harder to manage. It's certianly not transparent from the perspecitve of someone writing an atomic-level test.  I'm not sure how this would best work in a OO approach.

Thank you for the link to the white paper. I'll have a look!

[RavensFan]

Why not use a system to pass data that doesn't rely on the VI's, globals, or how you package them as to whether they work or not.  Perhaps it's as simple as writing data to a file that other the other test modules can open and read?  It sounds like there is a sequential nature to the test modules, I think you'd want to store the information someplace that has some longevity beyond just the memory in the PC while the power is on.

Since you are talking about dozens to hundreds of test stands, which implies a larger amount of tests and datasets, it sounds to me like you should be storing this data in a database that each module can access when it needs to.

[Sam_Sharp]

I think it's that 'time of year' at NI when they get a fresh batch of AEs and they are let loose on the forums!

I've played with PPLs a few times and the transfering of data can be a tricky part. In fact, there's a good method for distributing Teststand code modules where you build PPLs which are then called from within TestStand.

I think the best information I can give you is from this presentation: https://decibel.ni.com/content/docs/DOC-42910

In short - you can wire in references (e.g. queue/user event/DVR) into the PPL and use them to pass data to/from the calling application. Be careful about the type definitions as they are namespaced and therefore you might run into some 'kinks'.