Because a USB connection provides lower bandwidth and higher latency than the PCI bus, the Measurement Computing USB 1024LS discrete I/O device cannot offer the same level of performance as the PCI-based device.

In particular, USB speeds limit the rate at which data can be output and pulses generated, so pulse widths may appear larger than specified. On any I/O device, long pulse widths specified in Communications Explorer can cause data to be queued, and the queues may overflow.

Workaround:

If your application uses the USB device, you should observe the following guidelines:

• Do not attempt to use the 1024LS for applications with a part rate in excess of 120 parts per minute.
• Increase the Poll Rate value. Do not specify a Poll Rate of less than 100 msec for the device.
• Do not configure the 1024LS to transmit a heartbeat signal.

This section describes open issues concerning MVS-8600 acquisition in VisionPro 9.3 SR1.

Image corruption can occur using the Basler raL4096-80km when acquiring more than 6000 lines in a medium tap configuration.

The maximum line trigger rate for an MVS-8602e frame grabber with a Dalsa P3-80-12K40 line scan camera is 14.7 kHz. A line trigger rate above 14.7 kHz will cause your application to lose image information. At a 14.7 kHz line trigger rate, the maximum exposure setting is 68 microseconds.

Workaround:

If your application requires an exposure setting higher than 68 microseconds, you must use a lower line trigger rate than 14.7 kHz.

When using the MVS-8602e frame grabber with a Medium Line Scan Dalsa Pirhana P2-4x-8K only in Manual trigger model acquisition can suddenly stop acquiring. Other trigger models are not affected. To restart acquisition disable then re-enable triggers programmatically.

With two linescan 8602e FIFOs configured to run with auto triggers and sharing an encoder, adjusting the height while acquisition is in progress on one FIFO stops acquisition on the other.

Workaround:

Disable and re-enable triggers to restart the acquisition. Alternatively, Cognex recommends you stop image acquisitions prior to changing any acquisition properties.

For area scan cameras, the MVS-8600 acquires the full image returned from the camera, and then returns the requested ROI set by the user by performing a software cropping operation. As a result, there is no speedup in image acquisition rates when you reduce the ROI from full size, even if the camera hardware supports faster acquisition rates with a smaller ROI.

To acquire at faster frame rates with small ROIs, change the ROI in the camera using the serial interface, and then set the software ROI property for the acquisition FIFO to be the same size as set in the camera settings. Note that the image is always returned starting at the top left corner. So, for example, if you set the camera for (100, 200, 400, 600) as the hardware ROI, set the software ROI property to be (0, 0, 400, 600).

The combination of Dalsa P2-2x08k40 line scan camera and Dalsa DS-21-02M30 area scan camera, both connected to one MVS-8602, is not supported in this release.

In a test setup using these cameras, a portion of some lines were dropped from images acquired by the line scan camera. The test setup used the automatic trigger model with the line scan camera set for 4 Hz acquisition and the area scan camera set for 8 Hz acquisition. The dropped portion was about 25 pels of about six lines per 1.1k frame.

The I/O cable between the MVS-8600's Hirose HR10 port and the 8600's I/O connection module (P/N 800-5885-1) must correspond to the currently loaded software I/O configuration, as described in the MVS-8600 Hardware Manual.

If you have the I/O cable for I/O configuration 1 or 2 attached to your I/O connection module, and you have strobe devices connected to the I/O module, and you change to I/O configuration 3 in software, then you have changed the strobe output lines on Hirose pins 7 and 12 into encoder input lines. In this unsupported circumstance, any state change on those lines would have undefined results for the strobe devices and for the MVS-8600.

An analogous mismatch would occur if you have the cable for I/O configuration 3 attached, and an encoder device attached to the I/O module, and you change in software to I/O configuration 1 or 2.

When changing I/O configurations in software, make sure you have the correct corresponding I/O cable attached before powering on the MVS-8600.

The MVS-8601 has one physical camera port and only one valid Camera Link virtual serial port, yet it reports the presence of two Camera Link serial communication ports. Under normal circumstances, with a single MVS-8601 using a single camera, you always use Camera Link communication port 0 to address the camera. The second, spurious "ghost port" goes undetected and does not cause problems. However, the ghost port can cause confusion under the following circumstances:

• If you use a third-party Camera Link communication utility, such as the one provided by Basler, that utility may enumerate a list of available ports in a dropdown list, and thus may report the presence of the ghost port. In this case, attempting to communicate with the non-existent ghost port will produce no acknowledgement.
• If you use the Cognex Camera Link Serial Communication Utility, and you type the number of the ghost port in the port field and click the Connect button, the connection attempt does not succeed.
• If you have more than one MVS-8600 in the same host PC, port numbering for communication with attached cameras may not be what you expect.

Some examples will clarify the last bullet point. Let us say you have one MVS-8602 and one MVS-8601 in the same PC. Because there are three physical camera ports in this combination, you might expect to find three Camera Link serial communications ports, one per camera port. Against this expectation, however, you will find an extra communication port is present.

If the PCI bus assigns a lower board number to the 8601, you will see a configuration like this example:

Camera Link serial ports if 8601 gets the lower board number: 
8601-cam0  = 0   (corresponds to 8601 camera port 0)
8601-ghost = 1   (no corresponding camera port)
8602-cam0  = 2   (corresponds to 8602 camera port 0)
8602-cam1  = 3   (corresponds to 8602 camera port 1)

