Design advice needed for data acquisition system

[brownx]

18 minutes ago, ShaunR said:

The caveat here is that there was already a device VI to wrap.

This a similar technique to VI Package Manager which runs the pre and post install VI's.

I have device VI and we are already using it from Teststand. The new requirements however are asking for multiple devices loaded in the same time and also multiple scripts run in the same time - I have a sort of a solution right now but it is a pain to scale thus I need something better.

It's not enough to just read values directly from TS like a DMM would, i have background maintenance tasks too. For a project tried to do all from Teststand - painstakingly slow comparing to a simple labview loop, not comparable with C++ ...

[ShaunR]

24 minutes ago, brownx said:

I have device VI and we are already using it from Teststand. The new requirements however are asking for multiple devices loaded in the same time and also multiple scripts run in the same time - I have a sort of a solution right now but it is a pain to scale thus I need something better.

It's not enough to just read values directly from TS like a DMM would, i have background maintenance tasks too. For a project tried to do all from Teststand - painstakingly slow comparing to a simple labview loop, not comparable with C++ ...

The trivial answer is the launcher can be run re-entrant so you can run it from multiple scripts with different configurations etc  But what you are trying to achieve, from your description, is a poor fit for Test Stand, period. So I expect there will be other things that that perhaps you haven't mentioned (like the background tasks) that will make it difficult to use from Test Stand regardless of the solution. It sounds like you really need an entire application rather than a simple Test Stand integration. 

Edited September 30, 2020 by ShaunR

[brownx]

14 minutes ago, ShaunR said:

The trivial answer is the launcher can be run re-entrant so you can run it from multiple scripts with different configurations etc  But what you are trying to achieve, from your description, is a poor fit for Test Stand, period. So I expect there will be other things that that perhaps you haven't mentioned (like the background tasks) that will make it difficult to use from Test Stand regardless of the solution. It sounds like you really need an entire application rather than a simple Test Stand integration. 

For what else a Teststand script is good other than testing something? Whatever we test it is necessary to create environment which can control voltages, sensors, buttons, leds, multiplex signals - all of those exists in the NI hardware world too, they are used from Teststand but in many cases we need custom components ... Nothig special in it - most of the testing equipment is built this way ...

[LogMAN]

From what we have discussed so far, the Messenger Library certainly seems to be a perfect fit. It'll provide you with the infrastructure to run any number (and type) of workers and communicate with them in a command-like fashion. It is, however, a much more advanced framework than the simple message handler from my examples. As such, it will take more time to learn and use properly.

1 hour ago, brownx said:

this stuff will be used by Labview programmers - they need to be able to maintain it, slightly modify it to taylor it to their needs.

As someone who enjoys the company of technicians who get scared by things like "classes" (not to mention inheritance 🙄), I strongly suggest to evaluate the skill levels of your maintainers before going too deep into advanced topics. If nobody has the skills to maintain the solution, you could just as well do it in C++. Perhaps you can include them in the development process? This will make the transition much easier and they know what is coming for them.  If they also do some programming, they have nobody to blame 😉

@drjdpowell already mentioned his videos on YouTube. I really suggest you watch them in order to understand the capabilities of the Messenger Library 

Here is also a link with more information for the message handler in my examples (sorry no video, +1 for the Messenger Library): http://www.ni.com/tutorial/53391/en/

[ShaunR]

1 hour ago, brownx said:

For what else a Teststand script is good other than testing something? Whatever we test it is necessary to create environment which can control voltages, sensors, buttons, leds, multiplex signals - all of those exists in the NI hardware world too, they are used from Teststand but in many cases we need custom components ... Nothig special in it - most of the testing equipment is built this way ...

A very complicated reporting tool.

Some things are better for scripting/sequencing than others. Take the step response of an oven, for example. You need to step change the setpoint (SP) and monitor the temperature until a certain value has been achieved as it changes and note the time taken. To determine whether it has finished it's step, you detect the plateau in rate of change. In an application this is trivial and the test time is the time it takes to achieve get within +-% for n secs of SP or when dtemp/dt < x for n points (depends on specification). It is usually also monitored to determine whether it overshot before it got there (which may be a fail).

