hooovahh

So I see that you acquire 1000 samples, (not files) and then log those 1000 samples in a separate loop. I'd recommend waiting until more data is in the buffer before attempting to write. Those write operations are probably what is slowing you down, and if you can wait until there is 10,000 samples, or more waiting in the queue, and then call the log function just twice (once for time, once for the data, you will probably be better off. That being sadi I don't think I see anything really wrong with your VI, except maybe that there is a race condition on stop that might not close the TDMS file reference properly. Wire through the TDMS reference through the error case.

Michael did his magic again and it should be fixed.

Was debugging enabled on the VI when it was ran? I assume probing the cluster wire would force the string to be copied into another memory location. Anyway that does sound good since one VIM that takes a few minutes to write could perform some of the same functionality as the XNode. Still would require an unbundle by name, but a Read-Only DVR function could be pretty useful. I think I made one during the 2017 beta replacing the icon now that I think about it.

Oh sorry it was renamed Maleable VI, official feature in 2017 but was implemented as a custom XNode shipped with LabVIEW since around 8.2. http://zone.ni.com/reference/en-XX/help/371361P-01/lvupgrade/labview_features/ VI Macro discussion before 2017 made VIMs official. https://lavag.org/topic/19163-vi-macros/ It has some shared functionality with XNodes (type propagation for inputs and outputs) but other custom things like right click, adding removing terminals, and changing node size and icon at edit time can only be done as an XNode, not a VIM.

So cool, I would definitely use an XNode that does this. Yes the VIM could work with the issues already mentioned, with copying the whole cluster in memory just to grab one element. Props for the idea, and DTaylor's suggestion.

You say it is being ran in a different context, can you provide the context that it needs to be ran in? I'm having a hard thinking of a way to test this. Are you saying you have one EXE running, that the variant data is being passed to from another? Still I would expect the code to work properly since the LVClass.Open is providing the full path to the class. Is it possible the error is coming from some other place? Does this class not have a front panel in its private data? I admit I don't know what happens to classes once they are put into an EXE and would wonder if that is stripped out. Edit: Oh the get class by name will only work if that class is in memory. Just like referencing a VI by name only works if the VI is in memory. If you are loading from a separate context it won't be in memory. You need to provide the path to the Get LV Class Default Value and have it return the class. Then the rest should work (maybe)

I usually try to call it a Quick Start Guide, to help set expectations low. Then if things are missing the user just shrugs it off and figures there is a more detailed manual (which there will be when I finish it). I do a decent amount of documentation as I go, which probably isn't efficient since I'm often updating how things actually are. I don't really find the documentation part dragging on. Oh and I've been asked how long it will take to get a program up and running, and they will sometimes qualify it with. "How long will it take to get 90% of the program done" and I'll say something like "In two weeks I can get the first 90% of the program done, and then all that's left is to do the last 90%."

I definitely get what you mean by burning out. Even on project that is long, it is easy for me to lose interest. With LabVIEW it always feels like getting 90% complete is pretty easy, quick, and there are plenty of results to see. That last 10% seems to take so long to wrap up, and so much work that I find myself just putting it off and doing other work instead. Of course when timelines are involved, and you need to actually work on it, it is hard to stay motivated. Maybe its hard because I enjoy doing LabVIEW and it doesn't feel like work when its fun, but when it isn't fun it is a drag. For large multi member projects it gets a little better since you can all share in the accomplishments of everyone, so staying motivated is easier. From a program management stand point I've seen plenty of projects eat up 8 or more developers full time for months (years?) more than originally planned due to poor management, and unclear requirements. Those are pretty bad sometimes too because the moral of the team is poor. Constantly getting beat up, while working hard can make good people want to quit.

Man I love sysinternals. One suggestion I was going to say was you could try looking into parent child window relationships, and then set the whole parent window to be non active. But in typing this I realize this wouldn't work because in a normal window relationship the desktop is the parent, and so I'm guessing you would have the same problem. I'm not sure there is much you can do for this one. Maybe someone at NI will have a suggestion.

I looked at my code for setting extended style and it is the same as yours (other than mine runs in any thread which I think is a bug). And it sounds like the call is functioning properly for other windows. So this makes me think this is something specific to LabVIEW and how multiple window management is done. Here might be a useful test. Can you built a separate LabVIEW EXE that is your OSK and have it work properly on LabVIEW.exe or other build applications? I suspect this will work but don't know why it wouldn't work from within LabVIEW and the same application instance. I'm guessing this is just one of those instances where LabVIEW and NI are doing something non standard that is breaking normal functionality.

What's the errors generated from the VI server calls? I'm guessing the subpanel insert generates an error, and I'd also guess that error is something to do with the front panel window of the VI to be inserted already being open. Other than that you could ignore subpanels and VI Server all together if this is in Windows and perform child/parent relationships to embed any window inside any other. I demo'ed this in my attempt to insert notepad in the front panel of a VI, as shown here. http://forums.ni.com/t5/LabVIEW/How-to-run-an-exe-as-a-window-inside-a-VI/m-p/3113729#M893102

Must of these questions are covered in other CLA material, and the articles already linked to. I'm not overly qualified to talk about CLA specifics, only my experience. Every VI must have at least one block diagram comment, and every VI must have a VI description. I can't remember if every control I made had a description or not. I didn't bother with tip strips for the CLA. Style to me is mostly code cleanliness. Do you have many unnecessary wire bends? Do your wires cross lots of other wires? Do you have very nested structures? These could all be signs of poor style since type defs, libraries, classes, and subVIs can make the code easier to read and follow. You may want to check out the VI Analyzer which scans your code for style like this. NI uses this for grading but doesn't share the specifics of what the tests and criteria are.

