- Posted on: 2020-03-02
This series of blog post is intended to Symplify™ users who want to take advantage of all the features of the platforms. We will post new tips and tricks about how our own developers use Symplify™ to meet our clients’ requirements.
Most tests on embedded device are usually broken up into a series of steps that validate different aspects of the device, both hardware and software. As the unit evolve, it is very common for our clients to run into a situation where the device does not respond within an expected time frame. Those common failures are very helpful in identifying weak aspects of the unit’s logic and or electronics but they often need to be repeated multiple times in order for the developers to gather enough information to quickly understand and address the problem.
The challenge is to implement a flexible way in the test plan to test for different conditions including a timeout that would let us take proper actions if the device under test (DUT) becomes unresponsive.
The Solution in this case is to use built-in features directly in the script engine to offer a maximum of flexibility in detecting the Timeout and reacting to it. The platform continuously updates the system Tag _SYS_Relative_Current_Time_ with the number of seconds since the application started. By doing very simple operations and defining a timeout value (in seconds) as one of the variables, you can quickly add a timeout condition as a reason to exit the While loop, along with the other normal expected conditions.
The image below demonstrates what our code normally looks like. As you can see, we typically assign standard names to those variables and also implement a method to interrupt a test entirely with the Tag Abort_Test_Set.
This code can be found in the example project that ships with Symplify™, under the script sub-folder! Another thing worth mentioning here is the use of the “SysLog()” command to send extra information that the user can use to understand the test flow and the reason for the failure easily.