Sequence Callbacks Ordering

[bsvare]

I understand well enough how callbacks work, but I think I'm missing an important part on the order they are called and the decision behind the design.

One I'm specifically looking at right now is the ordering of SequenceFilePostStepRuntimeError and ProcessModelPostStepRuntimeError. For example, I'm creating a common process model that does everything I need it to. It's not product specific and so, just handles all the things I think are standard among all products. One standard item is a standard way to handle Errors that occur. In the ProcessModelPostStepRuntimeError, I set it up to be the generic error handler. That collects it, logs it, displays error screen, and usually terminates the test. It also calls the "CancelStepCallback".  I then have one product that wants to change the behavior. It will display a different style dialog, reset the equipment, and provide specific functionality for specific error codes. This is set up as a SequenceFilePostStepRuntimeError. Since I don't want my generic error handler to be called, I also set both the "CancelStepCallback" and "ErrorReported=True".

On my test machine, the client file's Error Handling works correctly and displays the custom error handling. When I deploy, I only get my generic error handler. It seems that the sequence file callbacks got reordered. I have a hard time thinking it could be random as it's always one or the other on the computer. Why is it like this?

What would be a ideal way to implement this feature set without resorting to using StationPostStepFailure as I don't think my generic error hander is always generic among all process models.

[paulmw]

TestStand step order of actions can be version dependent.  Here it is for 2014.  Do the two systems have the same versions (including service packs)?

[bsvare]

Thanks for the feedback, but even according to the page you linked:

---

When TestStand detects a run-time error in one of these actions, it calls the Post-Step Error Engine callbacks. When you do not define these callbacks or when the callbacks do not reset the error state for the step, TestStand executes the following actions to clean up the execution of the step:

---

It does not explain which call back is called first, second, or third. Or why that they are different between my development machine, and the deployment machine. They are running the same version and service pack of TestStand. 2014 - SP1

[Dsun]

Sequence file Callbacks will always run before Process Model Callbacks, so the way you set it up should work perfectly fine.  For clarification, is the SequenceFilePostStepRuntimeError you mentioned part of the Process Model, or in it's own Sequence File?

Beyond the general architecture, there may be something wrong with the deployment.  The logic makes sense to me so perhaps the inconsistensy arises from the deployment image.  When you run it on you development machine, are you using the TestStand development environment or the deployment image?  I suggest trying out the deployment image to see what the behavior is.  

[bsvare]

Thanks for the feedback. I do have the SequenceFile callback in my client sequence file.

I ended up making a slight change between the development and deployment that caused all my confusion. My development computer does not have the hardware to duplicate the testing exactly. So I wrote a sequence file to test the behavior I want. Verified it worked, then placed it into the delopment sequence file for the deployment station. The thing I didn't realize was that I don't have only 1 sequence file. So the location that was getting an error was a sub-sequence file which didn't have the callback. Thus it resorted to using the ProcessModel's callback. That in turn disabled all further callbacks (so when it returned to the sequence and terminating all the sequence stack, it didn't re-generate the error callback, thus never hitting the client file's callback)

I got too use to the process model callback working for client sequence and all subsequences. I didn't realize that the sequence file callback only worked for the one sequence file but not any of it's children. So... I either have to invent a new callback to do client file and all children, or add the callback to all 30 sub sequence files.