Skip to content

Changes and Fixed Issues in VisualApplets 3.0.6#



Operator TrgBoxLine (library Prototype):

  • The value range for parameter ImgTrgDelay has been extended to {0;65535} lines. (6848)
  • The operator's output port Exsync works correctly now. (6608)

Memory Operators#

Memory Operators allow Kernel Size >1

  • The operators LineMemory, LineMemoryRandomRd, FrameMemory, and FrameMemoryRandomRead (library Memory) now allow a kernel size > 1. (2369)


  • Operator PixelNeighbours1xM now supports variable line lengths also during simulation. In earlier versions, variable line lengths were only supported in hardware. (7170)

Instances of User Library Elements#

Improved Handling of Changes

Instances of user library elements that have been modified by the user are marked now with a special icon. In addition, when an update or quick update from the user library is started on such an instance, an according message occurs that informs the user that all changes that have been made to this instance will be lost if the update is carried out. This way, changed user library instances cannot be overwritten unintentionally anymore.

Parameters Library#

VisualApplets detects when due to wrong parametrization of the parameters DisplayHierarchy and Display Name a reference/translation operator module tries to add an operator parameter to a process of a design (which is not allowed). In earlier versions, this could lead to a crash of VisualApplets, or to an applet crash during runtime. Fixed. VisualApplets now informs via an error message how to parameterize the reference/translation operator correctly. (7053)

Details: If the reference/translation operator is located on the highest hierarchical level of the design (process level) and DisplayHierarchy is empty, DisplayName must be empty, too, because the process itself is not a hierarchical box and cannot get parameters. Now, VisualApplets detects such situations and throws the according error message DisplayName must be empty when DisplayHierarchy refers to process Level. In earlier versions, it was possible to define a parameter under Display Name also when Display Hierarchy pointed to the process level (i.e., when the reference/translation operator was located on the highest hierarchical level of the design and Display Hierarchy was empty. This could lead to crashes of VisualApplets, or to applet crashes during runtime. This has been fixed.

Blob Operators#

In VisualApplets version 3.0.4, Operators Blob_Analysis_1D and Blob_Analysis_2D caused a dead lock when being blocked. This has been fixed. (6702)


The timing closure of the DIV operator (library Arithmetics) has been improved. In earlier versions, under specific circumstances it happened that the DIV operator caused timing errors during build. This has been fixed.(6900)


New Error Code for Initialization File

The RamLUT operator now returns error code FG_INVALID_FILESIZE if the size of its initialization file is not correct. In earlier versions, the error code FG_ERR_RANGE_ERROR was output in such situations. The new error code FG_INVALID_FILESIZE is available in conjunction with Basler runtime software version or higher. (6422)


Operator LineMemory has been corrected. In earlier versions, under very rare circumstances there was the possibility of data corruption in operator LineMemory. This has been fixed. (6436)


Inserting nodes to operators (like BRANCH) via context menu could lead to loss of coefficients in subsequent FIRoperator modules. This has been fixed. (5450)

Mandatory Operators also in New Process 0#

Designs for ironman, marathon or LightBridge: If you delete process 0 and then create a new process 0 from scratch, the mandatory operators AppletProperties and BoardStatus are inserted automatically into the new process 0 design. (In earlier versions, after removing and then re-creating process 0, the mandatory operators were missing. Fixed.) (5720)


The ADD operator has been corrected so that now also two input ports with a bit width of signed 63 bit are allowed. (In earlier versions, the ADD operator did erroneously not allow two input ports with a bit width of signed 63 bit. Fixed.) (7138)


Operator CoefficientBuffer now allows to set parameter Ylength = 1. (1763, 3924)

Parameters Library#

Enhanced Control Mechanism

New error message "DisplayName must be empty when DisplayHierarchy refers to process level" is thrown if an operator instance of library Parameters is parameterized in a way that the referenced requested by DisplayName and DisplayHierarchy.


  • RemovePixel Operator: Simulating a design that contains an instance of the RemovePixel operator runs smoothly now. In earlier versions, when a design was simulated that included an instance of the RemovePixel operator, occasionally an error occurred: Removing the last pixel of an image could result in an internal error that immediately stopped the simulation and returned a message about corrupted simulation data. This has been fixed. (6103)
  • Simulation control: Improved simulation control for situations where a single image causes generation of multiple images within an image processing pipeline. (6314)
  • Pixel Data with 64 bit resolution: The calculation of simulation results for situations where pixel data with 64 bit resolution is involved works correctly now. In earlier versions, the results of such calculations were wrong. This has been fixed. (6878)
  • Operator RamLUT now supports variable line length also when a design is simulated. The image doesn't need to be rectangular for simulation anymore, but can also contain empty lines and/or lines of varying length (e.g., a triangular image). (6997)

Deleting Referenced Operators of Library Parameters#

Operator instances from library parameters can be deleted now from a design also if their parameters are still referenced by other modules. (In earlier versions, a crash of VisualApplets could happen in situations where the parameters of the deleted module were referenced by parameters of other modules (including parameter references due to property 'DisplayName'). Fixed.) (6423)

Overall Resource Estimation Improved#

The overall resource estimation (displayed under Netlist Generation in the DRC Log after Design Rules Check 2, and in dialog Build Hardware Applet after starting the Build process) now also takes the RAM LUT resources into account. Therefore, a higher amount of resources is calculated than in prior VisualApplets versions where the RAM LUTs where ignored in the overall resource estimation. Now, the overall resource estimation under Netlist Generation is consistent with the information of the FPGA Resource Usage dialog. (6487)

Generating GenICam XML code for eVA Platforms#

Fixed crash of VisualApplets when generating GenICam XML code (applies only to embedded VisualApplets targets) for a design which contains ColorTransform operator with dynamical coefficients. (6625)

Operator Reference (Documentation)#

Links to Examples of Use

Operator reference documentation: Links included in section Examples of Use now link directly to the according examples as intended. (7086)

Loading and Unloading Applets in a Loop#

Loading and unloading applets (built with VisualApplets 3.0.6 or higher) in a loop doesn't lead to memory leaks anymore. When applets built with earlier versions were loaded and unloaded in a loop, memory leaks could be observed. This has been fixed. (6925)

ROI Fix CXP Camera Operators (marathon and ironman)#

Now the ROI settings work correctly with all CXP camera models. In earlier versions, some settings for the ROI frame height lead with some specific CXP cameras to incorrect image acquisition. This has been fixed. (6461)

PoCL Support Improved#

The PoCL support that is automatically implemented in Camera Link Applets for marathon and LightBridge frame grabbers has been improved:

  • The PoCL detect mechanism has been further enhanced.
  • The support of PoCL cameras that are changing their clock frequency has been improved: Instable clock signals sent by the camera (during reconfiguration of clock frequency in the camera) are tolerated by the applets for a longer period of time.

Improved Stability After Invalid Pixel Signals from Camera

When the frame grabber received invalid pixels from the camera before the acquisition was started, the first valid line/frame sent by the camera after start of acquisition was discarded (due to a filter system implemented to discard invalid signals) even if the acquisition was started via trigger. Fixed. The filter system has been improved so that now after start of acquisition via trigger the first line/frame sent by the camera is processed also in cases when invalid pixels have been sent by the camera before start of acquisition. The fix has been implemented into all mE5 marathon, mE 5 ironman, and LightBridge Camera Link frame grabbers, and into microEnable IV AD4 CL/PoCL and microEnable IV VD4 CL/PoCL.

Back to top