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

Seems logical but it is not that logical with Teststand where I need a TestStand call (usually a VI in step by step script) which does nothing except requires the last known value of an IO than closes (and the script will do a decision based on that value or give a fail or a pass). This VI instance does not existed before, it will cease exist after it's execution so probably the "obtain notifier" will be run long after the IO changed and I am interested in. I have to check if a VI like this can be a "consumer" for a GPIO value - if I have to introduce a middle stage which listens through notifier to every IO change and saves a "snapshot" of the current state to provide it to a Teststand call than I am back to square one In a monolith APP I would definitely go notifiers/queues but it's not the case with TestStand so I am still puzzled which way to go ... And I cannot go completely Teststand oriented way either since in rare cases we do use this stuff in monolith applications too ... Seems a dig deep into notifiers but I'll learn something new I guess I used queue before, not notifier but it seems close.

>but this particular approach will result in high CPU usage and low throughput The cycles are in sleep most of the time - the application does not need higher refresh rate than 50msec and mostly will be using from Teststand which means context switches on every line But your point is valid, TBH I am tented to make a compact C dll which could deal with all this stuff with max speed and less CPU, however I am open to any suggestions which would let me remain in the Labview domain. >It sounds to me as if you need to capture a stream of data, process it sequentially, and output it somewhere els It is not a stream, rather read input and and control output - probably the best description is driver for hardware like NI-DAQ and NI-Multiplexer but with slow data communication (50msec I don't consider fast) and much more complex functionality in the HW but this does not matter from the labview point of view. Basically what I need is: - a generic API (sort of a driver interface) which can deal with two-three types of hardware, 1-10 of each (TCP/IP, UDP or serial connected). This might scale later. - all this HW is polling type (no async events in the communication) - the inputs are mostly digital or analog type, the outputs are digital - some of the inputs once became active have to be kept active until first read even if they go inactive meantime (sort of an interrupt, HW is prepared to do this, SW has to be as well) - the data will have multiple consumers (same data too) and I need a "last known value" support at any time to any of the data - due to high debug demand I also need to "cache" the outputs (last known value which was sent to the HW) >Do you really need to keep all this data in memory in large chunks? Not big chunks - I am only interested on the last value (always the newest). The data is not that much - mostly controlling stuff - sort of 50 input, 50 output, few analogs, I2C,SPI, other protocol extension - this kind of stuff. Thanks for the input

Hi I need to make a scalable data acquisition system (I have to deal between 1 and 20 of hardware cards in the same time). The systems are based on polling and have quite much data in and out. Tried to use arrays of data, arrays of clusters, than arrays of classes and with all of them my problem was the multiple data copies while I am doing a single operation (one input change causes a copy of the whole array of all inputs or clusters or classes). Thought about functional variables too but that is hard to scale (with my current labview experience). So I decided to use references - the basic idea is below - it it a valid one ore I try to push my luck with something not recommended? DataIn is a bool array representing a set of inputs (there will be more, also numeric ones). In the final solution the Ref_DataIn probably will be a global, the rest of the loops will be in different reentrant VI's (except the creation of the references from frame 1 which probably will be non-reentrant or synced). Also I would like to know the granularity of Labview in the sense of reference variables (Ref_DataIn and his elements in the case below) - do I need to sync the read and write of the values or it is good as it is? I would like to avoid reading the Value while the data acquisition loops write it - it is not a problem if I read an array half old, half new values but it is a problem if I read empty array or half array when this kind of collision occurs. Have no idea how this works in Labview - in C/C++ I would need to sync it. Any other input is welcome, I come from the C,C++ world with more than 20 years of experience, I could make this work in a few days in a DLL and than import it in Labview but the problem is others have to access, slightly modify and easily maintain the whole structure even on site which is easier if I leave everything in Labview ... Thank You ...

That grayed out is my issue too It is possible to add an ECU and select protocol version 1.3 but it seems it has no connection with the message definition which is forced to enhanced anyway. The property You found is output one and cannot be set - found it in the Frame Node - can't change it, just read it from db. At least I didn't found a way yet to change it. I'll try the automotive forum, TY

I have a CRC/Checksum issue with NI-XNET 16.0 LIN. It seems I am getting wrong CRC (error 6) with normal frames but it is fine with 3c/3d diag frames. The difference is the checksum type - diag frames are having classing type while other types are having enhanced ... I want to switch the CRC/Checksum type to classic or the protocol version to 1.3 (which have classic crc for all frames like my device probably has since it is a older one) but it seems database editor does not allows this feature - enforces Enhanced for every frame except diag ones and cannot be changed. Is there a way to switch it somehow? If not from db at least from code ... TY.

Made the code using variant just to find out TestStand have problems with passing variants ... At least I did not succeeded to create a Global variable to hold a variant and pass it to the steps (tried container and object reference) - forums are full with this issue, I'll see what I can understand from them. Update1: Pfff - seems it is not working, at least not with my version of TestStand: http://forums.ni.com/t5/NI-TestStand/LabVIEW-Variant-Attributes-get-lost-in-TestStand/td-p/3172358 Update2: Managed to make it work with DVR - probably is even better since the 2-300 line lookup table is not copied in every step.

Just found the lookup tables (variant) - probably I'll go this way if there are no better ideas.

I have a CSV with data like: Name Addr Number Paul 13 235 Sarah 1 15 I need the fastest possible way to get the Addr/Number pair which matches the searched name (exact match, occurs only once). The whole search will be called lots of times from a teststand - this is why I need to have it fast. The simplest is to load the csv into array once than do a loop with string compare (fastest in this case probably being the string subset). Is there any faster way for achieving this without hardcoding the name,addr/number pairs into a switch/case?