> Thanks for the comments and discussion , I am finding that by simply > discussing thhe issues I am gaining a much better understanding. >
Unfortunately, I still have very little information about what you are trying to do so my comments have to be heavily guess based. Let me describe a little bit about how LV and TestStand plug together and that is one possible way to mke things work for you. TestStand can operate in a standalone mode or pulled into a user program, anyway, it allows for calling to a VI to carry out a test. TestStand passes values into the subVI and initiates the call. One of the parameters is an interface for communications back to TestStand. This is used to gather additional parameters that aren't directly provided, or to update other values stored in TestStand, or to notify TestStand of progress. Sometimes the subVI doesn't use these mechanisms and it is a simple subVI call, but the capability is there and it is pretty simple for the subVI writer to take advantage of them when they are needed. If you have a very clear description of what you are looking for in terms of data in, data out, intermediate notifications, and synchronous versus asynchronous execution, you should try to state those clearly, even if just for yourself. This model will be the fundamental thing to define the interaction between your app and LV, and if it changes often, you will end up with lots of rework and most likely not very nice code. Another option you might want to consider. LV makes it very easy to do asynchronous tasks and to synchronize things later. If it allows you to simplify things, you might consider making a LV engine that deals with these things and you always call that from your C code, either synchronously or asynchronously. This hopefully means this interface doesn't change as much, but the LV to LV interface can offer more options and change more often without disturbing the rest of the app. Greg McKaskle
