Editor X hanging at end of test

Technical
1

I am having a problem where Editor X runs through my test plan to completion, but at the end of the test it never displays a pass/fail status and behaves as though the test plan was not completed.

Pressing the ‘Abort’ button at this point has no affect.

I didn’t see this problem until I updated to the EditorX Version: 1.6.0-rc.2+0972d0f5 while investigating long load time for large test plans.
I reverted back to Version 1.5.0, but the problem now remains so I’m not sure if the update is related or not.

I see the following logged warnings:
16:57:34.371 Resources Estimated processing time for result queue reached 3.1s (Limit is set to 3s in Engine.xml). Waiting for queue to be processed by NatsResultListener…
16:57:38.235 Resources Estimated processing time for result queue reached 5.8s (Limit is set to 3s in Engine.xml). Waiting for queue to be processed by StatusListener…
16:57:42.584 Resources Estimated processing time for result queue reached 5.7s (Limit is set to 3s in Engine.xml). Waiting for queue to be processed by StatusListener…
16:57:55.731 Resources Estimated processing time for result queue reached 6.0s (Limit is set to 3s in Engine.xml). Waiting for queue to be processed by StatusListener…
16:58:00.357 Resources Estimated processing time for result queue reached 7.5s (Limit is set to 3s in Engine.xml). Waiting for queue to be processed by StatusListener…
16:58:44.941 PathWave Test Automation TIMEOUT
16:58:44.958 PathWave Test Automation TIMEOUT

I have a number of Test Steps that perform a ~1sec acquisition followed by a number of Test Steps that perform signal processing on the acquired data and report their results to a listener. The signal processing steps perform their task quickly, so I’m wondering if the problem is related to how quickly the results are published.

I run the same test plan using TUI and don’t encounter any of the same problem. Unfortunately, I can’t currently run this same test plan on Windows using Editor as some of my plugins are linux specific.

Would appreciate knowing if others have ever run into something similar.

Thanks

2

Hi @wittrock,

If you downgraded the EditorX version, some of the other packages which EditorX depended on might still be left in their upgraded versions, since they are compatible they don’t necessarily get downgraded.

Can you give me the list of installed packages? You can get it by calling tap package list --installed.

Also, you will get these messages because the test plan is executed way faster than the result listeners can process the events. In this case, the UI has installed some result listeners which it uses for updating the UI. How many test steps are you executing and what is the average duration of each?

3

Hello Rolf,

Unfortunately, I didn’t have time to troubleshoot more at the moment, so I did a complete removal/install to put me back at my previous setup which is OpenTAP 9.21.0 and EditorX 1.5.0.

After I did this the problem went away.
I’ll get back to trying again but needed to finish up existing work first.

In the mean time, the tests that were giving the warning messages pretty much all follow the same pattern.

  1. Perform a single burst acquisition of 24K samples on 8 channels.
  2. Perform a DFT, RMS, AVG, etc on each of those channels and report a measured, high limit, low limit, status.

Step (2) does not have any blocking. Its time is limited just by cpu processing of the acquired data, so their are eight results that will follow almost immediately after each other. On my system the time reported for each signal processing step is ~500us to 2ms. So I could have a burst of 8 reports occur very quickly spaced by ~1second between bursts and this is repeated ~50 times.

I could try inserting a yield or delay within my signal processing step but not sure if there is better way to determine or wait for the result queue to catch up.

Thanks,
Jeff

4

Hi @wittrock,

Thanks for the info.

I am fairly sure this issue occured because there are some more updates in the newest EditorX version and that is probably the cause of the warnings you were seeing,

For context, how many values are you publishing for each of the 8 reports?

In any case, we are trying to reproduce what you found. I’ll keep you posted when we find a solution.

5

Thanks Rolf,

Each report I publish contains 5 string columns but just a single row. I’m using strings for report items just because I need unique control of formatting the measured values.

So I end up reporting ~400 rows x 5 string values each

Repeat ~50 times
    blocking data acquisition for ~1sec.
    for each channel (x8)
            signal process above acquired data and report 5 strings (500us-2ms)

Thanks,

1 Like
6

Some additional information.

I was listing the results that my own plugins are publishing, but In addition to my own data acquisition plugins, I am using the ‘B296x Low Noise Power Source(1.0v1)’ plugin and it looks like it is publishing results for every query I make.

I am using my own report listener that is filtering out everything not generated by my own plugins, so I don’t see all these reports, but I imagine result listeners for the GUI do.

In particular, I am sourcing V and measuring V/I arrays using this plugin. It looks like it is publishing the arrays when they are queried. These arrays are large (~10k samples each).
I don’t see an obvious way to control what is published from this plugin unless I modify the source and build locally so I can’t verify right now, but I suspect the large results being published by the SMU plugin are likely exasperating the problem.

Thanks,