Jump to content

stever

Members
  • Posts

    11
  • Joined

  • Last visited

    Never

stever's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Antoine, I have it all up and running now. Thanks again. IMHO, you should consider submitting this as an official NI example...good stuff! Steve
  2. You're right - thanks for pointing that out. And thanks to Chris and everybody!
  3. Hi, I'm building some LabView (8.6) code to do a simultaneous camera image capture and motor control. I put each of these in their own While-loops with an Event-Structure right inside looking for button presses to kick off each sub-vi. The camera capture is very CPU-intensive, and the motor control isn't (just steps when the button is pressed). But I am finding that when I start the camera capture, LabView is no longer responsive to anything else on the GUI (including a button which stops the capture!). I'm attaching a very much simplified test case for this "feature" of LabView that reproduces the behavior: - Two while loops at the top level of the VI - Two buttons at the top level also - Each while loop has an Event Structure looking for one of the buttons to be pressed - One of the buttons starts a process that finishes "immediately" in the lower While/Event structure - The other button starts a time-consuming process in the upper While/Event structure Steps to reproduce behavior: 1) Run the VI (I didn't reset buttons, etc., and, yes, there are two stop buttons, but don't worry about those things) 2) Press the Date/Time button on the left to your heart's content. It updates the display fine. 3) Start the counter with the button on the right (it'll activate on a transition to true) 4) Try to do anything with any other button on the screen (time/date, the two stop buttons), and you'll find that nothing works except the big kill button in the menu at the top. This is not the behavior I expected. I thought that since LabView was multi-threaded, load-balanced, etc., that I would be able to do other things while the CPU-intensive process is working, even if those other things slowed down a bit. But they don't slow, they are simply not available. In fact, in my real code, I put that "long" process inside a Timed Sequence just so that I could assign it to the 2nd core of my dual-core system. I verified that it shifted the long process to the 2nd core, but I *still* could not use anything else on my VI's GUI. Could this possibly be correct? I can't imagine that being the case. Am I just doing something really bone-headed? Thanks, Steve Download File:post-14611-1233787311.vi
  4. QUOTE I was looking at that. My only issue is that I don't know how the Timing Source interacts with the dt. You have to select something for Timing Source, and the only option is the 1 kHz clock. If you set dt to 0 does the structure run as fast as possible, or at 1 kHz? Documentation from NI is sorely lacking in this regard. QUOTE But while you are prototyping you should try putting a "regular" while loop inside a single-run timed while loop. This will allow you to use the timed loop to only set processor affinity. Your code will be slightly "messier" but you may find it does exactly what you want. That's a good idea. What I think I'll do is use a regular while loop (which will run as fast as it can), inside of which is a Timed Sequence whose Timing Source is "1 kHz Clock <reset at structure start>". Inside this Timed Sequence is my LabView code. I think this is equivalent to what you suggested. Thanks for the suggestion!
  5. Hello, I would like to be able to set different parts of my LabView code to run exclusively on different (and isolated) CPU cores (e.g. quad-core machine doing 1) random OS stuff; 2) data acquisition, 3) data processing, and 4) visualization tasks). My trusty NI sales engineer informed me there's no way to do this, but now that I have LabView (8.6), I have found the Timed Loop VI. While not exclusively for this purpose, it seems to be the only available solution for this (is this right?). So when I put a timed loop on a block diagram with some random CPU-intensive task, and wire an integer to the loop's Processor input, I can see the CPU load move from one core to another. My concern is the Timing Source. With just regular LabView I apparently only have access to the 1 kHz source (no RT target stuff to get the 1 MHz). I just want this loop to run as fast as it can, as if it were a regular while loop in the block diagram, I don't want it limited to running at 1 kHz. Is there a way to fix this? Can I tell a Timed Loop to "just run as fast/often as you can"? Thank you! Steve
  6. Is it possible that the Enqueue Element.vi only queues a pointer to the image? If so, I see the use in having the additional buffer, since that's where the frame data that the queue manages actually resides. Since frame data will be stored in this image/save buffer with indexes that only increase and then wrap at N (N=20 in the example), am I correct that this is a circular image/save buffer and therefore it's possible to overwrite frames? For example, if your image processing loop did so much stuff that frames were pulled into this buffer faster than they were pulled out, you'd end up overwriting good data, yes? Which perhaps is why you pointed the previous guy to the number of elements in the queue (if that gets > N, you can throw an error or something)? Very clever. You are obviously quite skilled at this. Steve
  7. Antoine, That is a proven learning technique, and I applaud you for your efforts I have a question about your VI: I understand the "camera" circular buffer (you have this labeled as the acquisition buffer) - this appears to be the same thing as a "ring" in NI's language (e.g. the LL Ring.vi example). And I understand the upper while loop and the queue as well. The lower while loop waits until the ID of the last buffer available is updated, then it proceeds into the True case. The goal here is to get the new frame referenced by this ID put on the back of the queue. In order to get this image sitting in the camera circular buffer into the queue, you have created a separate buffer of 20 (or whatever number) frames, and you index this buffer to get one of those frames. In this extracted frame, you IMAQ Copy the camera buffer frame into the image buffer frame and then shove that image into the queue. I understand the HistoryBuffer.vi takes care of getting the proper index into the image buffer. My question is why do you need a separate multi-element buffer to pull out an image and put into the queue? Couldn't you just allocate a single-frame buffer (N=1 instead of N=20)? Will this buffer ever have more than one image in it at any one time? There's an example from NI for IMAQdx that a coworker of mine found. Unfortunately, there's not an exact match to IMAQ VIs, and IMHO, the IMAQdx VIs are better, but I can't use them (because I'm using CameraLink). The example is located at: http://zone.ni.com/devzone/cda/epd/p/id/5859 It's similar to your example in many respects, but different in others. I'm not facile enough yet with LabView/IMAQ to render an opinion as to which one is better for what I'm trying to do. Thanks again. Steve
  8. Thank you. I am looking at it now - it looks promising. One comment - I think the case statement in the upper loop needs to be reversed to write files when the buffer is > 0 ? You are my hero!
  9. Antoine, Thank you very much for your speedy reply. I will have a look at the code in the link you provided to the other thread. Here is some info on my application: - Need to acquire at full frame rate of the camera, which is currently 60 Hz, but might be faster in the future (up to a few hundred Hz) - We cannot lose frames, and each frame needs a millisecond-based timestamp (this is a scientific application, not for human viewing of frames) - Modern PC (will eventually be on quad-core Core 2 with 4GB RAM, XP 32-bit, SATA HD non-RAID) - NI 1427 frame grabber - Sensors Unlimited SU320KTSX camera - We have to display frames, but not necessarily every single one (enough so the operator can see what's going on) - It'd be nice to do some processing on these frames before display, but if that's too slow, not a problem to skip this - Capture triggered by user pressing a button - Capture needs to be able to run essentially indefinitely, but probably wouldn't be for more than a couple hours. Using: - LabView 8.6 - IMAQ 4.1 Thanks again, Steve
  10. Leen, Were you able to find a solution? I'm trying to do exactly what you describe, and I've yet to find something that will work. Thanks, Steve
×
×
  • Create New...

Important Information

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