I find that TestStand cannot handle passing long strings or arrays into a Sequence through the SequenceCall step as such:
If there are too many values in the Value expression, TestStand starts to freeze up. The same thing occurs with a String parameter. Performance seems to start to suffer around 1500 elements though I suppose that it depends on the expression string length, not the actual number of elements. My actual use case is up to 65,000 elements.
I recognize that a workaround would be to use a Global parameter and pass that through. That is not an option for me as we are creating a custom Edit dialog for certain Sequences which provides a GUI for setting the Sequence Parameter expressions.
Are there any other workarounds to this? Why is TestStand having so much trouble? We regularly have TextBoxes with a lot of text and through performance does suffer, it's not this bad.
The enclosed Sequence (TS 4.5) demonstrates this issue (16,384 elements, ~67,000 characters).
Solved! Go to Solution.
Let me see if I understand correctly.
You're hard coding ~16000 elements into an expression box and you see a massive slowdown in performance? I'm sure a developer could hop on here and explain why this happens (as I saw it when I opened your sequence) but I'm not understanding why using a variable is not an option.
Is creating a 16000 (or 2 million) element array of numbers called myArray and then passing that by reference to the sub-sequence out of the question like in this picture?
Yes, you do understand correctly.
The variable approach you suggest will not work for us. We are creating a custom edit GUI for each subsequence (customizing the SequenceCall step with an Edit substep). This GUI allows the user to edit the subsequence parameters which can in this case result in a very large array. The GUI stores the data in the Sequence parameters (SequenceCallParameters).
I suppose the GUI could save to the main sequence's Locals. However, if we have multiple calls to the subsequence (each with different parameter values) from the main sequence we might run into trouble with collisions in the shared Locals.
If you're going to create a custom edit step then why don't add a variable to the step type and save off the configuration information there?
This is a great idea. I don't have access to the custom SequenceCall's step data from within the subsequence. So I'll need the sequence's parameter to reference the step data. Aside from a bit more work this is a reasonable workaround.
Hopefully the TestStand team will look into how long sequence parameters are handled as well.