Support

How can I reach the ETM/WinCC OA Support?

You can easily submit your inquiries online via support request around the clock, i.e. 24 hours a day, 365 days a year.

For details please see the WinCC OA Portal: https://www.winccoa.com/support.html

After a service request is made, communication for that service request is done via email. You will receive an email from ETM Support when ETM is working on your service request. This email can be replied to if you would like to send us additional information.

When you first contact us, it may take some time to enter your master data. Please accept our apologies for this.

A member of the ETM support team will call you back.

You can view the status of your service requests in the online portal. It is also possible to edit your service requests.

Which information is necessary to report a defect to the WinCC OA support?

Defects must be reported and transmitted to ETM in a reproducible condition. Bug reports must contain a brief summary, a detailed description of the bug situation, the expected behavior and actual behavior, the environmental conditions under which the bug can be reproduced, and an isolated project example where the bug can be reproduced using standard WinCC OA Installations. A custom testing environment is not available at ETM.

The quality of a bug report can dramatically impact the likelihood that the bug will be fixed. This requires that a number of ETM specialists (e.g. developers, code reviewers, QA and release managers) are able to quickly understand and review the issue by reading the report and possibly run a code example.

The following text describes how to report bugs and provides tips for producing high-quality reports. (Source: http://wiki.qt.io/ReportingBugsInQt )

Defect Report Content:

Summary

  • Enter a short but descriptive text that explains the error in one sentence.
  • T This should give a general overview of the occurrence of the bug without going into too much detail. It's important to think about what other people might be looking for.
  • Bad example: "Text field always goes wrong".
  • Too long: "My user interface crashes when I use a text field and fill it with the description text of my DPEs using a CTRL script in a for loop. This happens when I save the field in XML format and set the language of my operating system to Arabic, which also activates the right-to-left mode. If I then try to enter something, it crashes. A long text like this should be included in the description instead; the summary should be kept short..
  • A good example: "UI crashes on text fields when using an input method in right-to-left mode."
  • If you are sure that the error only affects one platform, put the platform and a colon in front: "WIN7: UI crashes on text fields when using a right-to-left input method."
  • If the error is a regression, i.e. it worked in an earlier version of WinCC OA, indicate this as follows:state this as follows: "[REG 3.12->3.14] WIN7: UI crashes on text fields when a right-to-left input method is used."

Affected Version

  • Define the WinCC OA version and the patch level at which you can reproduce the error. If this is not the current patch level of your installation, please also check the current patch level to see if the error has been fixed in the meantime.

Components

  • Determine the component that best matches the location of the error.

Description

  • A longer text that describes, step by step, the minimum measures required to reproduce the error.
  • This is a good form:
    • What did you do step by step? Ideally, this should be in the form of short bullet points. However, try to be as specific as possible when describing something like a touch gesture.
    • What did you expect to happen?
    • What happened instead?
  • If the defect leads to a crash, a vital piece of information in crash reports is a core dump. Retrieving a core dump is platform specific. If successfully created a core dump, submit it together with the crash report.
  • Finally, please supply any more details that you may have. For instance "This defect only occurs if I use Aero in Windows 7, it does not happen when I have opened the UI with Windows classic theme", or "This is a regression from WinCC OA 3.11.1".
  • Example:
    • Open attached example myPanel.xml
    • Click on the button „First“
    • In the shown menu choose item "Red"
    • Note: Wait a few seconds
    • EXPECTED: the panel background will now be red
    • ACTUAL: the panel background stays gray

Environment

  • A detailed description of your operating system, network, settings, and any other pertinent information is requested to help reproduce the defect.

Attachments

  • A simple example that reproduces the defect is always welcome.
  • If log files are attached, please describe them. Important information is for example: when did something happen, how is the topology of devices/machines/components and what are their names

In short

Always provide as much information as possible together with your defect report. The more the better. Also, please specify if a defect is a regression or not. If it is, then specify what version it worked in last to your knowledge. Finally, supplying a small test panel is a sure-fire way to solve a defect faster.

By creating a high quality defect report, you will gain priority over those less descriptive, and your chances of a speedy resolution increased.

Some defects may be hard to reproduce, for example, it may happen only occasionally, it cannot be reproduced in a small example, or it only happens in a specific environment. However, for the support to be able to help you, it is still important that the defects are analyzed in enough detail so that a developer is able to see the problem for himself. At this point, it is important not to lose hope. These defects are tricky, and solving them typically requires a lot of back and forth communication, since the defects can only be reproduced on the reporter's system.