Generate an error based solely on the error code

[matt_butts]

I have a large library of VI's that are wrapped in TestStand sequences. All of these VI's simply return an integer status code. I have started defining these status codes as real errors in a user defined error file at C:\Program Files\National Instruments\Shared\Errors\English\. I want to be able to use the same error definitions in TestStand.

Here is the issue. I have enough VI's that it is not feasible to go back through all of them and output the full error cluster (which should have been done when they were created). I set the status returned from the VI to Step.Result.Error.Code. I then added a post expression that sets the error occurred flag:

Step.Result.Error.Occurred=Step.Result.Error.Code!=0 (I know this messes up warnings, but it's better than nothing)

The problem I have now, is that I get the TestStand error window, but it doesn't pull the error description from the user defined file. It just gives me the code and "User defined error".

How can I get TestStand to read my file and return the appropriate description?

Thanks.

[~jiggawax~]

A couple questions:

Why would you automatically assume that TestStand knows to go and poll that file for the msg?  What parts of the Error cluster are you sending back?  Just the Occurred part?  Or just the Code?  Or Both?  Or the Msg?  Essentially what I'm wondering is what you are sending back from the VI that TestStand can know there is an error?

So in TestStand you have 3 parts to the error cluster: Code, Msg, Occurred.  I think you are correct in setting the Occured part of it to whatever is coming back from your VI.  So you may have to do it in the post expression like that.  However, what are you setting the Msg portion of the error cluster to for each step?  If you don't set that then you won't see it in the description.

What you can do is use the SequenceFilePostStepRuntimeError callback and  have some logic in there to read your txt file and parse it for the right Msg.  This will then set the description correctly.

[matt_butts]

Here is how I am setting the 3 parts of the Step.Result.Error cluster:

• Code: directly fed from the VI output (this is the only piece the VI returns)
• Occurred: Using a post expression to set this, True if the code is not 0, False if it is 0
• Msg: Not currently doing anything with this

So I am fulfilling TestStand's needs to figure out that there is an error, and I can confirm this because I get the error message. It just doesn't have my description. I would gladly add something to the post steps to fulfill the message piece, but I am not going to manually parse a file that is already in an NI format that should be understood by TestStand.

I was hoping TestStand had something like LabView where you can feed it just a code, and it will return the complete error structure. I was hoping that once I had signaled to TestStand that an error had occurred and provided the code, it would use it's resources (the error definition files in Shared/Errors) to get all of the information.

Any ways you know to do this? Or other ideas on populating the message?

[~jiggawax~]

Yeah I've never heard of TestStand using those for it's errors.  Unless I'm wrong then that's not possible.  If I am then can someone please enlighten me?  My guess is that because, as you admitted earlier, the proper way to call code modules is to pass the entirety of the error cluster and let the code module figure out the descriptions.

I think your best bet is to continue with setting the Occurred like that.  Then plop down a SequenceFilePostStepRuntimeError and put a VI in there that takes in your Code and parses that error file and returns the Msg.  Then set the Msg for that error.  I can't remember if it's a VI call in LabVIEW that figures out those codes?  If so then you can just call that VI directly from that callback.

[AllenP]

TestStand uses error codes to mean a class of something wrong.  The message could be very different based on the situation.  The code would describe a type of problem (File not found, etc...).

LabVIEW does things a bit differently, where each error code represents a unique error message.  TestStand does not have knowledge about the mapping of LabVIEW error codes to messages.  You'll have to extract this information on your own if you want it to go back to TestStand.