02-04-2011 05:27 PM
Yeah I tried LoadAsync and it was really strange. The timing chart looked great, but each time an image loaded there was an obvious delay that occurred. I could see the timing chart kind of stutter, but the line stayed at 33 ms. Honestly I have no idea how that's happening. When I get back to the lab I can try it with the real setup where the timing is hardware driven and see if I get any dropped packets. I think I would rather have a delay forced and know how long it is than use the async and not know the exact delay that occurred before the image was drawn, though. I can only make it down to about 0.2 seconds before the timing gets thrown off, so obviously my laptop doesn't measure up to your computer. Does the stutter not occur for you?
Thanks again for the help, and let me know if you happen to think of any other ideas.
02-04-2011 06:22 PM
So what is it you're really trying to achieve as the picture timing is so important?
/Y
02-04-2011 06:55 PM
We're recording neural signals and looking at the brain's response to different stimuli and thoughts or actions (where the thoughts or actions would be cued by the stimuli). It's important that we can line up the presentation of the stimulus with the signals as precisely as possible.
02-06-2011 05:37 AM
Hi Jwkelly,
As i cant open your vi's as i only have 2009 i dont know if i fully understand your problem. In one of your replies you said that the asynch was faster but had the downside of not allowing you to know exactly when the image was displayed. Could it be an option to upload the picture using async with the 2D picture control visibility off. Once the image has been loaded then set visibility to true? You will then know the exact point that the image is visible.
Rgs,
Lucither.
02-06-2011 04:02 PM
Despite my previous attempts making me think that switching the visibility of the controls on and off would cause a big enough delay to make it not work, that actually seems to be working. I can still notice a stutter in the timing chart, but the line stays at 33 ms. And everything looks to me like it's deterministic. Hopefully I'll get the same results when I hook everything up and the timing is hardware driven. I've attached two VIs that are updates of Yamaeda's last version of my little demo VI (I tried to save them so they'll work with LV 2009). imgDisplay_demo3 seems to be working, but imgDisplay_demo4 still has the delay. The picture display is done the same way, but one has an event structure. For my own sanity, and maybe to improve my future code, any ideas why the one has the delay and the other doesn't?
Also, I've read there are some more efficient methods of displaying pictures with an IMAQ Image Display Control that comes with NI-IMAQ or NI Vision. I don't seem to have this on my installation. Does anyone have any experience with that?
02-06-2011 04:32 PM
Sorry I forgot to mention that if you replace the event structure in imgDisplay_demo4 with a case structure that depends on Switch Image and add a delay in the while loop surrounding that structure, the problem goes away. So basically if you switch to polling instead of using the event it works. I've never had a problem with event structures like that.
02-07-2011 01:06 AM
I made a slightly more advanced version at home with events, thought i posted it ... oh well.
If you only ever want 2 pictures, why make it complicated? Put them in a tab control and switch. 🙂
/Y
02-07-2011 09:06 AM
I rarely ever only want 2 pictures. That was just for the purpose of simplicity in the demo.