Jump to content

Chris O

Members
  • Content Count

    16
  • Joined

  • Last visited

  • Days Won

    2

Chris O last won the day on August 27 2013

Chris O had the most liked content!

Community Reputation

8

About Chris O

  • Rank
    Active
  1. 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.
  2. 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
  3. 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
  4. 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
  5. 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 obje
  6. 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
  7. 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.
  8. 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 star
  9. 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 wi
  10. 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
  11. 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 noth
  12. 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.
  13. 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 100
  14. 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 se
  15. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.