notification usage

[bilby42]

This may be an obvious question, but I've been unable to find an answer in the forums.

I'm using a Teststand Rendezvous with the batch process model. I cannot find a way to recover if one of the batch sockets fails before the Rendezvous is reached.

For example if I'm using a two socket batch model I create a Rendezvous with number of threads = 2. If socket 0 subsequently fails and terminates but socket 1 keeps running normally, eventually socket 1 reaches the Rendezvous and waits indefinitely because socket 0 never arrives. I can add a timeout to the Rendezvous but this is problematic as the test time to reach the Rendezvous can be difficult to determine - hence this timeout would need to be long to account for all conditions. Additionally the Rendezvous "status" step doesn't appear to provide anything useful to determine the pass/fail status of the other threads in the Rendezvous.

I get similar problems if one of the batch sockets is skipped at startup, i.e. the "Disable Test Socket" checkbox is checked at the "UUT Information" screen.

I'm using Teststand 2010 with Windows 7

Regards,

Tom

[bilby42]

Sorry, The title should have stated "Rendezvous Useage"...

[bilby42]

I've also looked at using a "Batch Synchronisation" step instead of the Rendezvous. This method seems to compensate for a socket that terminates prematurely and seems to work ok.

However it still raises the question - how can you practically use the Rendezvous step for runtime failures?

[Anjelica-W]

Unfortunately, the run-time error generated by the timeout is the only option available for the Rendezvous step. I think the Batch Synchronization step is better suited for your needs because it will not wait for a thread that has terminated and been forwarded to cleanup. The only difference between the Rendezvous and Batch Synchronization setup is that the Rendezvous can have multiple exit points, whereas Batch Synchronization requires an entry for each exit.

[bilby42]

Thanks for the reply Anjelica. It looks like I'll be using Batch Synch in this application.

However the obvious question is how do you ever use a Rendezvous? With batch models you can use Batch Synchronization, but if the parallel model is being used this option is not available. How can a Rendezvous ever recover from a terminated thread? 

I've wondered if you could use the timeout feature and continually do timeout loops that polled the runtime properties to check the status of the other sockets. However it rather destroys the elegance of the Rendezvous.

[dug9000]

---

@bilby42 wrote:

I've also looked at using a "Batch Synchronisation" step instead of the Rendezvous. This method seems to compensate for a socket that terminates prematurely and seems to work ok.

However it still raises the question - how can you practically use the Rendezvous step for runtime failures?

---

As you've already discovered, if you are using the batch model you are better off using batch synchronization, batch synchronization effectively rendezvous at the beginning and end of each section.

If you want to use rendezvous for non-batch based synchronization and you have the possibility of execution being short-ciruited due to run-time errors, then you will have to do something more complicated in your cleanup. Keep in mind that run-time errors are not typically something that happens in the normal case of running your test sequence, so they should be relatively rare events. In such cases a timeout on the rendezvous with a runtime error when the time-out occurs makes sense in most cases. Keep in mind rendezvous are not likely to be used with multiple instances of the same sequence running, because in such cases, batch synchronization would make more sense. Rendezvous are more geared towards utility threads and other sequences which aren't typically run like a batch. Rendezvous are a lower-level primitive than batch synchronization, batch synchronization is designed for a specific purpose, while rendezvous are more general purpose.

Hope this helps explain things,

-Doug

[bilby42]

Hi Doug,

I thought the same issue arises when you get a simple test failure. In normal cases I will jump to cleanup on a test failure which causes the same problems (and is more common than an error).

I also thought the Batch Synch could only be used with the batch process model, not the parallel model.

However I take onboard your comments re Rendezvous use for utility threads.

Regards,

Tom

[dug9000]

---

@bilby42 wrote:

Hi Doug,

I thought the same issue arises when you get a simple test failure. In normal cases I will jump to cleanup on a test failure which causes the same problems (and is more common than an error).

I also thought the Batch Synch could only be used with the batch process model, not the parallel model.

However I take onboard your comments re Rendezvous use for utility threads.

Regards,

Tom

---

What exactly are you trying to synchronize? Perhaps a rendezvous is not the best kind of synchronization for you to be using. If you find yourself using the parallel model with rendezvous, then you should probably consider using the batch model instead as that would probably make more sense. The parallel model is for cases in which the sockets aren't strictly synchronized. They might be synchronized to share access to hardware, but are not typically synchronized to begin and end executing the client sequence together, so rendezvousing at a particular point does not really make sense because the sequences could be at any location in each socket. If you want to strictly control and synchronize the location within the sequence, across all testsockets, then the batch model is probably a better choice.

-Doug

[bilby42]

Hi Doug,

Yes, I'm already using the Batch model for this application so Batch Synch will do the job in this case. In my app a batch synch is used to release two power supply channels to do a calibration phase. My two socket batch model needs to serialise the sockets so both DC channels are released for cal. 

I'm just trying to understand when the Rendezvous would be appropriate - which you have probably answered regarding supporting threads. 

[dug9000]

In summary: The rendezvous is provided as a low-level primitive like it is in other development environments like LabVIEW. It is not necessarily used for synchronizing multiple main socket threads (and in such cases the batch model with batch synchronization probably makes more sense), it might be used for synchronizing a main thread with utility threads. If you had such a case and needed to handle the rendezvous being skipped due to an error or failure, you could add special code to the cleanup of that sequence that perhaps does the rendezvous in the cleanup to allow the other thread(s) to continue, or use a timeout. The rendezvous does not have an an automatic cleanup feature. We could perhaps add one in the future, but it would likely need to be an option because it wouldn't make sense in all cases for such a low-level primitive.

Hope this helps clarify things,

-Doug