hooovahh

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.

In my own words I'd say a central error handler is a separate code module (ie. library, class, while loop, VIG) that is dedicated to capturing and reacting to errors generated in other code modules in the application. This allows for errors to be organized by their origin, time, or other factors. A few possible reactions to an error coming in can be to log it, notify the operator with an asynchronous dialog (allowing for the application to continue to try to operate), notify the administrator (email, SMS, etc), or shutdown if a specific error, or enough errors are seen (if your application sees 100 errors in one second it is safe to say you should probably just shutdown safely).

VI Engineering had a NI Week presentation and here are some discussions on it. Open discussions found on search. Stuff on the dark side: http://www.ni.com/example/31253/en/ https://forums.ni.com/t5/Reference-Design-Content/Structured-Error-Handler-SEH-Library/ta-p/3495302 https://forums.ni.com/t5/Actor-Framework-Discussions/Central-Error-Handler-in-the-Actor-Framework/td-p/3436974 https://forums.ni.com/t5/LabVIEW-Development-Best/Advanced-Error-Handling-in-LabVIEW/ba-p/3485995

There's lots of topics on central error handlers, and multiple NI Week sessions have been dedicated to them. As for your implementation, it is up to you. A FGV can make for a fine central error handler if all you want to do is log all error from all locations, email someone on an error seen, or shutting down on specific errors. But of course if an error comes in at a code module, then it usually makes sense to try to handle that error as close to where it was generated first, and only letting unhandled errors get passed to an error handler.

Interfacing with external tools is another interesting one, where the habit is to just do the 1-to-1. Lets say I'm interfacing with some 3rd party DLL, and on the return they will have a number from 1 to 200 with a table in their documentation stating what the error corresponds to. I've see times where people will just add a number to every value returned. I know the ADCS toolkit does something similar to this. The error code is actually returned as part of the communication. Here is documentation with a negative response table. NI just takes a constant of -8000 and subtracts whatever the response value is and uses that as the LabVIEW error code. This is quite handy because when you get an error code from LabVIEW it will state things like "Service Not Supported" which tells me about type of issue I'm having. These are the times of error codes that I can't really find an equivalent existing error code for.

I too am interested in hearing how people tackle this issue. Personally I think it starts with keeping the number of custom error codes to a minimum. I have a tool (that I can't seem to find online but thought I posted) which allows to search for errors that might match what you need. Then I use this as the error code and put in the custom text in an Error Ring with the optional inputs with %s. Of course one step can be eliminated if you could search in the error ring. I understand the benefit of custom errors, but the dependency issues, and code ranges usually means I just stick with the ones on the system.

I worked at a company that had all USB devices disabled. Not just USB memory devices, but also USB CAN, USB DAQ, USB Serial, USB GPIB, everything. For the DAQ stuff we would just simulate the hardware, then deploy it to test it. It was a pain but not too bad. The USB memory devices were easy to get around. It made the USB stick read-only, so to write to it you would map some empty folder like C:\USB to the E:\ drive or where ever your USB was. Then you could read and write to the C:\USB folder all you wanted which actually wrote to the USB device. I guess they just setup software to disable writing to drives that were marked as removable. That DgAgent sounds nasty.

I'm loving this thread, it is stirring up so many memories and stories I mostly forgot. I was at a customer's site that had to production lines going which a previous vendor had made using LabVIEW and TestStand. The company I was working for had been tasked with updating the systems by adding a few new features, and updating to the latest LabVIEW/TestStand versions as well as updating the OS. Luckily they sent the 3rd system to our facility to update and upgrade while they were still using the other two. We updated the system and made the changes they asked for, but there was still some onsite work required because we couldn't interface with their network databases until we were there. Once onsite I started setting up the 3rd stand right next to the other two that weren't upgraded yet. My first day there I started asking around about the credentials used to access the network and database that I needed to have my software log to. No one seemed to know and even the IT guys were confused about what I was talking about. So with the permission of the program manager I looked at the source on the 1st stand to see how it was logging to the databases. Sure enough there was the user name and password, and it was something like User:TestUser and Password:TestUserPassword. So I updated our code got it working and the customer was happy. I saw the IT guy walking around so I let him know. "Oh yeah I found the credentials used for the production systems it is the TestUser account." His eyes got really large and said "No one should be using that." And I'm like "Oh okay well we're just using the same credentials the last vendor was using and it can be changed later." He said okay and left. About 10 minutes later I noticed the other two production systems were having all kinds of problems, failing every part it tested. Just then the IT guy came up and said "By the way I deleted that user account so no one can use it." Luckily the program manager was in ear shot and started blaming him for causing the production lines to go down, and demanded he fixed it. So IT made a new account, with a new password and we used that. I'm not sure why he thought it was okay to delete that user when I mentioned how the production lines were using it, but he did and I was glad we didn't spend too much time trying to fix it. Oh and we also have a No Sleep program on our test systems which is an AutoIt EXE. As for updates we have the systems download updates but not install and then we just need to remember to reboot the machines when testing is finished which might not be for months. Every once in a while IT comes down and says there is some major new virus and we need to update all machines now, which is a pain but we haven't had any issues yet.

Use off the shelf software? Heavens no. Why don't we just create our own approval software that doesn't integrate with anything, requires extra training, is supported by no one that speaks English, is buggy, and charges a licensing cost calculated by number of clicks of the mouse used during the approval... Another story before I forget it. I was deploying a test system to a production facility. The system involved two GigE gigabit cameras, and was looking at the DUTs display to determine if it was working correctly. Everything worked great before we got to the facility, but then all the sudden the images from the ethernet camera would sometimes get black bars, obscuring the image to where the vision system would fail to work. We looked into all kinds of jumbo packet settings, Windows network settings, and just before going to buy a new network card I asked if anyone had used the machine and a worker mentioned someone from IT had used it. I talked to them and they installed network spying software to make sure it was locked down. Turns out it was also disrupting all network traffic, including the cameras. We asked if it could not sniff the two ethernet ports going to the cameras and they said the software didn't allow for that level of control. We tried to uninstall their software but it required a password during the uninstall, and IT wouldn't give it to us and wouldn't allow us to uninstall it. At this point the customer is getting increasingly frustrated with their own IT department, especially since it was costing time and money for me and others to be there when the system was crippled. We were still local administrators on the PC, so we just disabled the Windows services, and had their software not run on startup anymore and production was running again. Customer was happy the system was running, and IT didn't really care as long as it was installed on the PC

I made a new thread and started with a story that you reminded me of.

So based on conversations in another thread we've come to find several instances in our career where IT and corporate policies that mean well, get in the way or getting work done. Policies intended to keep IP from leaking, or viruses from taking over our PCs, and ransom-ware, tend to make software developers find work arounds so they can get their job done. So I thought we could make a thread where we share some of our IT horror stories, focusing on previous work for obvious reasons... One company I worked with had locked down the work laptops to where you couldn't really do anything other then answer emails and write Word documents. So when we needed to install LabVIEW which required administrator privileges, there was a whole approval process to get the IDE and some of the DAQ drivers installed. This included several levels of approvals, and justification for why you wanted to be an admin. You would apply to have administrator privileges given to you but you only had a 2 hour time slot, and after that the credentials you were given wouldn't work, and you had to apply again. Of course the first thing we would do in that 2 hours, is use the administrator account we were given to promote our user as a local administrator, so we never had to apply for it again. This company also had an app store for PC software. To me the concept of having a PC app store seemed odd. I sorta consider the whole internet the app store, and the concept that an offline app store can be up to date with all of the internet, with the newest software seemed silly.