IMAQdx timestamp off-by-one

Question

I have a network camera and it provides its own timestamp via the IMAQdxTimestampHigh and IMAQdxTimestampLow properties. I'm observing something I don't expect -- the timestamp appears to be off by one image.
I have a simple VI that shows this behavior. In it, I open an IMAQdx session with my camera, configure a grab, reset the timestamp counter, and read the images sequentially. When examining the timestamp associated with each image, the first image has what appears to be the Nth+1 image's timestamp from the previous grab, as if stale data was left in memory.
To see this behavior, run the "Exercise Timestamp Reset.vi" twice. Before you run it the second time, take note of the value for "Last Timestamp". When you run it the second time, the value for "First Timestamp" is slightly higher than "Last Timestamp", which suggests stale data. I would expect "First Timestamp" to be close to zero.
What could be causing this behavior, and how can I fix my code? So far, I've tried:
Moving the "Reset Timestamp Counter.vi" so that it is called immediately after creating the IMAQdx session,
Creating an IMAQdx session, resetting the timestamp counter, and clearing the session before creating a second IMAQdx session for the grab.
My particular configuration:
Allied Manta MG 504B ASG
LabVIEW 2009 SP1
IMAQdx 3.9.1
Solved!
Go to Solution.
Attachments:
Exercise Timestamp Reset.zip ‏50 KB

Answer 1

BlueCheese wrote:
Maybe I used the wrong terminology here.... Its not so much "subverting the firewall" as processing the GigE Vision-related traffic at the lowest layer in the network driver, well before it gets handled by the network stack and any firewalls in the system. This is somewhat implied by using the "High Performance GigE Vision Driver". The firewall is still in place for any other traffic to the system.
When you are _not_ using the high-performance driver, the GigE Vision data does go through the firewall. However, since the reception is done in the OS kernel for performance reasons the firewall doesn't work quite the same way as through applications. The various exceptions you can modify on the list relate to individual programs, not the kernel. The kernel effectively has unrestricted access to the network stack. However, because of the way the firewall works it does end up blocking UDP traffic that is not "connection-based" -- in that UDP inbound traffic is not allowed unless outbound traffic along the same path was recently detected. In the original GigE Vision 1.0 standard there was always a unidirectional path with no way to make it appear bidirectional. In later versions a feature was added that made it possible and today most cameras support it. This is the "Firewall traversal" feature that I mentioned earlier that can be enabled inside IMAQdx. This is likely the easiest option and doesn't require any changes to your firewall configuration.
Thanks for your clarification -- I'm not so alarmed :-)
I was able save another Wireshark capture after enabling Firewall Traversal, and this time I saw a lot more traffic. I set the camera's PacketSize to 1200 and saw many UDP transfers just above that size.
One thing that was a bit strange: I could only enable Firewall Traversal from MAX via View Options » All Attributes and then checking the box for AcquisitionAttributes » AdvancedEthernet » FirewallTraversal » Enabled. I didn't see an equivalent in the LabVIEW Class Browser: Firewall Traversal was not present in the Advanced Ethernet submenu. I didn't see any filtering options for the property node either (I've seen that before in DAQmx). It was only discoverable as AcquisitionAttributes::AdvancedEthernet::FirewallTraversal::Enabled by using IMAQdx Enumerate Attributes.vi. I suppose that the driver doesn't keep a cache of some attributes and relies on run-time detection instead.
At any rate, I would be grateful if you can inspect whether or not the camera is sending bad timestamps. I am still waiting for a response from Allied about a firmware update.
Attachments:
firewallTraversal.zip ‏3388 KB