LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using Semaphore with a Global Variable - Correct Usage?

Solved!
Go to solution

Hi all,

 

I've looked into using global variables and in my case it looked like using a semaphore was the appropriate solution.

 

In my case, I use a global variable to keep the status of the system. Two asynchonous re-entrant VIs (same VI) will monitor two COM ports to see if they get a 'login:' prompt. If the COM port is associated with Alpha, Charlie, or Echo, it will increment by 1, and if it is associated with Bravo, Delta, or Foxtrot, it will increment the GV by 2. If the GV is 3, the rest of the code will execute. In this case, one COM port must be A, C, or E; the other must be B, D, or F.

 

A parent VI calls this inside a loop. It works for the first loop. It never adds up to 3 on the second loop, though. I can't figure out why. Please let me know if my code is improper usage of semaphores, or if there is some debugging I can try.

 

I'm still relatively new to LV, so I'm sorry if my VIs are hard to read. I built this in LV2011.

 

Thanks for any help!

Download All
0 Kudos
Message 1 of 5
(6,148 Views)

Two problems I see.

 

1.  Your numeric global may never actually equal 3.  Since you are comparing a float to an integer, there is a chance that 3 does not equal 3.

 

2.  How does your numeric ever get to three.  The subVI waits in a loop until the numeric equals 3.  But the only place the global seems to change value is after that while loop ends.  So you are stuck waiting for the numeric to equal 3 and it never gets a chance to change value.

0 Kudos
Message 2 of 5
(6,138 Views)

RavensFan,

 

Thanks for the reply.

 

I changed my int32s to floating points so there are no more coercions. I'm still seeing the issue. In fact I ran it with some probe watches and saw that the outputs of both DetectLogin VIs were Ttrue, but the GV was at 2.00. This makes me think that the A/C/E channel input isn't getting to the GV and incrementing it to 3.00...

 

The output of my while loop (wait until GV = 3) goes to the case structure on the bottom right (clear GV, PasswordEntry, etc.), so the GV does indeed get accessed by the upper-right-hand case structure.

 

Thoughts?

0 Kudos
Message 3 of 5
(6,129 Views)
Solution
Accepted by topic author CelerityEDS

@CelerityEDS wrote:

 

The output of my while loop (wait until GV = 3) goes to the case structure on the bottom right (clear GV, PasswordEntry, etc.), so the GV does indeed get accessed by the upper-right-hand case structure.

 


??

 

Your upper right hand case structure doesn't execute until your while loop ends.  The while loop doesn't end until the global equals 3.  Where else do you increment the global besides the case structures you can't get to yet?

 

Have you tried running your VI's with highlight execution on so you can see how they actually execute?

 

Another problem I see.  Assuming your initial while loop does exit.  In your case structures, you lock the semaphore.  But you may never unlock the semaphore unless you have the right combination of conditions that allow you to get to the case that unlocks the semaphore.  The conditions are based on data that is read before the case structure starts, which means that data isn't going to be read again and changed until everything ends.  You have the timeout of your lock semaphore wired into one of the case structures, but your lock semaphore can never timeout because you don't have a value wired into its timeout input.  I think you have a situation where  you can lock a semaphore, then get to a situation where you cannot unlock it, then wind up locking up your code cold.

 

I really don't think you need a semaphore at all.  I think you can protect the reading and writing of your global by using a functional global variable, i.e. action engine.  Overall, I think you need to rethink the architecture of your code.

Message 4 of 5
(6,117 Views)

Action engine for the win!

 

Thanks for the help RavensFan.

 

I posted my latest code.

0 Kudos
Message 5 of 5
(6,091 Views)