bbean

Can you attach your 2009/2012 VIs and NI IO Trace logs?

Turnstile

As a work around, what if you open with Option set to x100? it seems to release memory then. I don't know if its bad form or opens another can of worms to open with "Prepare to call and collect" but never collect. The documentation seems to indicate so. Quote: If you use this option flag (x100), you must include one Wait On Asynchronous Call node for every call that you begin with a Start Asynchronous Call node to ensure that LabVIEW does not retain any started calls in memory indefinitely.

Obviously this depends on the circumstances, but what mechanism do you use to execute the "do" portion of code that could hold up the event structure? Do you just pipe information into a parallel queued state machine or actor? Is there a post on lavag or on the darkside that lays out the benefits or pros and cons of this (using user events) vs just directly piping the "do" into a separate parallel queued state machine queue?

Do all your loops with CAN communication have a Wait ms in them? Maybe CAN performance got better and the PC doesn't have time to sleep.

What type of performance hit would you expect manipulating pixels using IMAQ ImageToEDVR and an IPE? Curious as to the difference between an algorithm implemented with this technique vs a c DLL call, but I'm not near a development environment with Vision.

Are the Matrox dll calls thread safe? Are you making any dll calls in your image processing? Is it possible they are executing in the user interface thread?

Off topic: that looks like one of the most interesting/promising improvements to the Vision toolkit in a while.

CharlesB...I can't figure out where your race condition is. Also am not sure why you need all the extra mechanisms (Semaphore, DVR, Status) when you can achieve the same thing using 2 simple queues as shown in my example. Plus the 2 queue approach guarantees you can not work on the image being displayed until it is put back in the camera/processing pipeline. IMHO it is a simpler and easier to debug solution. The other thing my solution does is allow you to do the image processing in "parallel" to your acquisition.

ShaunR - I was unaware that you could use events like that with Imaq IO refs...very nice. I will have to remember that for my next vision app. While the Godwin Global approach is nice, I think there are two issues: 1) I believe the poster is not using IMAQ camera interface (Matrox proprietary instead) and 2) Somehow his Imaq Image Display is getting corrupted by newer images when it is updated faster (400fps) than it can be painted by the OS. I'm not suggesting the "triple buffering" approach is the proper solution here, but I am collaborating with the hopes that he can see a "simple" LabVIEW queue approach can work. PS. I surprised ShaunR doesn't have a "Cantankerous Callback" approach and I haven't seen any Actor Framefork approaches with multiple Actors.

Triple Buffering with simple queues and shift register. BufferTest.llb

Is the attached closer to what you want? it prevents the "corruption" of the imaq image ref by taking it out of the cam /processing buffer while it is being displayed. The third image reference in the VI is pretty much worthless. But wanted to see if this was a step closer. BufferTest.llb

How fast can you run your acquire and processing loop if you do not display? So passing the imaq reference to a display loop with a notifier doesn't work because you are afraid you may be overwriting the "displayed" image in the notifier loop?

Can you share your code? Are you doing any image processing? Can you drop frames on the image processing?

See my code

Threw together some quick code using an Express VI (GASP) to test the theory. Haven't run or debugged other than with my webcam. The Queue should prevent race conditions and provide a little margin on processing. Not sure how many data copies of the images will exist. Don't have time to investigate. Bean BufferTest.llb

does anyone know if the code for the Edit Format String dialog box is written in LabVIEW and is it available somewhere in the LabVIEW directory?

Yes. We had a similar experience using VISA but with USB Raw calls in parallel to an FTDI chip on a NI RMC running LabVIEW 2012 RT (no virtual comm port). We ended up having to remove the parallel loop and could not determine the root cause.

Not sure if this is relevant to the conversation, but I wonder if the FIFO.Acquire Read Region DVR to TDMS technique discussed here: http://lavag.org/topic/15335-why-tdms/?p=109716 would help with your scenario if you need to push performance. See also: http://zone.ni.com/reference/en-XX/help/371599J-01/lvfpgahost/fpga_method_fifo_acqread/

