@JDorsey wrote:
just reading some documentation on the way home. CVB requires me to set the NIC address to 169.254.x.x on subnet 255.255.0.0. Does NI-IMAQdx really require me to use DHCP and wait for the DHCP timeout (on XP)? If this is an absolute requirement then that could be the solution (although it would mean IMAQdx is not strictly GigE compliant.
Any thoughts on whether this could be the answer anyone?
Setting a 169.254.x.x address with a subnet mask of 255.255.0.0 will be sufficient. All IMAQdx requires is that the camera's address be correctly addressable by the host PC. Generally we recommend customers configure everything to "automatic" so both the camera and the host follow the link-local address mechanism described by RFC 3927. If you manually configure a 169.254/16 address then you violate this RFC and need to take care not to cause conditions that could make the the mechanism to fail. Generally though as long as you can ping the device, your IP connectivity is set up properly and IMAQdx should work correctly. Also, in Windows Vista and above, the link-local process no longer takes 60 seconds so there is no advantage to hard-code a staticlly-assigned link-local-esq address.
As for your original problem(s), I have some thoughts:
It seems that the problem with the PeakBandwidth attribute and the SCPD attribute is ultimately caused by the fact that their XML file seems to specify a maximum value of the bandwidth available that is not 1000Mbit. The test code in the attribute validator tries to set it to the maximum, then check if it is valid. When we set it, it has to be translated from Mbit/sec to camera clock ticks in the SCPD register. Generally since the max value of thr bandwidth control is derived from the range of SCPD, this number should be equivalent. However, since it is floating point math, you don't end up with an exact integer amount and there must be rounding here. It appears that IMAQdx only rounds the SCPD register _down_ even though apparently in this unique case it needs to round _up_ (which is generally not the case since most only have limits on how much you can throttle it, not how little). In general this issue should only affect the validation tool (I think). As long as you don't modify the PeakBandwith attribute (or set it to one notch below the ~996 value it maxes out at) it should not be a problem.
As for the test packet failure, have you tried changing the packet size to 1500 bytes? If that works it could indicate an issue with receiving jumbo frames (possibly other network hardware like a switch in the path)?. If it still doesn't work, you could possibly try disabling the Test Packet support under the Advanced Ethernet settings of the camera attributes tab in MAX (you might need to enable the "Show all attributes" filter on the tree first). In general when you get this failure it is not a fault of the test itself but rather that the packets aren't getting through. This means that if you disable the test packet you'll simply get a more general timeout error instead. However, there have been one or two rare exceptions where specific cameras have had "broken" test packet implementations that did not work properly. However, all of those that I know about were fixed in updated camera firmware long ago.
Hope this helps,
Eric
