09-28-2006 09:42 AM
09-28-2006 11:08 AM
09-28-2006 11:21 AM
09-28-2006 01:50 PM
09-28-2006 01:51 PM
09-29-2006 08:23 AM
I looked at what I did then came back and re-read your original post. It sounds like after you've acquired a semaphore, some of the subsequent vi's you call may possibly produce an error. This error cluster gets passed into the Release Semaphore function, and no Release happens due to the input error. Is that right so far?
There's a boolean output in the call to Acquire Semaphore to tell whether you successfully acquired or not. I fed that output into a case structure that contains all the instrument communication ONLY when the semaphore was successfully acquired. Similarly, Release Semaphore is called ONLY when Acquire was successful.
Could you simply choose to route the error cluster *around* the call to Release Semaphore, allowing the Release to occur while still passing the error along to other vi's in the chain? You may need to stick the Release call inside a 1-frame sequence to help enforce dataflow sequencing.
-Kevin P.
09-29-2006 08:32 AM
09-29-2006 02:19 PM
... but there is something I don't like about going around the error cluster 😉
Yeah, me too. The rest of what you might want to do is merge the error cluster that *should* have gone into the Release Semaphore call with the error cluster coming out of the Release Semaphore call.
If I remember right, I also got bitten by that issue of the Release call not actually releasing the semaphore when the input error cluster had an error in it. I had wrongly assumed it would behave much like DAQ Clear Task calls work, allowing the task to be cleared in spite of input errors. It is probably the appropriate behavior though, since Acquire/Release is kind of analogous to DAQ Read/Write. You're using the semaphore refnum to do its "normal" work, so input errors are not ignored, similar to how Read/Write are the normal work of DAQ tasks.
-Kevin P.