Camera Link serial ports if 8601 gets the lower board number: 
8601-cam0  = 0   (corresponds to 8601 camera port 0)
8601-ghost = 1   (no corresponding camera port)
8602-cam0  = 2   (corresponds to 8602 camera port 0)
8602-cam1  = 3   (corresponds to 8602 camera port 1)

If you have more than one MVS-8600 in your system, the boot time assignment of board numbers to PCI boards can complicate the numbering of Camera Link serial communication ports.

The assignment of board numbers to PCI boards is determined by a combination of the PC's BIOS, Windows hardware enumeration, and the PCI slot numbering scheme used by the motherboard's manufacturer. You cannot control the board number assigned to a given PCI board. You can, however, influence the number assigned by the bus by moving boards around to different slots, using the motherboard's PCI slot numbering documentation as a guide.

With multiple MVS-8600's in a system, the Camera Link serial communication port numbers will depend on which board is assigned the lowest PCI board number. The example shown in the previous note would be changed as follows if the PCI bus assigns a lower board number to the 8602 instead of the 8601:

Camera Link serial ports if 8602 gets the lower board number: 
8602-cam0  = 0   (corresponds to 8602 camera port 0)
8602-cam1  = 1   (corresponds to 8602 camera port 1)
8601-cam0  = 2   (corresponds to 8601 camera port 0)
8601-ghost = 3   (no corresponding camera port)

Camera Link serial ports if 8602 gets the lower board number: 
8602-cam0  = 0   (corresponds to 8602 camera port 0)
8602-cam1  = 1   (corresponds to 8602 camera port 1)
8601-cam0  = 2   (corresponds to 8601 camera port 0)
8601-ghost = 3   (no corresponding camera port)

It might be difficult to determine which Camera Link camera is connected to which serial communication port when using the Cognex Camera Link Serial Communication Utility to communicate with and set up cameras. OEMs might be looking for a way to automate the setup of more than one Camera Link camera connected to one or more MVS-8600 boards in the same host PC, without knowing in advance which camera is connected to which port. The following points describe why blind advance setup is difficult.

• There is no programmatic way to determine which camera is attached to a given port.
• In a system with two MVS-8600s, the "ghost port" issue described above can make it difficult to determine programmatically which Camera Link communication port goes with which board.

The most clear-cut way to configure a Camera Link camera is to configure one camera at a time, while only one camera is connected to camera port 0 of a single MVS-8600, and then save the configuration in the camera's non-volatile memory. The Cognex Camera Link Communication Utility provided with this release, along with the command set file for each camera, provide the means to configure and save the configuration for each supported camera. The Camera Link Utility is documented in this release's Application Development Guiide.

Once the cameras are set up this way, they can be attached to systems containing multiple MVS-8600s without the need to reconfigure them.

When the first linescan channel is running and hardware is set up for the second linescan channel, a crash may occur. This is caused by a current limitation in the MVS-8600 hardware.

Workaround:

To avoid this issue, always set up both channels with the properties required before enabling triggers or starting acquisition on either channel.

Changing an acquisition FIFO property may cause the strobe on the MVS-8602 to fire even if the strobe is not enabled.

The MVS-8602 supports one camera lookup table (LUT) that is shared by both camera ports. The LUT must be initialized if needed before acquisition starts from a camera on either port. If acquisition is active when the LUT is set, acquisition may fail or a corrupt images may be returned.

This section describes open issues concerning persistence in VisionPro 9.3 SR1.

The Microsoft SOAP XML formatter can not be used to persist VisionPro objects that include generic collections, including the CogToolBlock.

This limitation only affects user-written persistence code. The VisionPro user interface does not allow you to specify the persistence formatter.

Workaround:

Use the binary formatter.

This section describes open issues concerning the Cognex image database (CDB) in VisionPro 9.3 SR1.

If you are recording images to a TIFF file using the CogImageFileTool and you add both monochrome and color images to the same file, the tool may crash if you attempt to scroll through the image display thumbnails in the control.

Workaround:

Do not attempt to view thumbnail images while recording different image types to a TIFF file.

This section describes open issues concerning the Cognex Communication Card in VisionPro 9.3 SR1.

Calling CogPrio.DisableEvents() at the same time as an event response is pulsing an output line may prevent the output line from completing the pulse. After which, the output line may become unresponsive forcing the application to be restarted.

After installing the latest VisionPro release on a PC using Microsoft Windows 7, the device driver for the Cognex Communication Card might not be properly installed and the PC will not recognize the hardware. For example, an object of type CogCommCards contains no instances of a CogCommCard, and the Cogtool utility does not recognize the Cognex Communication Card is installed.

In the Device Manager, the Cognex Communication Card can appear listed under Cognex Hardware as Cognex I/O Card instead of Cognex Communication Card 24C.

Workaround:

1. Open the Device Manager (Windows 7: Control Panel -> Device Manager).

2. Right-click on the device and choose Update Driver Software....

3. Select Browse my computer for driver software.

4. Browse to the directory for the Cognex Drivers (the default is C:\Program Files\Cognex\Common\Drivers).

5. Click Next to install the device driver for the Cognex Communication Card.

6. Check the Device Manager again to verify the hardware appears as Cognex Communication Card 24C.

This section describes open issues concerning edit controls in VisionPro 9.3 SR1.

If you change the value of property using an edit control, and the underlying vision tool converts that value to an equivalent or substitute value, the control may display the value you entered rather than the value used by the underlying tool.

For example, if you set the Skew value of an CogRectangleAffine to 90°, the Skew will automatically set it to 90.002° to avoid specifying a degenerate affine rectangle. The control will update to read "90.002". However, if you set the Skew value to 90° again, the control will read "90", but the underlying value will remain unchanged at 90.002°.