In Test Stand it is orders of magnitude more complicated to achieve the same process and you will probably try to wait x amount of time and hope that the temperature is achieved. However. You will miss the overshoot and that's not the test anyway. So you will write some software to do the state monitoring and calculate the rate of change and, now, you are using Test Stand just as a reporting tool. Test Stand is good for "stateless", pass/fail testing and suffers the same problems as any other scripting/sequencing environment when state and/or continuous monitoring is introduced. It may be that it has served you faithfully for the most part in your testing but it is not a test panacea which, I think, is why you are asking the question.

[brownx]

8 hours ago, ShaunR said:

A very complicated reporting tool.

Some things are better for scripting/sequencing than others. Take the step response of an oven, for example. You need to step change the setpoint (SP) and monitor the temperature until a certain value has been achieved as it changes and note the time taken. To determine whether it has finished it's step, you detect the plateau in rate of change. In an application this is trivial and the test time is the time it takes to achieve get within +-% for n secs of SP or when dtemp/dt < x for n points (depends on specification). It is usually also monitored to determine whether it overshot before it got there (which may be a fail).

In Test Stand it is orders of magnitude more complicated to achieve the same process and you will probably try to wait x amount of time and hope that the temperature is achieved. However. You will miss the overshoot and that's not the test anyway. So you will write some software to do the state monitoring and calculate the rate of change and, now, you are using Test Stand just as a reporting tool. Test Stand is good for "stateless", pass/fail testing and suffers the same problems as any other scripting/sequencing environment when state and/or continuous monitoring is introduced. It may be that it has served you faithfully for the most part in your testing but it is not a test panacea which, I think, is why you are asking the question.

It is not a panacea of anything but most of factory testers are using some kind of scripting system (would be overkill without). Wheter I like it or not it is requested by the customers anyway so ... Have seen the scripting of Vector, Keysight - they are even worst than Teststand so I have to live with it ... Do you know a better altnernative?

And yes - when I need any overshoot detect we either use dedicated hardware (osciloscope etc) or a backround thread. 

However my hardware is mostly used for control of the process rather than the testing itself (stop, start, multiplexing signals, controlling powerpaths, etc.). The most basic "backround" task is stopping teststand script if Abort was pressed or some threshold was reached on control signals.

And yes we do use persistent VIs for this kind of tasks ... So it is a combination of script with background persistent vi's ... 

[ShaunR]

37 minutes ago, brownx said:

It is not a panacea of anything but most of factory testers are using some kind of scripting system (would be overkill without). Wheter I like it or not it is requested by the customers anyway so ... Have seen the scripting of Vector, Keysight - they are even worst than Teststand so I have to live with it ... Do you know a better altnernative?

And yes - when I need any overshoot detect we either use dedicated hardware (osciloscope etc) or a backround thread. 

However my hardware is mostly used for control of the process rather than the testing itself (stop, start, multiplexing signals, controlling powerpaths, etc.). The most basic "backround" task is stopping teststand script if Abort was pressed or some threshold was reached on control signals.

And yes we do use persistent VIs for this kind of tasks ... So it is a combination of script with background persistent vi's ... 

Another thing I did with the aforementioned was to add TCPIP (a later version). It meant you could launch a VI and then communicate with it via strings sent from Test stand - even on remote machines. The wrapper was only slightly more complex than the pure launcher but it meant you could configure the devices on-the-fly, abort or reset devices and query state information with simple strings from Test Stand (I used SCPI-like commands).

Anyway. I diverge.

You've probably guessed by now that the choice you had was to have an instance per device which you control and sequence from TS, which is what I was describing, or an application that does it and reports back to TS, which is what you are designing. The others have given you options for the latter and I was just giving you a method for the former.

Edited October 1, 2020 by ShaunR

[drjdpowell]

I've never used Test Stand, but if I did, my first thought is to have a main LabVIEW App that controls all hardware, with Test Stand connecting (using the Messenger-Library TCP functions) and interacting via messages.  Just as Shaun is describing.

[brownx]

2 hours ago, drjdpowell said:

