NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Sequence Limits Editor Crash

While editing Multiple Numeric Limits, if I try to move the last entry in the Measurement Set window up, the editor crashes and takes the Sequence Editor with it. Has anyone else seen this behavior and is there a fix for it? I am running TestStand 4.0. Is this fixed in 4.1?

 

Thanks,

Bob

0 Kudos
Message 1 of 8
(4,314 Views)

Hi Bob,

 

I have not encountered such a problem in TestStand 4.x.

Are you using TestStand 4.0, 4.0.1 or 4.0.1f1?

 

- What Adapter/Code Module are you using?

- Could you please describe the exact steps you take to replicate this problem in TestStand 4.0.

 

Thanks

Message Edited by Nestor_G on 09-17-2008 03:55 PM
Nestor
0 Kudos
Message 2 of 8
(4,297 Views)

Hi Bob,

 

Do you continue to experience the described problem in TestStand 4.0 or TestStand 4.1?

If so, would you please reply with answers to the following questions:

 

- What Adapter/Code Module are you using?

- Could you please describe the exact steps you take to replicate this problem in TestStand 4.0.

 

Thanks

Nestor
0 Kudos
Message 3 of 8
(4,228 Views)

Sorry for the delayed response. Too many pesky project deadlines!

 

I use LabVIEW exclusively for our code. This problem occurs when I use a custom step type based on the NI_MultipleNumericLimitTest. We call the custom step type  AG_MultipleNumericLimitTest. Note that it was created in TS3.5 and uses the old limits editing window (see second attachment). I'm sure TS3.5 also crashed when the last test limit was moved up. Unfortunately I don't have access to TS3.5 to verify this.

 

Hopefully the two attachments will help clarify what causes the crash.

The first attachment (TestStand Move Up Crash.JPG) is the action that causes TestStand to crash. If "MoveUp" is selected, TestStand crashed.

The second attachment (TestStand AG-NI_MultipleNumericLimitTest.JPG) shows the contents of NI_MultipleNumericLimitTest and AG_MultipleNumericLimitTest.

 

Thanks,

Bob

0 Kudos
Message 4 of 8
(4,199 Views)

Hi Bob,

 

Thanks for the follow-up.
I was able to replicate the problem against TestStand 4.1.

 

The problem only occurs with a TestStand 3.5 custom step types merged with a Multiple Numeric Limit Test step. The problem is due to the merged Substeps from TestStand 3.5 running in TestStand 4.1. To resolve the issue, you will need to change the Substeps in the custom step to use the new TestStand 4.1 Substeps.


Please follow the instructions below to solve the issue:

  1. Open the TestStand 4.1 and navigate to the Types view (Crtl-T)
  2. Locate the TestStand 3.5 custom step merged with Multiple Numeric Limit Test
  3. Right-click on the custom step and select Properties. The Step Properties window will appear.
  4. In the custom step Properties window, select the Substeps tab.

 

Changing Post Substep

  1. In the Substeps tab, select on the Post substep and click on the Specify Module button
  2. In the Fuction Name dropdown, select "DoMultiNumericMeasEvaluationUsingExpr" - as shown in the picture below.
  3. Select OK

 

Changing Edit Substep

  1. In the Substeps tab, select the Edit substep and click on the Specify Module button
  2. In the Function Name dropdown, select EditMultiNumericMeasurementStepUsingExpr
  3. Select OK

 

Select OK in the custom step Properties window.

 

Nestor
0 Kudos
Message 5 of 8
(4,151 Views)

Nestor,

Thanks for the information. When I select "DoMultiNumericMeasEvaluationUsingExpr" I get the error shown in the attached screen shot. Any suggestions?

 

I am using TS rev 4.0.0.326.

 

Bob

 

 

0 Kudos
Message 6 of 8
(4,135 Views)
That dialog is not reporting an error. It is informing you that the CommonSubsteps DLL does not have type information for the selected function. The prototype for the new function is the same as the old one, so you can just click OK and close the dialog and everything should work.
0 Kudos
Message 7 of 8
(4,101 Views)

Hi Bob,

 

I reported this issue to R&D (#129258) for further investigation.

Please use the suggested workaround instructed above Bob.

 

Thanks for your feedback, and do pardon any inconveniences.

Nestor
0 Kudos
Message 8 of 8
(4,075 Views)