Starting with Version 9.9, VisionPro adds advanced tools that are based on a new Cognex software architecture that introduces .NET assemblies that use the Cognex.Vision namespace. In addition, VisionPro 9.x continues to use traditional assemblies with the Cognex.VisionPro namespace. For ease of reference, software objects that live in the Cognex.Vision namespace will be referred to as Vision Interop objects, or VI objects.

• Starting with VisionPro 9.9, VisionPro 9.x targets .NET Framework 4.8.
• If your application uses CogToolBlock or CogToolGroup, you have new run time dependencies. This is because the data binding mechanism used to link tool terminals has been enhanced to support VI data types. See the section below on Applications that Use VI Objects for specific steps that you must take.

VisionPro now incorporates advanced Edge Learning tools from the VI architecture by wrapping them with a traditional VisionPro tool layer. For example, the new CogClassifyTool and CogSegmentTool are front-ends for the VI tools named Cognex.Vision.ViDiEL.ClassifyTool and Cognex.Vision.ViDiEL.SegmentTool. The CogClassifyTool and CogSegmentTool behave like traditional VisionPro tools, but are powered by the corresponding VI tool. They can be used in QuickBuild, inside a tool block or tool group, just like any other VisionPro tool. The VisionPro tool forwards its input image to the VI tool and (sometimes) returns results after the VI tool is run, as shown in the following simplified block diagram. The VI results will not be copied back to the VisionPro tool if they consist of standard .NET types (like, Integer, String, Double, etc.), but they will be copied back if they represent a Cognex.VisionPro type (e.g. a CogImage8Grey).

You will typically create a new-style VisionPro tool using QuickBuild, and configure that tool using its GUI edit control. The tool will be run as part of the tool block that contains it. You can, however, access the VI objects directly from C# code. This will be discussed in greater detail below.

You can access VI objects programmatically using C# and Visual Studio or through C# and VisionPro scripting.

In either environment you will need to reference the appropriate assemblies. To work with the VI component wrapped by a VisionPro ViDiEL tool, you will need to reference:

• The following steps are needed to resolve dll dependencies that are not in the GAC. The steps will (a) create a symbolic link to the location of the dll dependencies, and (b) update the app.config file to use this location. Note that the mklink command requires Admin rights, thus you will need to launch Visual Studio as an Administrator.

  1. Add the following postBuildEvent step to the applications Visual Studio project file:

     View ColorizedCopy to ClipboardPrint

     cd $(TargetDir)
     if exist VisionProDependencies\ (rmdir VisionProDependencies)
     mklink /D VisionProDependencies "$(VPRO_ROOT)\bin"

     cd $(TargetDir)
     if exist VisionProDependencies\ (rmdir VisionProDependencies)
     mklink /D VisionProDependencies "$(VPRO_ROOT)\bin"

  2. Add the following to the application's App.config file:

     View ColorizedCopy to ClipboardPrint

     <configuration>
       <runtime>
         <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
           <probing privatePath="VisionProDependencies"/>
         </assemblyBinding>
       </runtime>
     </configuration>
     </code>

     <configuration>
       <runtime>
         <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
           <probing privatePath="VisionProDependencies"/>
         </assemblyBinding>
       </runtime>
     </configuration>
     </code>

• If you are using any VI tool you need to call the Initialize and Shutdown methods as described below:

  • At the start of your application call the VI function Cognex.Vision.Startup.Initialize(Cognex.Vision.Startup.VProX).
  • At the end of your application call the VI function Cognex.Vision.Startup.Shutdown().
  • Note that even if Initialize is called again after Shutdown has been called, tools will no longer work properly. Thus make sure Shutdown is only ever called at the end of the application.
• When working with VI tools in a .NET application you should work with those tools in the Cognex.Vision namespace. This will give direct access to the VI tool without using the Cognex.VisionPro wrapper class which is designed primarily for QuickBuild integration.