If you delete the last item from a grid control within a VisionPro tool edit control, then use the up arrow key to scroll up through the grid, the grid will not display the first item in the grid.

Workaround:

You can force the grid to scroll to the top using the scroll bar.

This section describes issues concerning image display.

Windows 10 operations that result in the loss of the viewing surface may cause VPro to crash if the 2D Display is active on the screen. Examples are locking the system using CTRL-ALT-DEL or when a display goes into sleep mode.

The Cog3DDisplayV2 's API provides different rendering mode settings. The non-default DisplayMode.Vertices can cause a crash if the graphics hardware/driver is not DirectX 11 compliant. This issue has been seen on Vision Controllers that have the Intel HD3000 graphic hardware as the available driver supports DirectX 10.5.

On some PCs and laptops the image and graphics shown in CogDisplay can appear corrupt. The problem is known to occur mostly on Windows 7 (32-bit and 64-bit).

Workaround:

Upgrading to a newer video driver from the video card manufacturer can often resolve the issue. For PC's and laptops that have integrated video, resizing the CogDisplay window can often resolve the problem.

If you attempt to repeatedly transform the same image using the functions in the CogImageConvert object, and you have set a CogDisplay control's Image property to refer to the image, your application may experience a run-time error. The following code illustrates the problem:

Dim myImage As Cognex.VisionPro.ICogImage
myImage = CogImageConvert.GetHSIImage(myDisplay.Image, 0, 0, 0, 0)
myDisplay.Image = myImage
myImage = CogImageConvert.GetIntensityImage(myDisplay.Image, 0, 0, 0, 0)
myDisplay.Image = myImage

Dim myImage As Cognex.VisionPro.ICogImage
myImage = CogImageConvert.GetHSIImage(myDisplay.Image, 0, 0, 0, 0)
myDisplay.Image = myImage
myImage = CogImageConvert.GetIntensityImage(myDisplay.Image, 0, 0, 0, 0)
myDisplay.Image = myImage

Workaround:

You can prevent this problem from happening by not using the same image to store the results of multiple conversions

You cannot retrieve the last image from CogDisplay using CogDisplay.Image after stopping live display. To get an image, capture another image from the acquisition FIFO after stopping live display

This section describes open issues concerning documentation in VisionPro 9.3 SR1.

If your VisionPro application generates an error (that your application does not handle itself), clicking the Help button in the error message dialog may not load the VisionPro help topic for that error

Workaround:

Open the help system manually and find the error in the "Errors" section.

Many functions and properties include NullReferenceException in their list of exceptions. In fact, this exception is never thrown.

Links in the VisionPro.NET programming reference that refer to functions with overloads may not work. If this happens, you can get to the documentation for the function by browsing the table of contents or searching for the function by name.

This section describes open issues concerning drivers in VisionPro 9.3 SR1.

VisionPro can report a security violation just after installation when using an MVS-8704e frame grabber to enable licenses because the device driver for the MVS-8704e is not running.

Workaround:

Reboot the PC a second time to start the device driver for the MVS-8704e.

Upgrading the OS on a PC that has VisionPro already installed can negatively impact the functionality of Cognex Drivers.

Workaround:

Uninstall Cognex Drivers before upgrading the OS on a PC that has VisionPro already installed.

During testing, Cognex has observed some PCs to take a relatively long time (5-6 ms) to respond to interrupts. This long latency does not cause problems with most VisionPro applications. However, when the acquisition rate is higher than one acquisition in every 6 ms, this prolonged delay could cause interrupts not to be serviced on time, resulting in missed acquisitions. The long latency of some PCs can also cause problems with other devices that require timely interrupt response.

The followings PCs are known to exhibit this problem:

• IBM Intellistation Z Pro: model # MT-M 6221-22U (2.66 GHz Xeon single CPU)
• IBM Intellistation M Pro: model # MT-M 6219-42U (3.06 GHz P4 single CPU)

This problem has implications for acquisition with a region of interest (ROI). For small images, the frame rate can be higher than usual, potentially causing interrupt overrun. The noted problem can therefore occur when using cameras that support ROI control and decimation with the MVS-8500, which supports partial scan (with the same end result as ROI).

This section describes open issues concerning the DS1000 series sensor in VisionPro 9.3 SR1.

Some settings for Peak Detection Mode might result in the wrong peak being selected when used with HighDynamicRange. Cognex recommends that HighDynamicRange be used only when Peak Detection Mode is set to Max.

When changing the IP address on a DS1000 series sensor, if the firmware is incompatible with the release you will receive an erroneous error. This error should be ignored. Note that you will need to upgrade the firmware before the sensor can be used with the VisionPro release, but before you can upgrade the firmware you must set a valid IP address, and thus will see this spurious error.

If Line Finding Mode is set to Binary and Peak Detection Mode is set to Closest, the proper position of the laser line might not be detected if its thickness is equal to Binary Peak Width. The problem does not appear when the laser line is greater than the value of Binary Peak Width.

If you configure a DS1100 to use Semi-Trigger acquisition and Intensity (or IntensityWithGraphics) mode, and you then queue more than a single acquisition start, a single triggered acquisition will occur and the acquisition system will fail to acquire on subsequent triggers.

Workaround:

You can prevent this error from happening by not queuing multiple starts when in Semi-Trigger Intensity mode. Be aware that calling StartAcquire( ) while an acquisition is in progress is the same as queuing more than a single acquisition start.

