Skip to main content

Obsolete Test POU Implementations

Important

The CBM.ETrigA and TM.Testcase_Base test POU implementations are still supported by version 5.0.0.0, but in future versions they might not be supported anymore.

If you have test cases with old implementation and want to adapt them to the new implementation, then you need to consider the following points:

. When using CBM.ETrigA
  • Use TM.Testcase (Implementing a single test POU) instead.

  • Derive a new POU from TM.Testcase and transfer the logic of the methods of the existing POU (to CBM.ETrigA). For this purpose, use the wizard to create a new TM.Testcase. Enable all options so that all possible sample content is generated (template, comments, methods, etc.). In this way, you can easily see the differences. Larger parts of your existing test implementation can remain the same if you pay attention to the following conventions of TM.Testcase as opposed to the methods of CBM.ETrigA:

    • The prvCyclicAction(), prvStart(), prvAbort(), and prvResetOutputs() methods do not have to be overloaded in the TM.Testcase scheme. As a result, they cannot simply be copied from the CBM.ETrigA-based test POU to the TM.Testcase-based POU. Instead, only the contents of these methods may be copied and customized into the equivalents of the new TM.Testcase-based test POU, as explained below:

    • Instead of the prvCyclicAction() method, Execute() is implemented:

      • The SUPER call is omitted. SUPER^.prvCyclicAction() must no longer be called and instead also not SUPER^.Execute().

      • The VAR_OUTPUT xDone output must no longer be set directly. To signal the successful end of the test, the Execute() method has to return the value TRUE.

      • Directly setting the error outputs VAR_OUTPUT xError and iErrorCode is still possible, but should be replaced by corresponding Assert Functions. We reserve the right to change the error outputs in future releases and plan to use the assert functions as a migration path.

      • The sInfo output now has the type WSTRING and must no longer be declared explicitly: The string length of sInfo is now defined by the library parameter CONSTANTS.WSTRING_LENGTH. The sInfo output may still be written directly. However, when using assert functions, it can be mutually overwritten.

    • Instead of the prvAbort() method, Abort() is implemented:

      • The SUPER call is omitted. SUPER^.prvAbort() must no longer be called and instead also not SUPER^.Abort().

      • The xAbortInProgress variable no longer exists. Instead, the Abort() method has to return TRUE when the abort has ended.

        Attention: This has the inverted semantics to xAbortInProgress.

    • Instead of the prvStart() method, Setup() is implemented:

      • The SUPER call is omitted. SUPER^.prvStart() must no longer be called and instead also not SUPER^.Setup().

      • The Setup() method still does not have to return a value (it is ignored).

    • Instead of the prvResetOutputs() method, TearDown() is implemented:

      • The SUPER call is omitted. SUPER^.prvResetOutputs() must no longer be called and instead also not SUPER^.TearDown().

      • The TearDown() method still does not have to return a value (it is ignored).

. When using TM.Testcase_Base
  • Use TM.Testcase instead.

  • The TM.Testcase_Base was popularly used in the past to be able to define an sInfo output with more than 255 characters. The TM.Testcase had only one defined sInfo output with 255 characters. Now you can set the length of the sInfo output using the library parameter CONSTANTS.WSTRING_LENGTH.

  • Derive directly from TM.Testcase instead of TM.Testcase_Base. However, you need to consider some points:

    • Remove the custom sInfo output.

    • Change the access to the sInfo of TM.Testcase to WSTRING (instead of STRING) if the custom sInfo output was a STRING.

    • Define the library parameter CONSTANTS.WSTRING_LENGTH of the Test Manager IEC Unit Test, 5.0.0.0 library (or newer) to the maximum required length.

Test POUs, which have been fully implemented without a base and therefore comply exclusively with the interface convention, could also become incompatible in the future. It is always recommended to derive from TM.Testcase.