NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Random 17502 Error throughout sequence.

I keep getting what appear to be totally random and intermittent 17502 Errors when running my sequence file.  When the error occurs, I simply hit retry and the step executes without issue.  I've been trying to debug this issue for weeks and have had absolutely no luck.  Here's situation:

 

I've running a sequence file in TestStand 2014.  Test sequence contains approx 100 different calls to a specific Labview(also 2014) MODBUS Read VI.  VI Details are as follows:   We use a .xml "configuration cluster" to pass MODBUS Register address and scaling factors to the VI.  VI uses config data from the cluster to perform MODBUS Reads and return scaled data.  VI is built on NI MODBUS Drivers.  We've been using these drivers for years without issue.

 

Debugging has been extremely frustrating:  The 17502 error does not occur when executing the VI within LabVIEW so I can't probe wires or look for .  Only occurs when calling VI from TestStand.  Also appears to be completely random. Sequence file can execute any number of times without issue...then we see the error.  Does not occur on specific sequence step so setting a breakpoint in the sequence is useless.  If a step fails during a particular execution, I "retry" the step, it passes, and sequence continues without issue.  Next several sequence executions will be fine.  Then, a different step returns the 17502 error.

 

At this point, I'm stuck.  Any suggestions?

 

Thanks

0 Kudos
Message 1 of 5
(3,150 Views)

Do you get the same issue if you wind the TestStand Tracing Speed down a bit (towards Slow) to get a bit more time between calls to your MODBUS read? 

 

TestStand Tracing.PNG

0 Kudos
Message 2 of 5
(3,112 Views)

Thanks for the suggestion.   I've been running at 50% Tracing Speed for the last several hours and...NO ERRORS!    Of course this effectively doubles the test duration, but it's a start.    Thank you very much for your help.  Much appreciated.

0 Kudos
Message 3 of 5
(3,099 Views)

Awesome.  Your description sounded like the issue is marginal timing related.  If I were a betting man I would put some money on your issue being around the release of resources that the driver is supposed to release before the MODBUS Read returns but doesn't (it returns as they are being released)...most of the time the time TestStand takes to move onto the next step is enough for the resource to be released before they are needed again by the next call, but on occasion they haven't quite finished releasing and you get the error.

 

Your description suggests the error is quite intermittent so 50% trace reduction is probably overkill.  Did you try any other values?  My gut feel is that you just need to give things a tiny bit more time to close properly so any additional delay, of any value, will probably do it (a bit of delay trial an error should hit the sweet spot), either through tracing speed, a delay at the end of the Read VI or in a Post Step.

 

Please let me know how it goes. I might find myself debugging MODBUS Read errors in the future.

 

Steve 

0 Kudos
Message 4 of 5
(3,094 Views)

After a few days of testing, reducing the trace speed does indeed appear to resolve the problem.  I've worked my way back up to approx 90% speed and all seems well.  No errors after 2 days of looping the sequence.   

0 Kudos
Message 5 of 5
(3,055 Views)