Any error reports to CODESYS should contain the following information: 

  • The versions used within the Project,
  • A clear error description of what exactly occurs and when,
  • The exact 'Steps to repeat' (STR) to reproduce the error,
  • If possible, a simplified/reduced example project (as a full project archive) with the necessary scope/extent to be able to reproduce the error in it.

Besides the above information, the principle of "more is better" applies here.
In order to be able to answer inquiries efficiently, it is useful to provide all relevant data

-> see also which additional data is helpful and why:

- The more detailed information the support team receives, the faster the problem can be isolated, and a resolution provided.

Whom to contact for vendor-specific errors?

  • The errors must be reproducible under the Codesys IDE and with a CODESYS SL PLC.
    - For errors that occur only under other IDEs, which were modified via brand labelling, the corresponding manufacturer must be contacted.
    - For errors that occur only with a device manufacturer's PLC, the device manufacturer should be contacted to pursue a resolution for the problem.

    - This is due to the fact that other IDE manufacturers use Codesys as a platform, but can build their own restrictions or extensions that deviate
       from the default interaction, behavior and standards of the Codesys IDE, and therefore can not be pursued by us. 

  • Errors that occur with a library, not developed by CODESYS GmbH
    - For errors that occur with a library which was written by a 'third party', this 'third party' should be contacted for support.

Check the FAQ's and the FORGE page before reporting bugs.

Please check if the occurring errors have already been covered in the FAQs
or if they have already been recorded and answered under our Forge community.


Which additional data is helpful and why? 

1. All used version information 

To be able to detect problems which may only be related with the used version(s), or to be able to exclude known issues,
the following version information should be provided:

  • Version of the CODESYS programming environment (IDE).
  • Version of the operating system, the used runtime and processor of the target system.
  • Version of the used CODESYS Packages (like SoftMotion, Ethernet, Visualization, etc.).
  • Version of the used Visualization Profile for visualization problems within the Visualization Editor and Visu Display Variants.

2. How to reproduce the problem

We always need accurate information and data to recreate the error profile:

  • Exact 'Steps to repeat' to be able to reproduce the error.
    The more precisely the individual steps are described, the less need there is to ask for error reproductions and the less room there is for interpretation when retesting.
  • A full project archive (not only the CODESYS project!).
    This contains the libraries used, the application structure of used functions, etc.
  • For more complex processes, in addition to the written steps, a short screen recorded video, showing the steps and then the error that occurs, can be very useful.
  • Note that sporadic errors are very difficult to solve.
    In these cases, you should endeavor to determine the conditions under which it occurs, so that the support team has a chance to reproduce it and investigate.

3. Additional related specifics

Depending on the existing problem, different additions to be reported are necessary (or at least helpful in order to correctly understand and comprehend error profiles):

  • If available, controller logs, with the appropriate log filter settings, should always be given.
  • Screenshots of the error when it occurs in the Codesys IDE.
  • In case of fieldbus related errors (or incorrectly displayed values in the different editors of the fieldbus), recording of the communication via 'Wireshark',
    that ranges from the download/login/start of the controller to after the occurrence of the error behavior, are needed. 

For reporting a runtime exception 

By any exception in the runtime, first check if it is caused by an applicative structure in a POU, FB or library.
To do this, use the Implicit Checks available in the Codesys IDE.  

See also our OLH on how to 'Create a Core Dump', and how to 'Creating core dump of the running application manually'.

For any exception in the runtime, we need:

  • a complete repository/project archive
  • the Coredump, in which these exceptions have been marked

Then send the full project archive, with the associated Callstack and a Core Dump, created at the time of the crash:

  • When an Exception error occurs from one of the CODESYS visualization elements, please set the compiler-define:


    and send a full project archive, with the associated Callstack and a Core Dump, created at the time of the crash:

    More detailed information can be found under Debugging a Visu Exception.

If you need technical support, please purchase a Support Ticket in the CODESYS Store.
Note that certain products in the CODESYS Store already include a Support Ticket.

To report 
software bugs or if you have a question concerning the products in the CODESYS Store,
click on the "
My Question" button next to the shopping cart in the CODESYS Store.

See also....