hooovahh

Thanks for the example. I now see what you mean. I wouldn't use #2 either. Sending a message (event) to tell the receiver to check their messages (queue) is redundant. True, it does do it without polling, but what's the point?

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.

I'm not quite following #2. Do you mean have the dequeue fire a user event when it receives a message on the queue...

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.

I have a hunch you'd see very significant performance problems if you implemented strategy #2. If you have multiple receive mechanisms in a single loop, you *have* to use a timeout and polling. (Unless you implement something like AQ's priority queue.)

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

That's correct. However, you have two message receiving mechanisms in that loop: the queue and the event structure. You have to make sure both are being serviced. If you don't have a timeout on the event structure none of the messages from the lower loop will be processed until the user initiates some action on the UI.

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.

Right click. Save As

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

You want a cookie?

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

Maybe I misunderstood what you were trying to do. I thought you liked to be able to silently load a VI even if it was broken?

Option 0x20 really allows you to do this; unless you also set option 0x10, the VI will silently be loaded into memory.

/J

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.

How about using Open VI Reference with option 0x20?

/J

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 think that's the one that most people are likely to run into. "Array data changes unexpectedly when passed through a case structure in a timed loop" could be pretty nasty too, but I don't often use timed loops.

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 just returned from this event and it was terrible. It was just an extended version of NI's standard sales pitch with some demonstrations in the dark and a couple of NI Week clips from 2011. I kept thinking that at some point the sales pitch would end and that meaningful information would be presented, but it never did. I'd like to have those hours back.

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.

While using an external solution such as Windows authentication is sometimes an option it doesn't automatically solve most of the problems. If you intend to not just call a Windows login dialog itself, you still end up having the password in cleartext in LabVIEW anyhow, so most of the concerns still apply.

And (ab)using Windows authentication for your own application is not as trivial as it may seem. There are differences about local logins and domain logins. While you can issue domain logins fairly easily using directory services, this proofs very difficult for computers that use a local authentication scheme or don't have cached domain login credentials and have to use local authentication as fallback.

I have tried with .Net to get there, but the only way that works reliably both for domain authentication as well as local authentication is using a VERY involved Windows API interface, that I came across by accident somewhere. And it requires an external DLL, as the Windows APIs involved are really complicated, and need to be able to adapt dynamically to various availability of APIs, depending on installed Windows version and feature set.

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.

hello everybody,

I am trying to connect my device through serial port and then get the waveform real-time. I have written a program but the problem is that the graph is an straight line with zero amplitude that sometimes show up which is not desired one.Could you please somebody help me and check the attached vi. I really need your help. Thanks in advance.

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.

There are several ways. For example, you can use this VI to detect the "direction" of your boolean change.

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.

It struck me as a vastly powerful and versatile engine (really amazing!)... hidden behind an incredibly clunky and dated VB6 style interface. Screen switching to set up the model in one place and view the effects in another. Very strange mouse behavior: click a button to enter some mode (like there was no mouseover event...?), and the mouse teleports to a different part of the screen. Entry fields were also... odd: some things you could click on, some you couldn't (but it seemed like you should). And clicking on entry fields tended to make the screen flash as it redrew everything so I could type.

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.

I have to check bags every single week, the only thing I find is a pain is that the taxi line's a little longer

However, being able to pack enough stuff for 4-5 days (NI Week) into carry-on size luggage is commendable

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.

We might start our next project on 2012, the latest TestStand and win7

Yeah I couldn't help but notice you are running XP. I'm sure you know this already but I like to remind myself, XP came out almost 11 years ago. Service packs have changed XP since that original release, but I can't imagine using very much 11 year old software today that was designed for consumers. Good luck with your future upgrades.

Here is my 2011 in Windows 7 x64. I'm having a difficult time seeing any difference between the two. I haven't used any thing earlier than 2009 in so long (it feels like more than a few years) so I can't say when the change happened.

Related

That only had 9 Kudos and it got implemented? I guess there's hope for any feature request.