12-08-2011 12:34 PM
Hardware: CVS 1454
Two cameras: AVT Guppy F036C
MAX Settings
680x480 Y (Mono 😎 15fps
Speed: 400MBs
Packet Size: 680bytes
Gamma Off
Bayer Pattern: BGBG_GRGR
Connection: Using two firewire cables directly to the CVS
Software: Vision Builder 2010 and Vision Builder 2009
I recently started to create a Inspection in VB2010. When I press "Run Inspection Once" button, it would lose connection with the CVS. I watched the free memory in MAX and it went from 32MBs to 3MBs before it would lose connection. I simplified my Inspection to use fewer states, eliminated most of the variables in an attempt to use less memory. I put the camera settings as low as possible in MAX. Eventually I got it to stop losing connection to the CVS.
Now that I could go through the states after it went through one iteration I saw that one or both of the Acquire Images would fail. Especially if I went into Inspection Interface and back to Configuration Interface. I figured it was a memory limitation since the CVS 1454 only has 128MBs, 96 of which is occupied by VB2010. I got another CVS, formatted it, and installed VB2009 since it had 44MBs of free memory.
In VB2009 I put all of the test steps into one long state. The program has:
two acquire steps in one state
two states for creating ROIs(one state for each image) for a total of 2 Select Images
a test state which has two Select Image steps, one vision assistant, along with other test steps
If I add one more select image or one more vision assistant those steps will simply fail to do anything. The inspection manages to finish running but anything involving that final Select Image/Vision Assistant will not work.
Has anyone else experience a limitation to the number of select images or vision assistant steps they can use? I have a working inspection now but I need to be aware of the limitations as I try to make more robust Inspections.
Is it a problem with the amount of user space in the CVS 1454 or is there just a limited number of pointers in the VB code that limits the number of references that can be made?
12-08-2011 01:33 PM
There is no limit on the number of steps you can have, just limited by the amount of memory available for those steps. When you run the inspection, how much available memory do you have without that last vision assistant/select image step. How much do you have with it. The Vision Assistant step will create a copy of the image (memory overhead comparable to image size), the Select Image just accesses the selected image (minimal memory overhead here). I assume you know the EVS has much more memory (2GB) and will remove all these troubles and be a lot faster as well...
12-13-2011 12:47 PM
The CVS gets down to about 3MBs in Free Memory before it starts to fail. One thing I started to notice is the camera aquisition step will start to fail around 7MBs. Is there any support for upgrading the 128MBs to something more suitable. Or is the CVS hardware not designed to be upgraded. The memory is the only real issue with the CVS for our applications. Buying a EVS unit would be going a bit overboard.
12-13-2011 04:59 PM
Sorry to say there's no way to upgrade the memory on the CVS.
12-16-2011 12:02 PM
I have managed to reduce the number of vision assistants along with other things in order minimize the memory footprint of the program. The CVS will run the inspection for some amount of parts and then crash. From MAX the memory will float around 10MBs and dip to 7MBs. Sometimes it will do 60 parts before failing other times it will 5. Is there a chance the garbage collection for memory is causing old data to stick around? Or is there some other issue beyond memory I should consider.
12-16-2011 12:25 PM
My bet is you're just too close to the memory limit on that device. A quick test would be to just acquire images from your camera(s) without any Vision Assistant/processing steps and make sure this works for long periods of time without problems. Use the same cameras, and triggering settings to make it as close The Vision Assistant steps make a copy of the image (as well as Threshold). You can use the Select Image step to see which steps create a copy of the image. If you are really dead set on the CVS, you could try replacing the steps that make a copy of the image with a Run LabVIEW VI that does the same same functionality and minimize the copies you do in the Run LV code. This should save you your image size x the number of processing steps you can replace with Run LabVIEW. You're kind of at the edge of what the HW can do, so I wouldn't normally recommend this, but if you're desperate and don't want to upgrade HW, you could try using Run LV to help do several of the steps in VBAI that are making copies of the image.
Hope this helps,
Brad
12-16-2011 12:45 PM
Yeah I figured I was already on the edge of capability. I just found the inconsistent behavior odd. If the program was the problem I thought it would not run or run for a couple then crash. I only acquire from two cameras and now have one vision assistant, and two select images. I already am using a Run LabView to handle some of the computations. On another note is there a Diagnostic program that can display memory in Real Time. MAX requires a button press to collect this information but I tend to not see the lowest value.
12-16-2011 12:57 PM
When you are connected to the target in VBAI in Configuration Mode, you can go to Target>>Target Information in the menu. Also, if you don't need the Video Out on the CVS, you can save memory by going to Target>>Target Options and choose Video Mode. Make sure it is set for the smallest size and the lowest color quality, and these should free up some memory.
Good Luck!