Semaphone becomes "not a refnum" when passed in to sub vi

[spastichawk]

In my main front panel VI i generate a semaphore at the beginning of program execution. This semaphore is then passed into a reentrant clone sub vi (and subsequent clones). When the semaphore reference is passed into the first sub vi it becomes invalid and probes as "not a refnum" right at the control input of the sub VI.

I am hoping the solution to this is something simple as this program had been working fine passing the semaphore along. I have tried reconnecting some things just to make sure tehre were no connection errors caused by erranous clicks but no change in outcome.

[crossrulz]

Do you have any code you can post?  Impossible to diagnose otherwise.

But my gut feeling is that you have something closing the semaphore.

[spastichawk]

Here is a snapshot which encompasses the semaphore path where it fails.

Below shows the semaphore being created and passed into the sub VI. Probing the input of the sub VI shows teh semaphore reference.

Below is the control that recieves the semaphore input in teh sub VI(clone). When probing the output of the control the signal becomes not a refnum.  There is nothing else touching the semaphore from creation to failure

[udka]

I think if i understood correct:

-In first image you passed semaphore ref into a cluster.

-Second image you are passing from semaphore control to subvi.

Now, Where is the connection to the control from the cluster(semaphore ref is in cluster) which you passed?

[spastichawk]

udka,  the semaphore ref is passed into a sub vi. the second image is the semaphore being transfered from the sub vi's control (input) to the aquire semaphore vi.

After som digging around yesterday, the snippets that I posted do work. The error in troubleshooting was PEBCAC as I assumed teh problem was happening at the first sub vi. The sub vi is a reentrant clone and tehre are 16 of them that pass along the semaphore in the program. Somewhere way down in the list of them a wire became disconnected <oops>. The issue I had was that it was not obvious which sub vi block diagram was automatically  opened when the error occured and the program was stopped.  

[billko]

FYI - In the Land of LabVIEW, snippets are actually executable pictures!  (They are png files with metadata that LabVIEW can parse and generate code from when you drop the snippet onto the block diagram.)  The way to create a snippet is to select the part of code you want to make into a snippet, go to the Edit menu and select "Create Snippet from Selection".  A file dialog is displayed and you can save the snippet where you want.  The picture ends up being a picture of the selection and the metadata is the code.  That way, people can see what the code looks like AND they can actually reproduce it - YMMV regarding the faithfulness to the original code - on a block diagram.

Just food for thought for next time you post.  🙂

[Gregory]

Hi uday,

I think the first picture is actually passing the semaphore into a VI with a LOT of inputs/outputs. It does look a lot like a cluster bundle, but it's just the VI with unchecked "View as icon"

[Gregory]

Hi spastichawk,

How do you ensure that you are probing the clone which is running?

[Ben]

"step into" the sub-VI call and it will open the instacne being invoked in teh diagram. back out gracefully and close VIs as you go. At one time LV would crash if you did not close as you backed out.

Ben

[spastichawk]

I ended up finding the error by just starring at the screen and verifying all connections. When the program is running and labview throws an error giving the option of stopping or continuing I was clicking stop and teh clone where the error was encountered would be opened with a brief highlight of the block the encountered the error. I do not know if it was possible to step in/out after clicking stop. 

In retrospect if there is a way (I have a feeling there is) to make sub vi connections mandatory it would prevent this type of error ever getting to runtime. ie. not connecting an input on an "OR" operator results in the compiler pointing it out when trying to run.