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!

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

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 ... 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 ....

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).

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 ...

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 ...

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++ ...

All that dynamic not - that was a 5 person project for years and always evolving :)) Forgot to say that most of those HW have C++ API and C++ test applications (some written by me so I know them) - thus I already have over 70% ready in C++. I would need to just add a class structure with the right inheritance to be able to put them together which is not that big of a task ... It is tempting however I think I'll go Labview since 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. If I go C++ they will curse me till the end of my life and I will get calls all day :)) Which means I will have to take a deep breath and go class factory - I don't need dynamic VI loading, a class factory with selectable HW type should do ... Pfff ... Was hoping to get a new fresh input to get pass of the array of arrays with some Labview magic I don't know yet, but I was also hoping to not get to complex dynamic HAL stuff ... :)) So I will aim somewhere in the middle ...

If it's that complex I rather do it in C++, few days (already done such stuff so not starting from 0) and just export the thing to Labview :)) But the guys following me will go crazy in case any change is needed The HAL is not that complex in my case - just think about a set of booleans and numeric values - the rest is taken care of the HW, no need implement a huge abstraction layer on Labview ... Classes, multiple inheritance, class factory etc. is not a problem - I am used with them. What I am not that familiar are the notifiers but with LogMAN and NI examples it will be fine. I've done complex HAL systems in C++, home automation/iot server with modules loadable by dll or jar or activex or whatever, everything abstract including the programming language too, scalability is high, etc. etc. - this is what You mean? If yes I probably don't need that complex - there will be less than 10 types of HW supported and the consumer of the data will exactly know what hardware he is using too, so there is no need of that complexity.

For me a subvi is equivalent with a functioncall in a scripted language - this is how Teststand uses them too (just see a line of script representing a vi with a bunch of inputs and outputs representing the data in and out, not even see the UI). But I get what You mean ... I don't care too much about performance since my application is a slow one with small amount of data - what is complex is the distribution of the data, the multithreaded access and the need for scalability. This is why I just thought there should be a better way than "arrays of arrays of arrays or classes and references" which is a pain to maintain and to scale. Ok - let's talk about my example - it's basically a IO driver: - I need to support a set of hardware, each with N inputs and M outputs (don't matter what kind, they will be many) - it has to be easily scaled to add more type and more from the same type - has to be multithreaded and permit multiple instances of the same HW - data has to be accessed from a single standalone vi call (hard to explain this unless You guys are using Teststand which is a bit different than having one monolith Labview app) How You guys would implement it? Don't need complete examples, just a few keywords from where I can get a new viewpoint ... For now what I see is a set of classes, holding only the class in array (with not even that is needed), using one persistent vi per instance and notifier to get the data from it and queue to send commands to it (this will replace the arrays of arrays of arrays I did not liked anyway). Do You see anything wrong with it or have a completely new idea?

I C ... Well in my case the UI is almost nonexistent - I have to do under layers of Teststand scripts based on different hardware, the result is never a UI (if You don't call a PASSED/FAILED and the test log a ui with some minimal interactions like start/stop/exit etc.). So I don't think in UI, the data I am working with is almost never shown (maybe on the debug UI only where I want to see some details if something goes wrong )

Hm - I definitelly did this mistake ... Even classes have their private data in clusters formed from bools, etc. - same sort of elements You get on UI. Can You give me a good Labview example which shows how to use real data vs UI elements? I did Core1 and 2 and this thing was never mentioned (except functional variable) and I still have the feeling that I miss something - this could be the reason I still kinda don't like Labview

>As a C/C++ programmer I feel the urge for memory management, but this is really not something to worry about in LabVIEW, I have the same background with 20+ years of writing all kind of code from servers to low level 16 bit half assembly code Maybe I just get older and dumber with time but I need much more time to think in pipes than in C lines - this whole thing I would have wrote it in C++ in 1-2 days and long forgotten :)) >at least not until you hit the upper MB boundary. Not really the memory was why I want a clean setup - it's more the syncing and multithread. Old solution had only 1 HW at a time - a simple global or functional variable written by one thread and read by the rest was enough - speed and memory was not an issue since the application is slow, memory footprint is low and whenever I needed faster read I could directly read the HW for the rest of the pins. But once 1HW is replaced with 10 and few threads with many - this solution does not works anymore. Either I use references which makes things hard to follow, either I use some async piped solution. You confirmed this as well - the notifiers for data and queue for commands might be the best solution, now I just have to make a drawing to see all the elements in one place to see if I did not forgot something ... >Now that I think about it, there are quite a few things I might just use in my own I/O Server... It's not opensource is it? :)) >It might seem easier at first glance, but now all your consumers need to know the exact order of inputs and outputs (by index), The outputs and inputs name changes for every application so they are changing anyway (rearranged and sometimes different function and different name). And the configuration is usually loaded from a INI file runtime (index, name, everything) which makes it a pain to use named clusters specially combined with Teststand. Teststand also has other limitations - too long to describe - they make easier to have indexes on consumer like ABORT_SIGNAL = 10 which can easily changed by the INI file runtime while a ring or enum would be messed up at every change by Teststand.

>How much data are we talking about? Not that much - around 110 Booleans basically (digital IO's) and less than 10 analog (double) per hardware. Since I have less than 64 inputs and 64 outputs I can even use a 64 bit unsigned for Inputs and another for Outputs and deal with the "BOOL" on the reader side with number to bool array. >Either your notification always contains the value for "read IO1", Since the HW responds anyway with all his IO's packed into one response probably it's much easier to do a "get everything" and than just mask the bit or bits at the other end. I also need a background loop too which does maintenance stuff so it's not enough to be completely on demand (exp. one of the inputs usually is Abort which stops everything). Probably the easiest way to go is to do a worker to feed the notifier with real hw data on every 50msec, in this case I don't even need read io command since a complete read will be performed anyway periodically. The only setback of this would be that a read IO 1 would wait for maximum 50 msec (or less). The only thing which will be a pain is the interrupt IO's - I'll have to deal with them somehow but I will figure it out - probably I can deal with that in the background reader ... Thank You for the feedback - it helped a lot ...

Teststand can call a VI as Labview would do, it does permits storing values in script variables as well (Labview has Teststand API which can access Teststand variables too). Also permits parallel thread which can hold a loop VI which can persist during the whole test. Done this many times. However to have the data from the persistent thread readable from other parts of the test (like "read IO1") would mean a different VI accessing the variables of this persistent VI - which takes me back again to references, global variables or functional variables. You are suggesting that instead of the data references I should use a notifier reference? As far as I understand the notifier can send notification of a value changed (and keep the last change only) but it will not provide me a way to "read IO1" unless I keep the last value on a local variable on the receiver end in the persistent vi. Thus I will still end in mirroring the data in the background, the only difference is that I will not loop continuously but rather run only when something changed, right? Sort of event based programming instead of continuous loops. I could also write the values directly to Teststand but this API will be used 20% in standalone labview applications 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).