If you configure a DS1100 to use Manual or Semi-Trigger acquisition, and acquire images greater than 10922 lines, calling ICogAcqFifo::StartAcquire( ) more than once before calling ICogAcqFifo::CompleteAcquire( ) will cause acquisitions to hang after the first or second image.

Workaround:

You can prevent this error from happening by not having more than one outstanding acquisition at any time. In QuickBuild, set Number of Software Acquisitions Pre-queued to 1 (the default setting) in the Configure Job Properties dialog box.

If you configure a DS1100 to use a test encoder, the following properties are inoperative, even though their controls are enabled:

• Single Channel Encoder
• Positive Acquire Direction
• Encoder Resolution

The DS1100 sensor will begin an acquisition immediately if the trigger input is active when the camera is enabled for acquisition. This means the image will not be synchronized with the active-going edge of the trigger signal.

To avoid this effect:

• 1. Make sure the trigger signal is inactive when calling start( ) in semi-auto trigger model, or when enabling trigger in auto trigger model.
• 2. Do not change acquisition properties while triggers are enabled in auto trigger model. In QuickBuild, this means the Image Source settings should not be adjusted while the job is running.

VisionPro does not generate a value for the maximum line rate when using a DS1100 sensor.

Workaround:

• Configure the exposure, high dynamic range, and ZDetection settings.
• Acquire a peak or range image regardless of whether the encoder overruns.
• Read the CPCyleTimeUSec feature from the camera.
• Maximum line speed (lines per second) is approximately 1,000,000 / CPCycleTimeUSec.
• Go back to step 1 and adjust parameters until step 4 produces a number suitable for the application.

This section describes open issues concerning the DS900 series sensor in VisionPro 9.3 SR1.

When field calibration is used with a DS900 sensor and "Remove Skew from Image" is disabled, the x, y, and z scales on the Calibration tab are ignored and default values will be used for both x and z scales. The y scale will depend on the encoder settings.

When using a DS900 series sensor with field calibration enabled, non-default values for image width and the scaling factor in the horizontal (x) direction can cause image data to be lost in an output image.

Workaround:

Use the default value of 1280 for the Width parameter on the Image Properties tab, and the default value of 0.03125 for the XScale on the Custom Properties tab.

The maximum line rate for the DS900 series sensor is 1200 Hz. Attempting to acquire at a line rate greater than the measuring field supports can cause one of the following issues:

• For measuring fields that support 1200 Hz, slightly exceeding 1200 Hz may cause dropped lines or hangs instead of overrun errors.
• For measuring fields that are limited to less than 1200 Hz, slightly exceeding the specified line rate will report overrun errors.
• At very high line rates, hangs may be observed regardless of the measuring field.

Workaround:

The DS900 sensor cannot be configured for a line rate higher than 1200 Hz. Correcting the setting should restore normal operation.

When using an encoder to control the rate of acquisition of a DS900, small changes in direction (as may happen due to vibration in the motion) may trigger encoder overrun errors or repeated acquisitions of the same line. For best results, the encoder should always indicate a steady direction of motion. If this cannot be achieved, enabling IgnoreTooFastEncoder may allow the DS900 to ignore the unwanted motion and still produce accetpable images, at the cost of not being able to detect when the encoder is truly running too fast.

The DS900 series may produce acquisition errors which include "AUTO_ABORTED" in the exception message. This can happen when very short range images are acquired at a very high line rate. It is recommended to acquire range images that are at least 10 lines high to avoid this problem.

This section describes open issues concerning the VisionPro development environment in VisionPro 9.3 SR1.

During a typical VisionPro installation, the installer launches the VisionPro Controls Wizard to populate the tool palette in Microsoft Visual Studio with the latest set of VisionPro edit controls.

The VisionPro Controls Wizard might fail to populate the Visual Studio toolbox with VisionPro edit controls if an instance of Visual Studio is running when the utility launches.

Workaround:

Close any instance of Visual Studio and launch the VisionPro Controls Wizard manually from the Start menu by choosing Start->All Programs->Cognex->VisionPro->Utilities->VisionPro Controls Wizard.

When you select Choose Item from the Toolbox in a 64-bit Visual Studio 2010 Windows Form application on a 64-bit OS, Visual Studio might display an error message that begins with the following:

The following assemblies are installed SDK assemblies but could not be shown in the customize toolbox dialog because they are missing one or more components. Please make sure that all necessary libraries are available:

Accompanied by a list of Cognex.VisionPro.* dynamic link library files.

Workaround:

Click OK to acknowledge the message, which can be safely ignored, and continue adding the control to the Toolbox. Another option is to create the project under 32-bit and then move it to 64-bit.

Cloning or copying CogFindLine or CogFindCircle operators from multiple simultaneous threads might fail with a thrown COMException and the error code 0x800A01E1 (CTL_E_INVALIDPICTURE) .

Workaround:

There are two workarounds to this problem.

1. Put a mutex or semaphore around the code that is cloning the CogFindLine or CogFindCircle operators. This mutex prevents the multiple threads from cloning these operators at exactly the same time.

2. Add one of the following code fragments before cloning the operators:

CogFindLine fl = new CogFindLine();
.
.
findLine.ExpectedLineSegment.MouseCursor = Cognex.VisionPro.CogStandardCursorConstants.Default;

CogFindLine fl = new CogFindLine();
.
.
findLine.ExpectedLineSegment.MouseCursor = Cognex.VisionPro.CogStandardCursorConstants.Default;

