Chris O

Is it possible to do a pulse width measurement or a two edge separation measurement? Counter resolution is very high, compared to most analog acquisition. You might need to look at how you would generate the signals in your hardware, but it might work. Another option is to start a high-speed analog acquisition when you send your output signal and then set an analog reference trigger to stop the acquisition. You could count the samples to get an event length, but you could also refine the waveform first to give a more accurate result.

I posted this in the NI Forums a few days ago, but I have discovered a few more oddities since the original post and the title is no longer accurate. Also, there wasn't much response there, so I thought I'd see if any of you fine folk could shed some light on the problem. Here's a link to the original post. http://forums.ni.com/t5/LabVIEW/Values-not-passed-to-subVIs-in-builds-in-LV2014-and-2015/td-p/3254123 It now seems like the subVI that isn't working is actually getting all the values passed to it, but for some reason isn't able to generate the return event. That or it is generating the return event, but the event isn't being processed by the run time engine, because there are no errors from Generate Event. We are in the process of upgrading our entire code base to LabVIEW 2015, and we are reorganizing projects and libraries to make it somewhat easier to force inclusions in builds if that's the only solution.

I have an application where there is a lot of data moving around and I use DVRs for the data transport and user events to signal updates to any interested processes. Some of the processes are started with the application, while others are spawned and destroyed as users select various things to view in the UI portion (separate application). I haven't really looked at the actor framework to know if this is a violation of the intent, though. -Chris

I took my CLD at NI Week and just got my results. I passed with a 96%. 15 on Style, 13.5 on Functionality, and 10 on Documentation. I'm quite pleased. I just wanted to say thanks for the great discussions here; they have certainly helped me along the way. -Chris

I use events extensively in my projects and I often times have multiple subVIs registered for the same user event with no issues. Something to be aware of is that registering for an event creates a queue to hold the event data until you can process it. You have no control over that queue and if you ever can't process the data fast enough, it can back up until your program runs out of memory. This can be an issue with large data types in user events. With a queue, you can set limits on the size and handle overflows yourself. I like to make a Boolean or integer "flagging" event with another object to hold the actual data. Depending on what your requirements are, Data Value References can work great, especially if you can normally respond to events fast enough and are okay with possibly missing samples if the DVR updates again before you get to it. Plus if you use a standard data type for your flagging event, you can change your data object without having to retype your event reference terminals. I have also run into issues with high numbers of events slowing down even when the computer was not experiencing high CPU load. In one test, I was attempting to generate 5000 events at a rate of 20Hz, but the events were only being generated at about 15Hz and the CPU was only at about 10% utilization. I think it was an issue with the Windows event service. Because of that, I modified those data classes to only generate their events when something subscribes to them. Otherwise they update a buffer that I can read at sparser intervals.

The computer doesn't have a virus scanner and all of the windows defender options are off. The application has all the access permissions I can give it. I'll keep looking into it though. I'll make some test applications to see if there's a way to not have these issues. It's not just startup that's slow on windows 7 either. I can launch an explorer window with no problem, but using the folder browser will hang up the program for several seconds. Are there certain OS functions that the run-time engine calls before the front panel is loaded that windows is hanging up on? Does LabVIEW run any code before the front panel is loaded? If not, then why wouldn't the panel load, and then pause. If it does run some code first, at what point does the front panel show up? I don't know what happens in the OS when you launch an application, but I assume there is some kind of allocation request, maybe access to the graphics system, or calling the "application directory" function. I will try a few things and pass the results along.

I looked into the network connection issue, but in my case, the computer isn't connected to a network. Maybe my problem is different since the applications start fine in LV2009; it's only on Windows 7 machines that the long start time occurs. I also looked into the issues the OP resolved, but that wasn't happening on our machines.

I am actually having a very similar problem. The common piece for me is Windows 7. The same application will launch in seconds on XP and Vista, in either 32, or 64bit. But on Windows 7 (either version) it behaves just like the OP says: Shows up on taskbar immediately, no CPU or drive use for a LONG time, then it starts. Also, whenever I access a windows function, the first use take forever. For example, launching the Windows folder browser, or reading the version information for my executable. I can't figure out what it is. Also, not every LabVIEW executable starts slowly like that. Some start right away. These machines are fresh installs with no networking, no anti-virus, no firewall, nothing (they are isolated in a lab). And they are powerhouse machines (6-core, 6 GB RAM, 5TB of HDD space). The same program starts right up on a dual core system with 2GB of RAM.

Just make sure that if you have any relative file paths in your code, you check that they still work. The LV2009 directory method in executables mirrors the directory structure on your computer. In LV 8.x, all your VIs had their path under the executable, which is why you got your warning. If you like to put things like config files in your support directory, you used to be able to strip a VI's path twice and then move to your support directory. Now, since the directory structure is maintained, you can't know how far down the hierarchy your VI is. BUT! there is a new function in LV2009 that will get you where you want to go. In the File I/O > File Constants palette, there is an Application Directory constant that will take you straight to the folder containing your executable. Its very nice!

