Jump to content

brownx

Members
  • Content Count

    23
  • Joined

  • Last visited

Community Reputation

0

About brownx

  • Rank
    Active

LabVIEW Information

  • Version
    LabVIEW 2014
  • Since
    2016
  1. 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!
  2. 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
  3. 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 ot
  4. 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
  5. 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 signal
  6. 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 ...
  7. 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++ ...
  8. 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 w
  9. 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.
  10. 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
  11. 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 )
  12. 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
  13. >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
  14. >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.
  15. 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 o
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.