• When writing script you can access VI properties directly. For example, you can set the "Enabled" property of the VI ClassifyTool using C# script code like this:

  View ColorizedCopy to ClipboardPrint

  ((CogClassifyTool)toolGroup.Tools["CogClassifyTool1"]).VisionInteropTool.Enabled = true;

  ((CogClassifyTool)toolGroup.Tools["CogClassifyTool1"]).VisionInteropTool.Enabled = true;

• There is no need to call either Cognex.Vision.Startup.Initialize(Cognex.Vision.Startup.VProX) or Cognex.Vision.Startup.Shutdown() in your VisionPro script code. This is done automatically within QuickBuild.

To make programmatic use of VI classes with VisionPro easier, a set of conversion functions is provided. In the new Cognex.VisionPro.VisionInterop assembly is a new class named CogCoreConverters. This class provides numerous static methods for converting between VI classes and their VisionPro counterparts. See, for example:

• Image8Grey CogCoreConverters.MakeImage8Grey(CogImage8Grey image) // convert from VisionPro to VI
• CogImage8Grey CogCoreConverters.MakeCogImage8Grey(Image8Grey image) // convert from VI to VisionPro

VisionPro generally provides a WinForms edit control for each of its tools, and users are free to reuse those controls. The VI-based tools work differently. Their edit controls are WPF-based rather than WinForms-based. There are no edit controls for the VisionPro wrapper tools.

You can incorporate these WPF controls in your WinForms application with the help of Microsoft's System.Windows.Forms.Integration.ElementHost class in assembly WindowsFormsIntegration.dll. See the Microsoft documentation for details on this class.

An important characteristic of the VI WPF controls is that they act upon the VI-based tool rather than upon the containing VIsionPro tool. In particular, these controls have several built-in buttons that will interact with the VI-based tool in ways that may not be desired for your VisionPro application:

• The Run button calls the Run method on the VI-based tool, not on the containing VisionPro tool.
• The Reset button will replace the current VI-based tool with a default constructed instance. It will not replace the current containing VisionPro tool with a default constructed instance.
• The Open button will expect to load a VI-based tool from a .VPP file. It will not successfully load a VisionPro tool from a .VPP file.
• The Save and SaveAs buttons will write out VI-based .VPP files, not VisionPro .VPP files.

To change the existing behavior you can provide user-defined delegates (functions) to the VI WPF control. There are 7 delegate properties on the VI WPF edit control's ViewModel:

• RunDelegate
• ResetDelegate
• OpenDelegate
• SaveDelegate
• SaveAsDelegate
• SaveMinimumToolDelegate
• SaveMinimumToolAsDelegate

See the installed sample application %VPRO_ROOT%\samples\Programming\ViDiEL\Classify\C# for exmaples of this technique.

Because of the new run time dependencies for VI-based classes (e.g. CogClassifyTool or CogSegmentTool) or classes that potentially could load/use VI-based classes (e.g. CogToolBlock, CogToolGroup) you will at a minimum need the DLL dependency steps listed in the topic Using VisionPro with Microsoft Visual Studio. This requires:

• An edit to the application's app.config file,
• A new postBuildEvent command, and
• Calls to the Initialize and Shutdown methods.

See the topic Deploying Your VisionPro Application for details on deploying your finished vision application to other systems.

Note that an <applicationName>.exe.config file will be generated by Visual Studio and this needs to be deployed along with your built executable. This tells the application where to look for the non GAC'd DLL dependencies, but it also needs the symlink to exist. A batch file called VisionProDependencyHelper.bat can be found in the VisionPro bin folder to create the links for you. The bat file needs to be executed in the folder where your application executable resides and needs to be run as Administrator due to the mklink command.

ViDiEL wrapper classes (i.e. Cognex.VisionPro.ViDiEL.CogClassifyTool) are not guaranteed to reflect every change to an attached VI tool (i.e. CogClassifyTool or CogSegmentTool). This is another reason to use the VItool directly where possible in .NET applications.