In configuration mode, things run slower on the smart camera because we synchronize execution with updating info on Windows about step status/state executing, etc. When you run in inspection mode, it runs as fast as possible, so there may not be as much available processor time to handle the variable access requests from your C application. Is your inspection acquiring triggered images, or going as fast as the smart camera can possibly go (i.e. non triggered in immediate mode)? If you are in free run mode, what happens if you change to wait for next...this may give the processor a little more time to update variable requests while it's waiting for the image to be acquired. Another way to test this theory would be to put a delay step in your inspection and see if that works (start with 100ms and if it works, see how small you can make it).
Something that might also help is to define the variables on your host machine, and in VBAI create a network variable that binds to the variables defined on your PC. This way, the shared variable engine on RT doesn't have to handle updates from your PC as well as updates from VBAI, as well as running the inspection as fast as possible, and your C application shouldn't have any trouble accessing variables on the same machine. It does mean that your PC needs to be up and running when your inspection runs on the smart camera or else there will be timeout errors accessing the variables...but this may be alright for your application. Here is a nice document that talks in depth about shared variables.
http://zone.ni.com/devzone/cda/tut/p/id/4679
Another option might be to use TCP, serial, Ethernet/IP, or some other protocol to read/write variables in VBAI.
Hope this helps,
Brad