Yeah there was a post on the JKI forums about it, and I went and tried and even though the download said 2016 on the page, the link was to 2017.

Generally the rule I followed was to place the tag, along on the block diagram, in the state (or case) that was going to cover it. If it was just a utility VI without a state machine it was just on the block diagram near the code that covered it, or in a blank area with the comment stating what the developer should finish and how that would cover the requirement.

Well then there is the fact that I didn't see any feedback nodes in NXG (unless I missed it) so it is possible it is going away. Or maybe it just hasn't been implemented yet. One point about the Value Changed function that someone at NI mentioned is a bug, is it doesn't work correctly for all values of doubles. For instance a NaN is never equal to anything, including NaN by definition. So if you used the Value Changed on a NaN and wanted to know if the value had changed from the previous NaN this function would return true, even though the value of NaN never changed. Just be aware of this functions limitation.

Here is a useful nugget on the CLA over on the dark side: http://forums.ni.com/t5/Certification/Certification-Nugget-CLA-Certified-LabVIEW-Architect/m-p/3165461 I took 1 hour creating a module template (actor) that was library based. It has a core VI with a while loop QMH with template cases like Error, Event, IDLE, Request, Send Reply, and a couple of others. This used user events to send and receive data which I made a few templates for. After this first hour I copied this library into all the separate code modules I knew I would need. Then I spent about 2 hours coding up the code, putting down comments on how something would talk to something else, or where data needed to be handled. The last hour was documenting, which included VI icons, comments, VI descriptions, and the tags. All you do for the requirements is place a [Covers: XXX] comment. Did you look at the example exams I linked to which have example solutions? It shows how this is done.

Yup looks like you're all set and don't need to install that extra thing I linked to.

Neat I didn't realize that it had been updated and rebranded. Of course the one I linked to has a BSD license, while the Averna has a custom license that seems a but odd, like the Restrictions section states "you may not...disassemble the Software or merge the Software into any other software, or otherwise attempt to discover the source code." Does pressing CTRL+E count as discovering the source code? It isn't password protected. But the inclusion of the RTM functionality, and multiple icons is useful.

Yup Tim is right. If you do this often you may want to either specify a custom configuration file in the application builder for your EXE (with this INI set) or you can make a post build VI that sets this INI tag in the built EXE after it is built. And if you are trying to hide your program in the system tray I highly recommend this set of code posted on LAVA a while ago. It is the most feature complete, and well done API I've found.

Well the purpose of this was to enable right click menus in explorer 32-bit. Do you have this? If not I'd suggest going to the SVN forums, or support to see what others have done to get around this.

Look at the error handling requirements section of the example CLA exams: ftp://ftp.ni.com/pub/gdc/tut/cla_sample_exam_atm_machine.pdf Also there are some example exams and answers on this NI page. http://www.ni.com/gate/gb/GB_INFOCLAEXMPRP/US Do the work that covers the requirements. I'd recommend a separate running code module, but a FGV may meet all the requirements depending on how it is implemented.

Not if it is done right. Either have a circular buffer of errors as a history, only show the last error, or cache the errors to disk. That's a fine idea but it doesn't scale well to large applications. You now have this inherit coupling between the error handling code, and the UI that the user sees by passing control references around. It reduces modularity, but in a pinch works fine. I probably wouldn't do that in the CLA, and am unsure how it would score using that technique

Sure blocking in these situations are fine, but for me many of my tests run for months unattended, and having a prompt come up and ask what the user wants to do, may leave the DUT in a weird state for a long time that could be dangerous, or at least invalidate the rest of the test. Prompting to continue is not something I do often, and usually it is only in the part of the application where I know the user should be there. Like if the user is setting up a test and they forgot to configure something I will prompt them to continue or go back and fix it. In this case a dialog is fine, but mid test is a poor place for a dialog in my applications.

There's lots of solutions, and anything I'm going to suggest might work or might not work depending on other factors about the design I'm unfamiliar with. For you number 1 issue in my designs the central error handler is a parallel running loop that doesn't halt the rest of the application asking the user if they want to continue or abort. My dialog just informs them of when the error happened, what the error was, and where it came from. My other code modules are written in a way that they should retry what they were doing, by reconnecting, or to go into an inert state where they only send some type of reset command to the hardware they are talking to. In neither case does the error dialog block anything. If you are using a FGV with a dialog, then that will block the flow of data which it sounds like youi don't want. For your number 2 issue I've seen something like a variable that gets incremented for every code module (actor) spun up, and then decremented for every code module that shutdown. Then only when this value is 0 does the error handler loop shutdown.

These forums are for general discussion and without you mentioning the CLA I didn't realize this was in relation to that. Now that I see your crosspost over on the darkside I realize this is talking about the CLA, and for that I think I did have a separate running parallel loop (like actor) that received messages from other parallel loops, and then had comments stating what to do with the newly received messages like "Add code for logging all errors here" and "Add code for performing asynchronous dialog here", but didn't actually implement them. I don't remember the specifics if the requirements talked about having to do anything with the errors. You'll want to read the requirements and determine the amount of work you need to do to cover them.