CogFindLine fl = new CogFindLine();
.
.
CogLineSegment segment = new Cognex.VisionPro.CogLineSegment();
segment.Interactive = true;
segment.GraphicDOFEnable = CogLineSegmentDOFConstants.All;
segment.SetStartLengthRotation(50, 50, 200, 0);
fl.ExpectedLineSegment = segment;

CogFindLine fl = new CogFindLine();
.
.
CogLineSegment segment = new Cognex.VisionPro.CogLineSegment();
segment.Interactive = true;
segment.GraphicDOFEnable = CogLineSegmentDOFConstants.All;
segment.SetStartLengthRotation(50, 50, 200, 0);
fl.ExpectedLineSegment = segment;

When running your vision application in the Microsoft Visual Studio debugger, a pure virtual function call error message can appear after exiting the application. In addition, the error might occur using sample code from previous VisionPro releases.

Workaround:

Call ICogFrameGrabber.Disconnect(false) on all frame grabber objects that have been used by the application. See the Programming Reference for more information.

There is a behavior change when the SubjectChanged event is fired that will only might impact users who create custom edit controls derived from CogToolEditControlBase. This event is fired before OnCreateControl whereas in previous releases is was fired after.

Users can launch a tool edit control by double-clicking on a tool after it is added from the tool palette to the Job. When this happened in earlier releases, the Subject changed event used to get fired after the form's OnCreateControl() protected method is called. In this release, the Subject changed event is now fired before OnCreateControl(). Users might need to adjust any applications dependent on when the Subject changed event is fired.

There is no impact if users add the custom control onto a form in a Windows application because when the Subject is assigned is solely determined by the user.

When you create a Windows application using Visual Studio you may drag VisionPro controls from the Visual Studio toolbox onto the Form(s) of your application. This action sometimes causes Visual Studio to add assemby references to your project. Often, only some of the added references are needed. The others are superfluous and can be removed. For example, any assembly whose name starts with "Cognex.VisionPro.Interop" can be removed.

In future versions of VisionPro these "Interop" assemblies will be removed from the product and any projects that still reference them will begin to emit warnings. These warnings will not prevent your project from compiling, but the warnings are annoying and may obscure other output from the compiler. Cognex recommends that you remove all of these "Interop" references from your project.

For example, if you add a CogPMAlignEditV2 control to a Form in your application the following assemblies will be referenced:

• Cognex.VisionPro
• Cognex.VisionPro.Controls
• Cognex.VisionPro.Core
• Cognex.VisionPro.Display.Controls
• Cognex.VisionPro.Interop.PMAlign
• Cognex.VisionPro.Interop.PMAlignCtl
• Cognex.VisionPro.PMAlign
• Cognex.VisionPro.PMAlign.Controls

You should remove the references to:

• Cognex.VisionPro.Interop.PMAlign
• Cognex.VisionPro.Interop.PMAlignCtl

This will ensure a smoother transition to future versions of VisionPro.

An alternative method for eliminating unneeded references is to manually add a reference to the appropriate "Controls" assembly _before_ dropping the control onto a Form.

For example, if you already have the following common references in your project:

• Cognex.VisionPro
• Cognex.VisionPro.Controls
• Cognex.VisionPro.Core
• Cognex.VisionPro.PMAlign

You only need to add:

• Cognex.VisionPro.PMAlign.Controls

to prevent Visual Studio from adding any of the "Interop" references when you add a CogPMAlignEditV2 control to your Form.

Cognex recommends that you use the CogSerializer object to persist VisionPro .NET objects. If you use the .NET serializers (such as SoapFormatter), then you must add the VisionPro CogSerializationSurrogateSelector and CogSerializationBinder classes to it before using it, as shown below:

myFormatter = CreateMyFormatter();
myFormatter.SurrogateSelector = new CogSerializationSurrogateSelector(myFormatter.SurrogateSelector);
myFormater.Binder = new CogSerializationBinder(myFormatter.Binder);

myFormatter = CreateMyFormatter();
myFormatter.SurrogateSelector = new CogSerializationSurrogateSelector(myFormatter.SurrogateSelector);
myFormater.Binder = new CogSerializationBinder(myFormatter.Binder);

VisionPro includes numerous collection objects, such as collections of results produced by vision tools. All of these collection objects implement the Changed event. In almost no case, however, is this event ever fired.

Cognex recommends that you do not implement an event handler for any collection object's Changed event.

VisionPro does not support the use of multiple AppDomains within an application. If you attempt to instantiate and use VisionPro .NET objects in multiple AppDomains, your application will experience poor performance and unpredictable errors.

The VisionPro .NET CogRecord object implements the ICloneable interface, but if you attempt to clone a CogRecord, only a shallow copy is returned.

If you create a Visual Basic VisionPro application using Visual Studio.NET, the Visual Basic code editor will treat all of the VisionPro interfaces as private, which means that they must be declared and used using long, fully-qualified names.

Workaround:

You can work around this problem by importing the VisionPro .NET assemblies in your Visual Basic project. (Right-click on the project, select Properties, click on References, then select the namespace containing the desired interface from the Imported Namespaces list.)

CogDisplay.CreateMapInfo() is not supported under .NET.

Before adding a VisionPro control to a WinForms form, you must add a reference to the assembly to your project. If you fail to do this, you will get an error message stating that the assembly could not be found.

All Cognex VisionPro classes that support serialization derive from the CogSerializableObjectBase class. There is a bug in this base class that prevents successful serialization of a derived class that happens to include a private data member with the same name as any of the private data members of the base class(es). If you encounter this problem, you can work around it by renaming the private data member within your class.

