hooovahh

I completely agree, and I think you would be hard pressed to find someone who thinks this is the better way of doing things. I also wanted to mention that I didn't think this was a "new" feature. I think the only new thing NI added in 2012 was the visible labels. Just so others don't get confused, in 2011 I can select multiple items, and right click and I will get the properties option (I don't remember what version that was added). In 2012 they added the Visible Labels option. I did not think that NI had said that there were other new right click options in 2012, other than Visible Labels.

Yeah very useful for clusters of clusters of clusters...etc. I do my best to not have any items in my cluster have the same name as another item in another cluster. When hide long names is turned on, a quick glance may not be enough to ensure the right element was selected, if the same name is used.

Absolutely. The custom user events mechanism is very powerful when combined with a UI and I think it would be a great evolution to the QSM. Not used in all situations (someones signature comes to mind) but in my mind I don't know why I would use native queues anymore, other than possibly interfacing with other already written tools. And even then a wrapper could be done to convert an incoming queue to a user event.

There's alot of good discussion going on here and I don't want to introduce more topics, I just wanted to clarify what I meant. No what I meant was have a subVI that enqueues data, but just after it enqueues data onto the queue, it then generates a user event. The consumer loop is not polling anything, it has a while loop with a event structure with no timeout. But it does handle the custom user event. In the custom user event case it dequeues the data from the queue. I wouldn't go this route, but for those that like working with queues this would be a middle ground between user events and queues. I would take it a step further and not use a queue, but use a user event for consumer/producer data which means no polling, and all events (UI events or other) are all handled in one event structure, without polling. Hopefully with my clearer explanation you'd see that there would be no polling with #2, and no timeout. There are multiple receiving mechanisms, but one triggers the other, so in reality you are only waiting for one to fire, and when it does, go handle the other. Attached is a very quick test of method 1 and 2 I mentioned earlier (in 2011). Just open the main and run it. It will enqueue 5 things to handle, (500ms apart) and the consumer loop on top handles them one at a time and then waits for user interaction to hit the stop button (without polling). Again I would use method 1 which only uses user events, method 2 uses user events but queues as well. Queue Event Test.zip

I've thought of two possible solutions to this. 1) Only use User Events to pass data around and don't use queues. 2) Or have the queue fire a User Event, telling the event structure to go read a queue message. The obvious benefit from this is no polling. Your VI will sit idle until either a command comes in, or the UI event is fired. Of course if you need polling you can enable it by giving your event case a timeout. I've heard that behind the scenes a user events are just queues so I wouldn't expect much (if any) performance difference.

From MAX the File >> Import function worked as you described, where it will show you what things it will replace or change, and allow you to make adjustments. I was assuming that the import from the palette, or the import from installer wouldn't give you that option and would just import it without prompting you, but I've never used these two features. I just assumed they worked that way because I couldn't see an installer prompting for those kinds of settings. I also don't know how they would interact with the silent install switches that NI installers support. I agree, that at a minimum, the build specifications should indicate what things it will include, likely by checking their corresponding items in the Additional Installers section, and then allow you to uncheck things you know are already installed.

I have seen that option, and every time I go to use it I had issues of some kind so I just distributed the .nce file along with the installer and had to import it manually, which I think I prefer because you can then resolve conflicts manually where the auto import may not make the decision I would about which hardware is what alias. That being said I think it wouldn't be too difficult to do this your self, using the Import function on the palette, as you suggested as a Post-Install function that I believe you can do. I'm sure you can understand why NI decided to include so much extra content when you decide to create an installer with the nce file. What if MAX isn't installed when you run your installer? It won't be able to perform the import...but still 330MB! It probably includes a run time engine or two, (which are now over 100MB each), and then possibly DAQmx, maybe NI-VISA, and MAX so I can see why it would be that much. I almost feel like you could make 2 installers, one that installs MAX, DAQmx, VISA, and any other things you need (NI-DMM, Switch, NI-Power), and then have your second installer that is your 9MB program which imports your nce as a post install function. Then have the user install both if it is the first time new machine, or just run your smaller installer if it is an upgrade. That way when you push a new version of your code you will only have to deliver a new 9MB file, instead of a new 330MB file, with 321MB being the same as the last release.

Put me down as another member who would love to see this tool. You are welcome to do as you please, but why even post an image of this tool, if you are unable, or unwilling to share it?

Thanks, not sure why I didn't think of that.

I had a big long explanation typed up and accidentally it the back button. I don't fee like re-typing the whole thing so here's the shorter version. I have a reentrant VI that is launched multiple times. In development you can open a reference to the VI by full path, but in an EXE the path is unknown. So you open the VI reference by name, but for this to work the VI needs to be in memory. So attached is one technique I've seen to keep a VI in memory by putting it in a case that will never be executed. Just run the Main.vi click Make New Graph Window and stop when you are done. This code will work when built into an EXE because nothing is opened by path. Is this the right way, or are there other ways to force the compiler to add a VI as a dependency, so that a new reference can be opened by name? Reentrant Reference Test.zip

Whats the conversion from cookies to Internet points? To Internet dollars? To Zimbabwe dollars? Back to cookies?

Pretty interesting, which is why I told you about it. You posting it kinda feels like you are stealing my internet points. I'll just have to make some posts around here that don't add anything to the conversation to get my post count up.

I do want to load a VI silently, even when the VI is broken. I also want the load to take as little time as possible. Say I want to do this for 1000 VIs and each of them are broken for some reason. If I use 0x20 each VI will take about 20 seconds to load, for each VI it is missing. This is a guess of how long it takes LabVIEW to give up on trying to find a missing VI. However if I open it in LabVIEW as normal, I can just click Ignore All. I would like to have the same functionality as Ignore All, but programatically. AQs previously posted VI seemed to be just what I wanted but I only have 2011 installed, and it did not perform as expected.

