From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Semaphor behaving different than expected

Hello everybody,

 

I am new to Semaphors and although I thought I understood the working principle, they dont behave the way I want :S

 

I am using two VIs (attached are the simplified block diagrams). The Experiment VI will carry out an experiment which requires a pressure reading. On the other hand there is the logging Vi that frequently logs the pressure, to monitor the pressure even if no experiment is carried out. To avoid both vi accessing the same pressure reading instrument at the same time I use Semaphors. However, to me it seems like the Example VI is not able to successfully occupy the Semaphor. Therefore, the logging VI always accesses the device although the experiment is still running.

 

I really dont know what I am doing wrong here. I am thankfull for any advice!

Regards Stefan

Download All
0 Kudos
Message 1 of 10
(2,795 Views)

Hi Stefan,

 

          If I am correct, you should be using a while loop inside the data logging VI, which will not exit until the logging is stopped by some means. Once the data logging VI acquires the semaphor, it start logging the data continiously without coming out of the loop. So there is no possibility for the Experiment VI to acqire semaphor, since the semaphor is not released by data logging VI. I have attached a sample VI, which explains the concept of semaphore. Select Highlight execution and run this attached VI to understand easily. Can you be more specific so that I can understand the problem clearly.

 

Reards,

Gopal.

0 Kudos
Message 2 of 10
(2,773 Views)

Hi Gopal,

 

I think I did not state my question precisely enough. The actual logging VI which I use has a second while loop behind the casestructure. The second while loop causes a certain waiting time which is specified by the user. During this time I thought the semaphor is available for the Experiment VI to acquire it.

Therefore, I think the actual logging VI is fine. To me it seems like the Experiment VI is causing the problem. Maybe it is not possible to acquire the samaphor for too long? Or maybe the sequence structure to the very right of the block diagram is executed too early; namely before the called VI is terminated?

That would explain why the logging VI, when analyzing the status of the semaphor, sees it as available and thus aquires the semaphor?

 

I hope I was more precise this time.

Regards Stefan

 

PS: I am using LabVIEW 8.2 and couldnt open the attached file

0 Kudos
Message 3 of 10
(2,758 Views)

Hi Stefan,

 

           Sorry, I don't have LV 8.2. In LV2009, by default the timeout for a Acquire Semaphor VI is -1. It waits infinetly untill it acquires semaphore. So there is no need for the case structure with while loop on the other side at all. But I'm not sure whether Acquire Semaphor VI is available in LV 8.2. Can you list the VIs that you have in LV 8.2 related to Semaphor? 

 

Regards,

Gopal

0 Kudos
Message 4 of 10
(2,746 Views)

Hi again,

 

I think all the required VIs are there: CreateSemaphor, AcquireSemaphor, ReleaseSemaphor, DestroySemaphor, GetSemaphorStatus and NotaSemaphor.

 

The thing is, I don't want the AcquireSemaphor in the Logging VI to wait for an infinite time. Therefore, I placed the GetSemaphorStatus VI in front of the case structure. Since the created Semaphor has a size of 1, the Logging VI analyses the output "available". If it is 1, the semaphor is acquired to perform the pressure measurement. If it is 0, the program knows that the Experiment VI is occupying the instrument. Therefore, instead of logging the pressure, a text is written to the log file stating that logging was not possible. For the Example VI on the other hand, I want it to start as soon as the semaphor is available. Therefore, I directly use the AcquireSemaphor VI.

 

The problem is, if I first run the Experiment VI and then the Logging VI, the GetSemaphorStatus always gives out available=1, although the Experiment VI is still running and should thus still acquire the semaphor (resulting in a 0).

0 Kudos
Message 5 of 10
(2,730 Views)

Use the Acquire Semaphore timeout input.  Set it to the maximum time you want to wait (in milliseconds).  Then put a case structure afther the Acquire Semaphore with the selector wired to the "timed out?" output from Acquire Semaphore.  You do not need Get Semaphore Status.

 

Without seeing your actual VIs, it is hard to say what is going on with the Experiment VI blocking.  Please post the VIs.

 

Lynn

Message 6 of 10
(2,721 Views)

Are you running the VIs in LabVIEW, or are you compiling them into EXEs?

 

This won't fix your problem, but the way you are checking for semaphore availability is not the way you want to do it.  I understand why you did it that way in the monitor program, but it is possible that between you checking the available count and acquiring the semaphore that it could be acquired by another process and now, you're waiting indefinitely.

 

Instead, wire the timeout to something (say 100ms) and use the timeout output to a case statement that performs the measurement and unlocks the sempahore.

0 Kudos
Message 7 of 10
(2,719 Views)

Lynn is right is saying "You do not need Get Semaphore Status."

 

Stefan, your code might not execute as you expect, because

(1) you ask for the state of the semaphore.

(2) You try to acquire it after (1) executed.    -->  How can you be sure that noone acquired the semaphore between (1) and (2) ?

 

You're better off following Lynn's advice.

Guenter

0 Kudos
Message 8 of 10
(2,716 Views)

Ok I think I have it!

 

You are right, Lynn's advice is the best way to handle it. And I had it like that long time ago. But back then I still got the undesired behaviour. Therefore, I thought the acquire VI will force the acquisition once the timeout value is exceeded. Anyway this is NOT the case, so removed the Get Semaphor Status.

 

Apparently the reason why the semaphors did not behave in the intended way was that the two VIs belong to different LabVIEW projects. So if i open them from the opened projects the semaphors somehow can not be linked together. I have no idea why.... But if I open each VI directly (without loading the project first) they link and work as expected... Also there seems to be some malfunction if I stop and restart the VIs in a certain order (Start Experiment, Start Logging, Stop Experiment, Start Experiment, Stop Logging, Start Logging). I dont have a reason for that either...

 

Anyway it works now ! I just open the VIs without opening the projects first. Since the Logging VI will be running for ever, the malfunction will not appear, even if I stop and start the Experiment VI many times.

 

Thank you all for your input!

0 Kudos
Message 9 of 10
(2,701 Views)

The reason the projects prevent it from working is the same reason I asked if you have two EXEs.

 

LabVIEW reserves separate memory space, so Pressure Reading will create two different semaphores - one in each application space (project).  When you open the VIs in LabVIEW without the project, LabVIEW puts them in the same application space, so the semaphores are the same.

 

You would have to explain the malfunction (i.e. what happens) to help you with that.

0 Kudos
Message 10 of 10
(2,695 Views)