I've never used Test Stand, but if I did, my first thought is to have a main LabVIEW App that controls all hardware, with Test Stand connecting (using the Messenger-Library TCP functions) and interacting via messages.  Just as Shaun is describing.

The application which starts the teststand script is a labview executable by design. However in most of the installing variants this labview teststand engine runs in a separate labview instance from the one started by the script. The only communication between them is windows messaging (pain to use and slow). Nothing we discussed here would work ... 

So I have Labview 1-->Teststand --> Labview2 and the two Labviews are separated (like two different executable is). Tried windows messaging but it is a pain ... I could build a tcpip messaging but would add additional layer I don't want.

Thus we usually go other way around - the Teststand engine has a lot of callbacks prior testing. In one of those I start up a set of persistent labview modules which will be running through the whole testing procress and does the hw control and other maintenance tasks. Basically it acts as an App started by Teststand.

So we are sort of doing how You say but with a twist to be able to fit into Teststand way of running things.

I don't inted to change this - all my HW control will run in that persistent set (including with the UI for user interaction).

[ShaunR]

35 minutes ago, brownx said:

So I have Labview 1-->Teststand --> Labview2 and the two Labviews are separated (like two different executable is).

You will have to re-architect that if you want to....

Quote

so it has to work without teststand as well (not to mention that Labview Teststand API is slow and I would like to keep the connection between teststand and labview "ondemand"  instead of always updating a lot of stuff even when I don't need it).

By the way. The TCPIP I described earlier is a layer to break cohesion - meaning that the VI's can be controlled by anything, in any language, including Test Stand. So if you want the "on demand" aspect, then that is probably the easiest way forward.

[brownx]

14 minutes ago, ShaunR said:

You will have to re-architect that if you want to....

Is there a propper way (except some kind of interprocess communication)? There is a combination when the two instances are one but not with labview runtimes which sometime is requested.

Contacted NI support a while ago, discussed with one of the heavyweights but he could not give me a good solution which does not involves interprocess. More than that the current NI way of windows messaging is one way - teststand can send a message towards the labview1 engine but other way around only betweem two teststand steps hijacking the step update mechanism. Once a step locks himself (bug or some other reason) it will lock the whole messaging queue ... It is a useless pain ... 

14 minutes ago, ShaunR said:

By the way. The TCPIP I described earlier is a layer to break cohesion - meaning that the VI's can be controlled by anything, in any language, including Test Stand. So if you want the "on demand" aspect, then that is probably the easiest way forward.

Yea I know ... But adds another layer of complexity - all the HW is already tcpip or udp so adding a tcpip bridge between is not something I want ... Last time I did it was because we had a mixture of 32bit and 64bit enforced by the client and I had to But I understand what You mean ...

Probably I'll use named queue instead, I can hide it so anyone uses it does not have to understand how it works ....

Edited October 1, 2020 by brownx

[LogMAN]

36 minutes ago, brownx said:

Probably I'll use named queue instead

1 hour ago, brownx said:

So I have Labview 1-->Teststand --> Labview2 and the two Labviews are separated (like two different executable is).

Named queues will only work in the same instance of LabVIEW. If there are two instances, those queues are isolated from each other (labview1 and labview2 don't share their address space), which means you need inter-process communication.

@drjdpowell If I remember correctly, the Messenger Library has built-in network capabilities, right?

[brownx]

8 minutes ago, LogMAN said:

Named queues will only work in the same instance of LabVIEW. If there are two instances, those queues are isolated from each other (labview1 and labview2 don't share their address space), which means you need inter-process communication.

@drjdpowell If I remember correctly, the Messenger Library has built-in network capabilities, right?

Yea, this is why all the stuff will be in labview2 - i'll keep labview1 just as a launcher of teststand script engine.

I'll look anyway to @drjdpowell solution, might or might not use it but probably i'll learn something from it

[brownx]

Went in the Queue/Notifier direction, VI factory and some classes - seemed to be the simplest and fastest to implement if I keep everything in one Labview instance.

The basics are working very well with random data and one type of request through queue ...

TY for the help for everyone!