So... yeah... I have to sheepishly admit... Maybe I should have triple-checked. I found a place where I was actually registering for the event. It was a way to receive verification from the higher level VI that it had received the request for registration from this object. I pulled a goof and wasn't de-registering for the event. I found it when I was working backwards from the end of the process chain. That's why I didn't find it until the end. *sigh The good news is that the system works fine now. Thank you all for your time; I appreciate the help and I'm relieved it turned out to be such a little thing.

Thanks for that I am aware of the "background queue" that's created when an event is registered for. I use queues and events a lot in my programs, but I have just never seen a situation where such a memory increase occurred. I tend to stay away from passing any sizable data via events anyway. For large data sets, I almost always use queues. I have been experimenting with Data Value References lately, but haven't converted over any of my old code. My confusion is that in every other attempt to recreate this particular issue, there has been no similar behavior. I can strip down my code to nothing (there's not much to it now!) and still, the only thing that seems to impact the memory increase is the firing of the events. I'd love to sheepishly admit there was something that was responding to the events and opening a reference and not closing it, but there isn't any thing like that (...goes to double-check... nope) Any chance there's something funky going on with an event fired inside an In-Place Element structure from a DVR in a sub-vi?

Two things to note: 1. The events aren't registered anywhere. They are there for future use in this framework. Even when they are used, it's only one or two at a time. Also, most are updated at 1Hz. Only a few are updated at 20Hz, and none are faster than that. 2. The second example registers more events and fires them more rapidly than I would ever use my class for and it shows no memory increase.

The class has 14 properties. There are 5 strings, 2 timestamps, 4 doubles, 2 booleans, and a boolean type user event ref. My "constructor" method creates my object and then gets a data value reference. The reference is how the objects are accessed, and all my methods use the DVR. I don't believe accessing the data is the issue. I see no memory, or for that matter CPU, issues when I am updating my objects. Running at 2500 updates a second (which is above real-world levels), I only have about a 1% CPU utilization increase. I can even torture-test my system with 10,000 instances updating at 100Hz and while I get a large initial memory hit and the CPU load from that many updates, there is no memory increase while running. It's only when I enable the event generation that I see the memory increase. I tried to duplicate the setup, albeit simply, with my sample. The only difference I see is that I'm not firing the event from inside a method. The thing that I'm confused about is the ONLY thing I have to change to get the memory issue is to enable the firing of the event. If you look at the lower-half of the original attachment, the Event Ref is being read whether the Silent property is TRUE or FALSE. Also, when I used the profiler to see where this problem was happening, none of my VIs showed more than 5.7k of max memory use, even though I ran the profiler while memory use was increased by 50MB. Oh, I forgot to mention I'm using LabVIEW 2009 32bit. I don't remember if I have 2009.1 installed or not. I do my development on a 64bit Vista PC. We usually deploy to 32bit XP systems. I haven't put this into an executable or tried it on another system.

Good afternoon! I have a LabVIEW class that contains as a property a reference to a User Event with a boolean data type. A unique User Event is created for each instance of my class. I create anywhere from 50-500 instances of my class and I generate the user event between one and 50 times a second (It's different for each object). The problem is, when I do this, I get an incredible amount of memory increase; on the order of 400KB to 3MB per second. The lower half of the attachment shows the method for firing the user event. I added a property to my class called "Silent" which turns off the sending of the User Event and when I set my objects to silent, there is also no memory increase. None of the user events have anything registered for them, so there isn't a difference with some other action happening. I can't figure out why in this situation, there is a memory increase. As a comparison, I made anther VI (top half of attachment) that creates 1000 of the same type of User Event, puts them in a cluster and then gets a data value reference and generates events for all of them at 100Hz. Using that VI, there is no memory increase. I have other classes that I also pass around by DVR and they also have User Events, but I have never seen this issue. Anyone have any suggestions, or obvious problems with my code? Thanks, Chris O

The easiest way to record for long periods of time is write to your file periodically. There are different ways to go about this. If you want to write less often, you can build a buffer and then open/write/close your file every few minutes. Or, if you want to keep memory usage as low as possible, open the file and leave it open. Then write to it after shorter periods of time (every second or so). Once you are done recording, close the file. Be careful not to write to the file too often (10's of times a second or more) because you will lose hard drive performance and incur high CPU usage. One other thing to note: LabVIEW uses 64bit values for file position in binary files, but a 32bit integer for the length value in a wave file. This will cause a problem if your wave file gets above 2GB. We had to use a hex editor to fix the length value in a wave file that was too long. For normal audio recoding rates though, that's a pretty long time. (3-6 hours or more depending on the number of channels.)

I think if you have your project auto-populate from the directory, it doesn't give the option to remove from project. I seemed to have an issue like that once. I could be wrong. I don't have LabVIEW in front of me right now.