SubVI Value not updating when connected to connector pane

[lilmaniac2]

I have a legacy program that calculates a frequency when a sensor value changes (falling edge basically), and I'm trying to convert the logic to a subVi so I can use it for 44 other sensors. The program initially used a large number of Value Property Nodes, which I found out is not proper for subVis. I converted them to local variables, but I still am having issues.

The issue is as soon as I connect something to the connector pane output the value quits updating. If I remove the connection from the connector pane it works fine.

attached is an image of the block diagram. I have tried connecting both Freq and Frequency Output to the connector pane, as soon as I connect it to the connector pane it goes from functioning fine to not updating at all.

The VI is setup as non reentrant.

Thanks

[udka]

-Without having full functionality of main code it's difficult to decide what is functioning and not functioning.
-What are inputs to this SubVI and ouput values for e.g. fro Freq and Freq Output actual expected and present executed values?

[JÞB]

Lets take a look here.

What you get and what you want are vastly divergent!  What you appear to want is some means to store the value of "output array" between calls to this vi.  A Local is just simply not going to do that!  Locals have default values until a value is supplied to the terminal!

Try a slight step in the right direction thusly:

That is a Feedback Node, it remebers what the value was the last time the vi was called (unless reloaded or recompiled) Another common memory element is a Shift Register left uninitialized.  You have MANY locals that should be replaced with Feedbak Nodes.

[RavensFan]

Since your problem is about why a program is not working properly with this subVI, it would be helpful if you included the main VI as well as the subVI.

But poking around your subVI, I see a couple things.  One of them I'm sure is the answer.

First.  Local variables are better than property nodes, but using actual wires would be better.  Then you can get rid of the sequence structure.

But the real problem is your subVI only has one input, "Input", and one output, "freq".  But you have a lot of other controls and indicators in there whose values are only defined by their defaults within the subVI.

Start with turning on highlight execution on this subVI, and watch the dataflow when you run your main VI.  Up front you look at counter <= Samples.  These values aren't on the connector pane.  They are both 0.  So the are Equal and thus the true case runs.  Inside you use the input value to work on an Output Array, which is empty and will likely remain empty, but never goes anywhere after this subVI.  And increment Counter which is 0 to start, but Counter never leaves this subVI.

In the end, you do a little work on meaningless default data, but basically accomplish nothing because it never goes anywhere.

I would recommend looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours

---

@Chad.H wrote:

The issue is as soon as I connect something to the connector pane output the value quits updating. If I remove the connection from the connector pane it works fine.

---

That part of your question makes no sense to me.  But it really doesn't matter in light of the other problems I listed above.

[lilmaniac2]

Its impossible to give you the fully functioning main code, as it uses a DAQ device that I'm sure you don't have on your machine.

The input to the subVI is the output from the daq card (analog voltage)

The output should be the frequency calculated for the previous 1 second.

Here is an image of what I'm talking about

[lilmaniac2]

Is there advantage to using the feedback nodes vs the local variable?  In the back end isn't it doing the same thing?  

Feedback nodes to me are harder to understand ( probably due to my text based programming background x= x+1; // for example)

The program functions fine when the connector pane is disconnected, I fail to understand how switching to feedback nodes alleviates this issue?

[Ben]

Please post the code so we can see the context .

I am baffled what you are attempting to do without context.

Ben

[JÞB]

---

@Chad.H wrote:

Is there advantage to using the feedback nodes vs the local variable?  In the back end isn't it doing the same thing?  

Feedback nodes to me are harder to understand ( probably due to my text based programming background x= x+1; // for example)

The program functions fine when the connector pane is disconnected, I fail to understand how switching to feedback nodes alleviates this issue?

---

As ravens fan pointed out- you did not attach the code so we can only guess.  We can replace the DAQmx device with a simulated one or even a simulated signal.

[lilmaniac2]

Thanks for the reply, a couple things.  As I stated in the OP this is legacy code given to me by another dev.  It functions fine when not in the SubVI (and functions fine when the connector pane output is not connected), I realize it follows some antiquated practices when it comes to developing ( flat sequence structure vs state machine for example).  I've taken both Core 1 and Core 2, and I know there are better ways to doing it, but like many of you I have a to do list about a mile long and really don't want to take the time to rewrite this entire edge counter, this started as a simple take the code and convert it to a subvi, something I thought would take 5 mins todo.

I currently have defaults set via the front panel properties (sample is defaulted to 100).  I can add them to the connector pane, but I don't think that is causing my issue.  I attached an image to a post above showing the issue.  I'll also work on getting a main vi that can simulate the DAQ hardware so you all can see my issue.  

[RavensFan]

---

@Chad.H wrote:

Its impossible to give you the fully functioning main code, as it uses a DAQ device that I'm sure you don't have on your machine.

The input to the subVI is the output from the daq card (analog voltage)

The output should be the frequency calculated for the previous 1 second.

Here is an image of what I'm talking about

---

But the problem is your subVI has only 1 input and 1 output.  You have many other controls in that subVI that are critical to how that subVI functions.  You don't have them connected to anything.

It is kind of like you did a brain transplant, cut out a dozen neurons, but only bothered to reconnect 2 nerves.

In your picture, the reason why the one indicator "works" is that it is stuck at whatever value it was at since you haven't connected it to anything.  Or it is getting a value from somewhere else in your main VI through a local variable or property node.  The one indicator showing 0 when it is connected to the subVI is because of the reasons I described early.  Your subVI isn't really doing anything, and the indicator on the subVI is outputting its default value of zero.

Have you run your code with highlight execution turned on yet?  Even use probes.  Use your debugging tools so you can understand how your VI is actually running.