Leaderboard

You guys really need to discover the GetPlotAtPos method of the Graph/Waveform. Where is the LAVA Rube thread?

I've managed to keep Community scope by avoiding the password-protection features of VIPM, which is otherwise responsible for damaging the library (Known issue 13790). I now perform my own project cloning and password protection through a bit of scripting, and leave VIPM to just apply the license file. I really don't think I can live without Community scope in my toolkit, so this workaround will have to do

Actually it is a little better than you think... If you install the Vision Acquisition Software (i.e. the dev toolkit) then you don't need a license at all provided you UNCHECK the IMAQdx component... Magic! Of course, this will limit you to basic Image Management functions, but if that's all you need then you you don't need to pay half a year's salary for a full Vision license A handy side effect of this is that you can acquire images using IMAQ with a 3rd party CameraLink board without any license (since camera link uses plain IMAQ, rather than IMAQdx), but if you use a GigE camera then you need IMAQdx and therefore you need a license. Something to think about if you are building a vision system and have a choice of hardware interfaces! I tested this a little while back. Let's say you have a 1024x1024 RGB image: The IMAQ control uses 4MB to display the image, as expected since the underlying data type is u32 (4 bytes per pixel). Pretty efficent. The picture control uses 7MB which includes 4MB to display the image plus an additional 3MB for the input data. Why 3MB for the data? Well, the picture data is smart enough to know that an RGB image only has three bytes per pixel that are worth encoding. Note that the IMAQ control doesn't have the overhead for the input data since IMAQ images are by-ref.

I believe in the upper of your two pictures there's a buffer allocation on the wire junction. LabVIEW sees that you're doing something with the second wire and creates a copy of the array element. The resulting DVR is NOT pointing to the actual element in your array if my assumptions are correct but is rather pointing to a separate copy of that array element in memory. In order to do what I think you're trying to do you would need to create an array of DVRs and make a copy of the existing DVR from the array to have the DVR pointing tot he array element. Does that line up with your experiences of the code behaviour? I believe the only way to create concurrent DVRs to a single memory location is to branch the DVR wire. You can't call the "Data to DVR" several times because this (AFAIK) creates several DVR pointing each to different memory locations.

The Vision Common Resources install is FREE and allows you to use the IMAQ image control in your application. You don't get any image processing but it is fine for loading images and displaying them with all the ROI tools. I believe the only bit you need a license for is IMAQdx...

But it's truth. The big performance problem is not in thread switching here (thread switching while costly isn't usually where things go completely bad) but it is in copying the data. In order for the data flow paradigma to work without race conditions LabVIEW needs to make a copy of the data whenever a global or local is read. This is no problem for scalars but some people like to store x MB arrays in a global and read it every second to append a new subset to it and write it back. This is about the worst scenario you can think of in using globals. Thread switching however does occur when using the Value property since properties are executed in the UI context. So here in addition to possible performance loss because of data copy the additional two context switches will further increase the performance problem. Rolf Kalbermatter