Broken Semaphore VIs

[RobbieD]

Hi.

I'm relatively new with regard to LabView development, so not sure if I'm missing something with this issue.

Just started a project which requires the use of semaphores and have noticed that all of the semaphore VIs seem to be broken, i.e. unexecutable. As far as I can tell, this is down to the Semaphore Refnums in the relevant VIs being greyed out. 

The errors listed in the VIs, e.g. Release Semaphore.vi, seems to relate to scope issues - 'Type Definition 'semaphore': This VI cannot access the referenced item in private scope'.

I've tried to run the semaphore example provided by NI and get the same errors.

Has anyone encountered this issue before, and if so, is there a resolution?

Cheers

Rob

[RobbieD]

Apologies for the premature post.

Believe I've managed to sort the issue.

Somehow, the Semaphore Ref Typedef had become associated with a library I had created for testing cloneable modules. Disconnecting the Ref from the typedef for each instance seemed to sort it out.

Cheers

Rob

[billko]

This sounds more like a symptom than a problem.  Something like that should raise red flags.  I'd go through that project with a fine-toothed comb.  My personal note on how I feel about semaphores: It feels like cheating to me, like the problem could most likely be solved without using one if you took dataflow seriously.

[RobbieD]

Apologies for the late reply Bill. Limited to 2 posts per 24 hrs at the moment. Like the moniker (assuming it's in homage to the great Phil!).

Not sure how, but a library unrelated to the project had become a dependency resulting in changes to the access scope of the semaphore typedef ref used by the various Semaphore VIs.

With regard to data flow.. still adjusting to the paradigm. It was a bit of a shock coming from the world of .NET!

Cheers

Rob

[billko · Accepted solution]

---

@RobbieD wrote:

Apologies for the late reply Bill. Limited to 2 posts per 24 hrs at the moment. Like the moniker (assuming it's in homage to the great Phil!).

Not sure how, but a library unrelated to the project had become a dependency resulting in changes to the access scope of the semaphore typedef ref used by the various Semaphore VIs.

With regard to data flow.. still adjusting to the paradigm. It was a bit of a shock coming from the world of .NET!

Cheers

Rob

---

Like shifting without a clutch, I understand completely.  Wat I was saying is that if something like that happened once, you might find other things as well.  I would review the project as thoroughly as possible.  If you have an experienced LabVIEW programmer with you, see if they can sit with you on this.

[RobbieD]

Hi Bill,

This is the first LabView project undertaken within the company. Have a colleague who's also involved, but he's in the same boat.

Will scan the project as suggested.

Many thanks

Rob

[billko]

One of the best tools for this is to simply display the complete path in the project window.  I forget how to do that right now because I don't have LV on this computer.  But by enabling this, you can usually see if a VI or control doesn't belong.

[Claude1]

I have the exact same problem. Have tried a variety of things.

ElonOne

[AeroSoul]

If it's the exact same problem, then apply the exact same solution.

Otherwise we need more information.

[Yamaeda]

---

@billko wrote:

One of the best tools for this is to simply display the complete path in the project window.  I forget how to do that right now because I don't have LV on this computer.  But by enabling this, you can usually see if a VI or control doesn't belong.

---

Do you mean shifting to File view? Ctrl+E or the Files tab.