Is your database located remotely on a network? If so I would implement my first recommendation to open the connection to the database separately and leave the connection open all the time. That way you don't have to re-establish the connection each time to access the DB. Now you will have to add error checking and loops to re-establish the connection if it goes down. My guess is you are seeing some network latency or some type of issue related to the nagle algorithm bunching your packets together.

The DB toolkit is really just a wrapper for the activex methods and properties you are using. One thing you could try is opening the connection to the database separately first (see DB Tools Open Connection.vi), executing a query with a forward only cursor on the connection (see DB Tools Execute Query.vi), and then "fetch" the recordset (DB Tools Fetch Recordset) like they do in the DB toolkit. This way you can separate connection problems to the database from querying problems of a large recordset.

I am working on an RT app and hardware that uses more than 50 USB devices connected via USB hubs to an NI rackmount computer. After a hard reboot of the rack mount computer, the USB devices and hubs take more than 5 minutes to enumerate. I am looking for a way to verify all the USB devices have enumerated. Polling VISA Find Resources appears to cause the entire system to lockup if we start it immediately in RT app. If we manually delay for 10 minutes or so in the application and then call VISA Find Resources, it appears to work OK as long as all of the devices have successfully enumerated. A hard-coded 10 minute delay is not optimal because on soft reboots, the delay is unnecessary. Are there any other ways to get the state of system USB enumeration other than VISA Find Resource? During reboots, the NI boot loader takes a minute or so to "Enumerate USB devices" but it appears it only enumerates each USB hub before it completes and moves on. PS. I know there are latency issues using USB on an RT system. We chose to use the RT platform for stability (no windows updates, etc) vs determinism. This may or may not be a good reason, but its what we have now.

why not mouse events associated with the graph?

For the first time in my career I may need to compile LabVIEW code so it runs stand-alone on a MAC. Can anyone point me to a "compiling LabVIEW on a mac for windows dummies" article or webpage? A quick google search yielded limited results. My development machine is Win7 and I have VMware. I assume the process goes something like this: Obtain Proper Mac OS $$? and Install as a Virtual Machine in Vmware (I have VMware, don't have the Mac OS disks) Obtain LabVIEW for Macintosh with Application Builder $$? (I have a LabVIEW Professional license windows, can I just download/install LabVIEW for Mac on the VM and use my license) Install LabVIEW for Mac on Mac VM Copy VIs from windows development machine to Mac VM Press Easy button on LabVIEW for Mac and compile VIs to mac executable and build installer. Install on mac machine Profit The application uses serial port (any issues here with VISA?) for communication to a few instruments but no data acquisition. BTW my Mac experience is pretty limited...I can move the mouse around and click things but I still haven't figured out how to right-click . Any pointers or suggestions for avoiding common pitfalls are welcome. Thanks.

Name: Wire And Connect Quick Drop Plugin Submitter: bbean Submitted: 03 Apr 2013 Category: *Uncertified* LabVIEW Version: 2012 License Type: BSD (Most common) This Quick Drop (QD) plugin complements the functionality of the built-in QD plugin (CTL-Space-CTL-D) by wiring between selected controls, indicators, constants, and SubVIs. Default Shortcut - [W] Normal Operation Wires selected nodes in left to right order. Attempts to connect any common unwired terminals in between the far left and right nodes by checking the datatype, Name, or Caption. Holding Shift and the Shortuct: Wires controls to unwired far left Node terminals and indicators to unwired far right node terminals. This is just something I put together as my first attempt at a Quick Drop plugin. Something similar has been done previously to wire the corners of subVIs using the right click framework by user JCC_(SK): RCF Plugin - Wire Nodes by Corner - https://decibel.ni.com/content/docs/DOC-8386 . Code for this plugin was developed prior to knowledge of the JCC_(SK) RCF code and probably doesn't function as well since it hasn't been tested thoroughly. However this plugin is for quick drop and has some added capability to wire up all like terminals but can suffer from potential overzealous wiring. Just delete extra wires if necessary. Thanks to the NI guys for creating the QD template with good instructions. Someone may have done this already but I'm putting this out for comment anyway. http://www.screencast.com/t/PZhMafM2 Click here to download this file