Hi Christian,
I have a few questions/clarifications based on what you said so far:
-You checked for resends, but did you also look at the cumulative lost packets property node entry? If for some reason the camera was not reporting resend capability correctly it won't even try to do resends.
-The High Performance driver will be listed in device manager under the network interfaces section. You should see either an Intel Pro/1000 or an entry for the High Performance driver. You can select properties on the device, go to the driver tab, and select a different driver. You should have a choice between the two drivers. You can only get a packet capture of the image data if you are using the standard driver for your network card, not the NI one.
-When you mentioned that only the first 2 images in a sequence of 10 had the fully-populated info, do you mean the custom data was completely missing? Or do you mean that the values of the other members were 0 or something like that. You should be seeing the same information populated in all of them.
-What kind of acquisition are you using? You mentioned that you did a 10-image sequence, but then you mentioned that the timestamps started missing after going through the number of buffers in the ring. You only have a ring of buffers that get re-used in a continuous acquisition (using the Grab VIs). If you use the Sequence VIs it uses a buffer list as large as the number of buffers you are acquiring total. I'm not sure how the buffer list size in a continuous acquisition would affect the timestamp data, so I'm thinking it was just a coincidence. Can you increase the buffer count to something like 50 and see if you see the same behavior? Also, can you try the same with a Sequence example as well?
-It sounds like you are making an interesting system. However, I'm not sure if these timestamps are necessarily going to be that useful for you. Firstly, the timestamps come from an internal clock in each camera. If you have multiple cameras, the clocks will eventually drift out-of-sync since they will be incrementing at ever-so-slightly different rates. Since you are already hardware-triggering the cameras (presumably from the same signal), then you should be assured that the images will be in sync with each other. The only thing you may need to worry about is if you end up skipping an image on one but not the other. There are two ways this could happen, and both are avoidable if you are careful in your design. The first is that your image processing loop could be too slow and so you end up not being able to process every image that comes in all the time. If you ask the Grab VIs for the "Next" image, then you could easily see this. If instead you ask for specific buffer indices each time you can have better control over ensuring you get synchronized buffers each iteration. The second possibility is if you are using a buffer ring size that is too small you can run into a situation where a particular buffer has to be completely skipped and never even gets saved into the ring. Images that get skipped in this manner do _not_ get counted in the buffer indices. Thus if you skip a buffer in this manner on just one of the cameras, there will now be an offset in the synchronized indices between the two cameras. You can check for this with the Lost Buffers property. However, this does not come up normally except in extreme cases with high frame rates and very small buffer lists (like 1-2 images). If you make the buffer list be say 10 images or more, there is very little chance of this happening.
Hope this helps,
Eric