VisionPro .NET documentation is not integrated into the MSDN 2008 online help. For example, if you press F1 on any VisionPro method, the help page cannot be displayed and if you turn off the filter in index, none of the VisionPro .NET methods are listed.

Workaround:

You can still view the VisionPro .NET documentation from the Start menu: Start->Programs->VisionPro->Documentation->VisionPro .NET Documentation.

The Clone function implemented by the CogToolBlock and CogToolGroup objects does not work correctly: the links between tools are not properly constructed in the cloned object.

This problem affects any copy that you make of those objects.

Workaround:

You can work around this problem by using the serializer to construct the object copy, as shown below:

public static CogToolGroup CopyToolGroup(CogToolGroup aToolGroup)
{
CogToolGroup newToolGroup = null;
using(System.IO.MemoryStream memStream = new System.IO.MemoryStream(1024 * 1024))
{
CogSerializer.SaveObjectToStream(aToolGroup, memStream);
memStream.Position = 0; 
newToolGroup = CogSerializer.LoadObjectFromStream(memStream) as CogToolGroup;
}
return newToolGroup;
}

public static CogToolGroup CopyToolGroup(CogToolGroup aToolGroup)
{
CogToolGroup newToolGroup = null;
using(System.IO.MemoryStream memStream = new System.IO.MemoryStream(1024 * 1024))
{
CogSerializer.SaveObjectToStream(aToolGroup, memStream);
memStream.Position = 0; 
newToolGroup = CogSerializer.LoadObjectFromStream(memStream) as CogToolGroup;
}
return newToolGroup;
}

This section describes open issues concerning GigE Vision acquisition in VisionPro 9.3 SR1.

GigE Configurator defaults to an IP address of 169.254.x.x for GigE network adapter when no GigE Vision cameras are attached.

Workaround:

Plug in a GigE Vision camera and refresh the utility to retrieve the static IP address. Alternatively:

1. Open Windows Control Panel.

2. Select the network connections.

3. Select the adapter.

4. Right-click and select Properties.

5. Double-click Internet Protocol Version 4 (TCP/IPv4)

6. Set the static IP address for the adapter.

A CFG-8704e, a quad-port GigE Vision network adapter, or any network interface card that uses the 82574 Ethernet Controller can go in standy mode where the network port is inactive.

Workaround:

Download the latest Intel driver from the Intel downloads page:

https://downloadcenter.intel.com/SearchResult.aspx?lang=&ProductID=3023&ProdId=3023

The eBus Universal Pro Driver may not be functional on all GigE Vision network interface cards after installation. The GigE Vision Configuration Tool will display Not Installed for the name of the performance driver, and the eBus Universal Pro Driver checkbox will be unchecked.

Workaround:

1. Open the Local Area Connection Properties control for your GigE Vision adapter (Windows 7: Control Panel->Network and Sharing Center->Change Adapter Settings->Change settings of this connection).

2. Select the eBus Universal Pro Driver if it is present and click Uninstall.

3. Close the Local Area Connection Properties control.

4. Check the eBus Universal Pro Driver in the GigE Vision Configuration Tool to install the driver.

If you are using a 32-bit operating system and you attempt to acquire an image larger than 10 MBytes from a GigE Vision camera the acquisition may fail with an abnormal error. The error message will indicate Buffer retrieve failed (GENERIC_ERROR).

Note that the exact image size that causes this error to occur can vary depending on the number of cameras used and available memory.

To avoid this error, reduce the image size or use a 64-bit operating system.

Attempting to modify GigE Vision features for a GigE Vision camera during acquisition can cause QuickBuild to become unresponsive.

The GigE tab and the Custom Properties tab of the QuickBuild Image Source control cannot reliably read and write integer values containing a comma.

Workaround:

Do not specify integer values using commas. For example, use "1234" and not "1,234".

Some cameras may not be reliably discovered in a system with multiple network adapters, where clicking the refresh button in the GigE Configuration tool will cause the camera to randomly appear and disappear.

Workaround:

1. Temporarily disable all network adapters except the one with the problematic camera.

2. Configure the IP address of the camera using the GigE Configuration tool.

3. Launch QuickBuild and configure the Image Source to use this camera.

4. On the GigE tab, enter GevDiscoveryAckDelay in the Feature box and click Read.

5. Change Value to a smaller value, for example 50 instead of 1000.

6. Click Write.

7. Repeat steps 1 - 6 for any other cameras that are not reliably discovered by the GigE Configuration tool.

8. Re-enable all network adapters.

If you are using the SMC Networks SMCGS8P 8-port gigabit PoE switch and you are experiencing abnormal errors errors it may be due to the jumbo frames property is not set corretly.

Workaround:

Consult the vendor's documentation on any new firmware or software available to enable and set jumbo frames on this switch. If that does not resolve the problem, try reducing the bandwidth being used through the switch. A final option is to use a different switch that supports jumbo frames.

Attempting to acquire images with Windows Firewall enabled may or may not result in successful acquisition. After performing acquisition with Windows Firewall enabled the camera can disappear from all applicaitons and the network connection for that camera may be in a bad state.

Workaround:

Cognex recommends you disable Windows Firewall on GigE Vision network connections and reboot the PC.

The installation of VisionPro can appear to hang or otherwise malfunction during the Cognex Drivers installer.

Workaround:

1. Check to make sure all network connection dialogs are closed and reboot the PC.

2. Use Device Manager to un-install the driver for any network cards that are not behaving correctly.

3. Select Action->Scan for hardware changes to re-install the driver.

