VBAI 2010 Fatal Error (NaN to number)

[eberg]

I'm getting a fatal error (see attached banner image) that I have never seen before in VBAI 2010:  A NaN value in a calculator step gets interpreted as a large negative number (-2.14E+9) in a subsequent Create Region of Interest Step, which in turn causes the subsequent Edge Finder to trigger the fatal event.

The root cause, in this case, is a missing measurement (a frequent occurence for this and other similar calculator steps in this routine), the x-coordinate for an edge enpoint in previous step, from which I subtract a 2, i.e., I'm trying to set an ROI boundary 2 pixels away from the previous edge found.  Typically, when I have a missing measurement in this situation, the subsquent ROI ends up at the image origin (0,0), but VBAI does not crash. 

I fully undestand why VBAI crashes with an ROI edge set so far out in "Left Field", but I'm at a loss to explain why an NaN caclulator output get's interpreted as  -2.14E+9.  When stepping through the routine in Configuration mode and editing the Create Region of Interest step, a message indicates that a "missing measurement is being replaced by a constant" or something to that effect, and the constant turns out to be  -2.14E+9, so I assume that this same process takes place in the background when in inspection mode.  But what I don't understand is why my routine has never thrown this error before when the measurement was missing, but as of this morning, it throws the error every time!

I've got a temporary work-around (check for NaN in the calculator step and force to zero if needed), but I have a large number of similar sequences to fix and want to make sure I understand why this fatal error suddenly appeared.

All ideas appreciated,

Eric

[Brad · Accepted solution]

This is fixed in VBAI 2011 and newer. It will no longer crash with the updated VDM dlls and in VBAI, if a previous measurement used by the ROI step is NaN, the ROI step will treat it as a missing measurement and the ROI step will fail. The reason NaN gets cast to a huge number is because NaN is only valid for double values, and the ROI coordinates are integers, so when we internally convert the NaN to an integer, it gets interpreted as a large number. Not sure why this would just start happening today though.

Hope this helps,

Brad

[eberg]

Brad,

Thanks.  That helps, since we're planning to got straight to 2012, I will only have to apply my work-around "as needed"  at this point it only appears to be the on sequence that throws the error, while it's mirror image, inspecting the other side of the product has yet to throw the error.  Hopefully, 2012 will be released and have passed our evaluation before I have to patch every instance.

Eric