My VI do not work when called from teststand

[robojeff]

I have a Labview 2014 VI that parses TCP data and it works as a stand alone VI but when I call if from test stand sequence file , this VI times out and does not parse the TCP data.

What sort of things should I be looking for in order to find the root cause of this problem?

I have been skipping oher steps in my sequence file but I am not able to find the source of the problem...

Thanks

[robojeff]

Another thing that is goofy about this is that if I set a "run mode of skip" for a few steps in my sequence the VIs will work but it doesn't seem to be the same sequence steps every time so I am having a difficult time tracking this one down... Could it be a memory or update issue?

[robojeff]

I forgot to mention that the VIs are written in Labview 2014 and I am using Teststand 2014.

Is there some special set up that I am missing for using these two together that might affect these VIs from running in Teststand

while they seem to work as stand alone.

Also, I just tried only selecting the sequence steps containing these VIs and selected run selected steps using single pass and they worked.

Something is missing or messed up here...

[robojeff]

I just updated my teststand 2014 with teststand 2014 SP1  f1 patch and it still is not working.

These two VIs worked before when called bt teststand and now they do not.

Not sure what changed or how to fix this problem.

Has anyone out there seen this problem?

ANYONE?

[pulidotech]

It would be helpful if you posted at least some snippets of your code, both from LabVIEW and TestStand.  If all your code is doing is parsing data from TCP (or from anywhere), there's no reason it shouldn't work in TestStand, assuming you're passing data correctly into the VI.  

Pulido Technologies LLC

[RaviShrigiri]

Hi,

Probably it seems to be a timing issue.Since it works with few steps skipped or run.

Assuming the read step is timing out before data has come :

You can try looping your read step so that even if it fails once (does not read) it will do it the next time. ( you have an option of looping each step).

Assuming read step is executed after data came :

Junk data which is masking\erasing the original data? 

Any flush operation happened in between which erased the data.

Is there any way you can track the command/data sent on TCP and match it with the steps\vi executed ?That should give you a better idea of whats happening.

Hope this helps.

Ravi

[robojeff · Accepted solution]

I found that other programs used within the sequence file in steps previous to

running my VIs were causing them to time out and the only work around was to cycle power to the

unit that I am testing before running my VI steps in the sequence.

The peculiar thing is that I didn't need to do this a week ago...

Thanks for all you help with this...