If you want to manually install the eBus Universal Pro Driver, launch the GigE Vision Configuration Tool and select the checkbox to install it.

Making changes to your network settings while a vision application is running is not supported and can produce unexpected behavior. Exit the vision application, make any changes to network settings, and restart the applicaiton.

Incrementing the X offset for the region of interest to an odd value can change the color mapping of YUV422 packed images from red to blue.

Workaround:

Ensure the X offset increments in even values.

Unplugging and re-plugging a GigE Vision camera while the application is executing can cause the application to crash. This can also happen if a camera temporarily loses power or the data cable is loose. Hot plugging cameras while an application is running is also not supported. GigE Vision cameras must be present at the time the application launches for them to be used.

In some cases QuickBuild will fail to initialize an acquisition FIFO for a JAI GigE Vision camera.

Workaround:

Exit and restart QuickBuild. In addition, Cognex recommends you use the sample Job JAI CM-*GE VisionPro Compatibility sample job located in the Navigation pane under GigE Vision Camera Properties.

Attempting to acquire packed 12-bit monochrome format images with certain Region of Interest (ROI)-based image sizes using a Basler Scout GigE Vision camera may generate abnormal acquisition errors.

Workaround:

Modify the ROI so that both the width and height are even values.

If you are using a GigE Vision camera to acquire a 16-bit monochrome image, the camera may not support the full range (0.0 through 1.0) of contrast and brightness values. In particular, the maximum supported value for both properties may be much less than 1.0. If you specify a brightness or contrast value outside of the range of values that the particular camera supports, acquisition may fail with an abnormal error.

Workaround:

If you experience an error, reduce the brightness and contrast values until the acquisition succeeds.

If you are using a GigE Vision camera and you have selected the Performance Drivers, you may see below-normal acquisition rates when you use Manual trigger mode..

Workaround:

Use the GigE Vision Configuration Tool to remove the Performance Drivers ( select the Remove Performance Drivers menu command).

This section describes open issues concerning installation of VisionPro.

The installation of the prerequisite .NET framework requires a reboot but the installer does not resume the installation after the system has restarted.

Workaround:

Relaunch the VisionPro installer to complete the install.

After installing the latest VisionPro release but before rebooting the PC, the GigE Vision Configuration Utility might crash.

Workaround:

Reboot the PC.

The Cognex driver installers Cognex Drivers 4.7 and “Cognex x64 Drivers 4.7” have no “Change” or “Repair” functionality associated with their installation. It will not be possible to invoke these functions from the Windows Control Panel applets “Programs & Features” (W7 & W7x64), or “Add Or Remove Programs” (XP).

Workaround:

To install Cognex drivers on hardware that has been installed after Cognex software has been installed, uninstall the currently installed driver package, then reinstall it from the original installation location.

The VisionPro installer will display the default installation path if you to try modify a VisionPro installation installed in a non-default directory.

If you try to install VisionPro using the Japanese, Korean or Chinese language setting on a PC using any Western Language version of Windows XP, the installation utility displays an unintelligible dialog box.

Workaround:

You must install the Eastern Asian Languages option from the Regional and Language Options applet of the Windows XP Control Panel.

During an effort to uninstall VisionPro, a dialog box might appear reporting that the installation utility was unable to automatically close all requested applications. The dialog box can be closed and ignored.

If you are using Windows 7 and perform an uninstall of VisionPro, you might see a dialog box warning you that any of the following applications should be closed before the uninstall can continue:

• Cognex Security Service
• Cognex Reminder Service
• Cognex Software Licensing Service

Click OK to continue uninstalling the product.

If you are using two or more frame grabbers of the same type in the same PC, Cognex recommends you reboot the PC after installing the Cognex Drivers for frame grabbers. After driver installation, the board index may be incorrect. Rebooting the PC will properly order the list of boards in the system and this order will remain consistent upon all subsequent reboots. This applies to all MVS-8x00 series frame grabbers, and does not apply to FireWire cameras.

On some PC's with Windows Vista, a reboot might be required after the installation of VisionPro in order for the environment variable VPRO_ROOT to be set correctly. Attempting to start QuickBuild where VPRO_ROOT is undefined will result in a startup problem.

VisionPro automatically installs the Microsoft .NET framework, if it is not already present on the PC. If you manually uninstall the .NET framework, a subsequent attempt to uninstall VisionPro will fail