I appreciate the suggestion but that is not a solution. The help has this to say: Hide loading dialog box—Prevents LabVIEW from displaying the loading dialog box when searching for missing subVIs of the referenced VI. Note This option flag does not affect whether LabVIEW prompts you to find the missing VIs or not So it sounds like if you use 0x20 LabVIEW will not show the loading dialog, but will still be searching for the missing VIs. I want to perform an Ignore All, meaning just skip missing VIs.

Old topic I know, but I tried using this VI in LabVIEW 2011 and it no longer works (at least for me it doesn't). Is there an update that will work? I realize this VI was developed before the "Ignore All" button existed in the loading window, but I'm looking to open a reference to a VI programatically. Is there a way to open a reference to a VI on disk, and have it perform the same function as if I pressed Ignore All? Thanks.

I know that each CAR and bug fix probably has a huge amount of information about it. Things like under what conditions it is reproducible, and what work arounds are available. But I can't help but think that NI could have been a little more descriptive with their one sentence summary of this bug fix. Also I thought it was odd that a patch was released for a version of LabVIEW which is not the latest, and by that I mean 2012 which was released a few weeks ago.

Wow very tool tool, not sure how I didn't see this sooner. One thing I wanted to bring to your attention that you may already be aware of. I found that some more complex data types cause the XControl to crash in a strange way causing me to have to kill LabVIEW. If the data type is an Array of Clusters, and in that cluster is an element that is an array, I will get the following error: This error mentions to Right Click to fix the issue. But at this point if you right click the control, this VI becomes un-responsive and cannot be closed. If you don't right click the control you can still control the VI and stop and close like normal. This was seen in 2011 SP1. Attached is the example VI I used which causes the error saved in 2011. Is it possible to accommodate these more complicated data types? Or possibly just detect these data types, and not attempt to read them into the XControl so that this dialog and lock up issue aren't seen? Thanks. Array Probe Test.vi

I'm sure NI would love to hear your feed back. That being said I mostly agree. I knew it was bad when I noticed one of the members of the audience remoted into his machine at work with his iphone and was doing LabVIEW work from his phone. I did like how they mentioned some of their new hardware platforms, but I already knew about the. What I didn't know about is LabVIEW's new 2012 features which I was happy to see them demonstrate.

My solution to these issues would not be ideal at all, but it would go something like this. You log in to the PC (Windows login) this can either be domain controlled or local. Then run the LabVIEW software, or have it in the startup. On start of the application LabVIEW gets the user that is logged in. By looking at the "cmd /c set" results you can determine if the PC is on the domain or not. If it is then use the Windows command line "Net" to get the groups the user is a member of. If the PC is not on the domain, use "Net" again to get the groups that the user is a member of on the domain. Using this information the software can enable or disable parts of the UI to restrict the user. If the user wants to log in as someone else, I would use the command line function "Shutdown /l" to log them off where they will then be presented with the Windows login. This way LabVIEW never has the password, and the user never types it in while the PC is logged in (also deterring software keyloggers). If the user wants to perform user management and add users, or modify privileges, you can call a Windows program. Local users and groups can be edited through Lusrmgr.msc. None of this would rely on .Net, or ActiveX just Windows command line programs which have been standard for several versions, but sure Microsoft could for some reason change them. Non-Windows...yes you are screwed.

In the past I would avoid all situations that would cause me to handle passwords in my code. My code does not handle ISO rules for password protection, and it would be quite some time to develop those features. Then it would be even more time to have meetings certifying my code. Having reviews, and audits to verify the protection it performs and that it works properly every time. Then the verification procedure to have records of its functionality. Instead I would rely on Windows user management, or rather domain controlled management. If that wasn't an option I would use TestStand user management. If the project wasn't using TestStand I would push for DSC which adds user management. The point I'm trying to make is that personally I would not use my own code to perform security other than for a deterant, and not unauthorized access that would compromise any thing important. My opinion is that it is more cost effective, and safer to rely on 3rd party software that is off the shelf, and has already gone through any certifications required. Of course that being said I understand the constraints people are in and why these might not be viable options.

Couple things. First there's no reason to re-init and close the serial port every time the loop runs. Init the serial port before the while loop, then close it when the loop has finished executing (you pressed the stop button). The reason you are getting zero data, is because you are updating the waveform chart, outside the case structure. This means even when there is no data on the serial port it will add data to the chart. Move the chart to inside the True case, where you are reading, then the chart won't be updated if there is no data to read.

Thank you I didn't know this VI existed I've always been using the OpenG Boolean Trigger VI, which seems to have a better name, and icon, for the function it performs, but I would rather use a NI VI than an OpenG VI if their functions are the same.

I remember there was some kind of odd-ness with a few tree controls as well where two tree controls looked the same where you could select items by checking boxes in one, but the other was an indicator with boxes that couldn't be checked. Also don't let your self be impressed with the graphical view shown in demos. With more than 10 requirements that view is worthless. I remember a few projects with several hundred, and one with over a thousand requirements where that view was just a blur of lines.

What version of DAQmx is installed? Likely not it, but I didn't see it mentioned any where. It sounds like it is seen by MAX to some extent so I'm guessing the version installed is fine.

That's nothing. I can't seem to find it right now but I have pictures of me unpacking my carry on luggage for a business trip that was 2 weeks. I had one bag with clothes, and one laptop bag with all my electronics. When I got home I took a series of pictures as I unpacked because I had a very large pile of clothes, which appeared to be 3-4 times larger than the suite case that contained them. As you can imagine the bag with the clothes in it was very dense and heavy.