LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error Handling with Semaphores

Hello all!

I have a pretty extensive program that communicates with GPIB instruments etc.  I have a while loop to manage UI and the other to handle all commands to instruments.  I need to synchronize both loops sometimes with semaphores (i.e:  UI calls a "read output" to the command loop and it return a value to the UI). 
One problem I have found annoying with semaphores is error handling.  Lets say a loop is waiting for a semaphore to be released but the "release semaphore" vi will never be run because an error occured beforehand.  Is there no way to release a semaphore with an error (notifying the release than an error occured)??  Or is the only solution giving it a "time out"??
Thanks for your insight!

Yohan
0 Kudos
Message 1 of 8
(2,946 Views)
Hi Yohan,

From looking at the VIs for semaphores it doesn't look like there's a way to implement this using semaphores alone.

You could use notifiers in conjunction with semaphores to pass information between the loops about whether or not errors have occured... does that seem like a possible option?
Sarah

Applications Engineer | National Instruments | UK & Ireland
Message 2 of 8
(2,937 Views)
Fairly recently, I had my first experience implementing semaphores for instrument communication and I recall needing to learn about certain error-handling issues by trial-and-error.  I don't remember exactly what I finally did, but I know it's been working successfully.  There's a background process that continuously queries the instrument for data.  But at any time, the test sequencer may require access to send a command down to the instrument.  The semaphores have helped make sure communications from independent processes to a single instrument work out smoothly.
 
I'm not near that test PC now but will take a look when I can and report back.  Hopefully, I did something "right" and am not just getting lucky... Smiley Surprised
 
-Kevin P.
CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 3 of 8
(2,935 Views)
Hi Sarah,
I had actually thought of using notifiers to pass error data but I find it doesn't make much sens since it would eliminate the use of semaphores to begin with.  I will continue to ponder on this 😉
Thanks

Yohan
0 Kudos
Message 4 of 8
(2,922 Views)
Thanks Kevin,
if you can have a look at what you did earlier, that would be appreciated!
Cheers

Yohan
0 Kudos
Message 5 of 8
(2,922 Views)

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.

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 6 of 8
(2,895 Views)
Hi Kevin!
Thanks for the reply.  Your first option I had not thought about... that's a good idea.  And the second option you wrote about I had already started using... but there is something I don't like about going around the error cluster 😉
Cheers

Yohan
0 Kudos
Message 7 of 8
(2,892 Views)


... 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.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 8
(2,881 Views)