If you install both CVL and VisionPro, then attempt to uninstall the Cognex device drivers (from either product's installer), the Cognex Reminder Service may no longer work correctly. (The Cognex Reminder Service notifies you when a security key license is about to expire.)

You can correct this problem by uninstalling both products' device drivers, then reinstalling the VisionPro device drivers only using the Cognex Frame Grabber Drivers installer.

Workaround:

You can prevent this problem from happening by installing the VisionPro device drivers only.

By default, whenever you install the Cognex frame grabber drivers, the installer program also installs the drivers to support the HASP4 security key, as well as a reminder service that notifies you when a time-based software key is nearing expiration.

If you manually uninstall the HASP4 driver, the driver files are properly removed but the reminder service may not be removed. The presence of the reminder service files causes no problems for the operation of your PC or VisionPro.

Workaround:

You can manually remove the reminder service by following these steps:

1. Open Control Panel->Administrative Tools->Services, select the Cognex Reminder Service, and click Stop.
2. Delete the files cogremind_srv.exe, cogremind_srvENU.dll, and cogremind_srvJPN.dll from the System32 directory.

This section describes miscellaneous issues in VisionPro 9.3 SR1.

Some virus scanning utilities can incorrectly flag/quarantine VisionPro dynamic-link library (DLL) files. Cognex verifies that all binaries are virus-free prior to being released.

Workaround:

Add the DLL files to the whitelist of your particular virus scanning software.

This section describes issues concerning Model Maker in VisionPro 9.3 SR1.

An existing Visual Studio project containing a CogSynthModelEditorV2 edit control might report a problem opening Cognex.VisionPro.Core.dll. The problem is limited to 64-bit OS machines.

Workaround:

1. Open the file MyForm.designer.cs in the IDE text editor and remove the following line:

this.cogSynthModelEditorV21.Subject = ((Cognex.VisionPro.ICogShapeModelCollection)(resources.GetObject("cogSynthModelEditorV21.Subject")));

this.cogSynthModelEditorV21.Subject = ((Cognex.VisionPro.ICogShapeModelCollection)(resources.GetObject("cogSynthModelEditorV21.Subject")));

2. Open the file MyForm.resx in the resource editor editor and remove the following row from the table:

cogSynthModelEditorV21.Subject

cogSynthModelEditorV21.Subject

3. Save all files and rebuild the project.

This section describes open issues concerning discrete I/O in VisionPro 9.3 SR1.

The assertion of the Data Ready signal by QuickBuild can be delayed if the QuickBuild local display is open. This delay can be particularly noticeable if the local display includes multiple result graphics.

Workaround:

Close the local display.

This section describes open issues concerning QuickBuild in VisionPro 9.3 SR1.

QuickBuild can fail to launch under Windows 8.

Workaround:

If QuickBuild does not launch properly, follow the following procedure to verify that the environment variable VPRO_ROOT is set and that the VPRO_ROOT path is added to the Path environment variable:

1. Open System Properties by clicking Win+Pause/Break.

2. Click on Advanced system settings.

3. In the Advanced tab of the System Properties box, click Environment Variables.

4. Click OK.

5. Click OK.

If a Job containing a CogToolBlock is running in Continuous mode and you attempt to stop continuous mode within the CogToolBlock, the Job does not stop but appears to slow down.

If your image source specifies a configured camera but is currently set to acquire images from an image-database file, opening the Image Source dialog box while the Job is running will cause QuickBuild to crash with a CogNotStopped exception.

Workaround:

Stop the Job and then open the Image Source dialog box.

When vision tools having a variable number of inputs are reset to their default state through their tool edit controls, any links to those inputs must be recreated. Sometimes the links will be drawn before the link is recreated, but inspecting the input point values will reveal that the link is not working. To recreate the links, first create the objects corresponding to the inputs, then drag from source node to destination node.

When adding a terminal to the Posted Items list (by right-clicking on the context menu of the terminal), the item added to the Posted Item list is based upon its unique GUID. If you wish to see the terminal based upon its terminal name you can bring up the property browser from within the Posted Items dialog and navigate to the terminal using its name rather then its unique GUID

Do not use the Reset button in the edit control of a CogFixtureNPointToNPointTool or a CogCalibrationNPointToNPointTool to reset the tool to its initial state. Instead, delete the tool from your Job altogether and add a new instance from the QuickBuild tool palette. Attempting to reset either one of these tools can generate invalid databindings, and will prevent the tool from running successfully.

If you change the name of a script terminal, you should re-link the terminal manually before running the job. Failure to do so will cause duplicate links to be present when you try to hook up the terminal, one to the "new" terminal and another link to the "old" terminal. Should the duplicate links problem occur, you can remedy it as follows:

1. Edit the script and change the the terminal back to its original name, exit the script editor.
2. The link to the old terminal will now be visible. Remove it by right clicking and selecting unlink.
3. Edit the script again and restore the new name for the terminal. Exit the script editor and your tool group should only have the new terminal and its corresponding link.

Depending on the speed of your PC CPU, you may not be able to achieve a software trigger rate in excess of 25 to 30 acquisitions per second if you select Auto-Generate Triggers.

Using QuickBuild, you cannot modify or create terminals that refer to an indexed results property, unless the tool has already been run and has produced a valid result with the desired index.

For example, the Caliper tool's default terminals include

Results.Item[0].Score

Results.Item[0].Score

Until the Caliper tool has been run, and has produced a valid result at index 0, you cannot modify or duplicate that terminal.

If you initially set the User Queue size to 1 and then subsequently change the size to a larger value, the contents of the result queue disappear.

When you import a tool group saved for the earlier COM version of VisionPro, you may get an error message that the tool group was in the wrong format.

Workaround:

Restart QuickBuild an try to load the tool group again.

Image aImg = cogDisplay1.CreateContentBitmap(CogDisplayContentBitmapConstants.Display, null, 0);
Bitmap aBM = aImg as Bitmap;
Bitmap aBM2 = aBM.Clone(new RectangleF(0, 0, aBM.Width, aBM.Height), PixelFormat.Format24bbpRgb);
using (FileStream fs = new FileStream("C:/cr37683.bmp", System.IO.FileMode.Create)) aBM2.Save(fs, ImageFormat.Bmp);

Image aImg = cogDisplay1.CreateContentBitmap(CogDisplayContentBitmapConstants.Display, null, 0);
Bitmap aBM = aImg as Bitmap;
Bitmap aBM2 = aBM.Clone(new RectangleF(0, 0, aBM.Width, aBM.Height), PixelFormat.Format24bbpRgb);
using (FileStream fs = new FileStream("C:/cr37683.bmp", System.IO.FileMode.Create)) aBM2.Save(fs, ImageFormat.Bmp);