Reference to control on main front panel fails when subvi front panel is closed?

[Arpsy]

Hi All,

I'm experiencing an odd bug. In my code, I use a subvi to control a piece of hardware. This subvi has controls for all of the functions of my hardware.

I'm changing the value of one of these controls from my main front panel by running a reference to a knob on my main front panel into the subvi, grabbing the value of the knob with a property node, and then updating the value of the subvi control using a signaling property node.

This works fine when my subvi front panel is open but fails to work at all when the subvi front panel is closed.

I'm new to labview , so any help is appreciated.

Thanks,

Arpan

[GerdW]

Hi Arpsy,

you should not use references like that. There are other methods to transport data between parallel loops like FGVs/AEs, User defined events, notifiers, queues, ActorFramework, and even global variables…

Nevertheless: show your VIs (or simplified version of them) to demonstrate the problem!

[altenbach]

What is your LabVIEW version?

Front panels that are not shown are typically not updated and might not even be loaded into memory.

The presence of certain code elements (e.g. property nodes) often forces the front panel to be in memory even if it is not shown, but I haven't studied it in a long time so there might be subtleties. Maybe somebody from NI can give more details.

If it does not work unles the FP is open, open the front panel minimized to avoid distraction.

Can you attach some code? Maybe there are better ways to do all this anyway.

[Arpsy]

Here's the subvi of the subvi whose front panel must be open where all the updating goes on. The Waveformctls cluster that comes in is from my main VI, and the 4 references near the bottom are from my subvi. Interestingly enough, the gain updating is the only thing that fails - all the waveforms and the boolean peakdetectmax control update just fine. 

To be clear, this is located in the timeoutcase of an event loop so it updates.

[Arpsy]

This is labview 2012 by the way. It's an application requirement that the second front panel be closed.

[altenbach]

Code pictures are typically pretty useless. We prefer actual VIs.

What happens in the "knob:value change" event? Why does it even need an event?

[Arpsy · Accepted solution]

That event triggers a serial write to the actual hardware. The hardware is only sent a command when something changes.

My code is organized into event handlers inside functional global variables. This way, I can send different parts of the code different commands (example: reset hardware and reinitialize) with programatically-generated events.

The main page's knob's value itself, according to my probes, is getting passed on through. It's the subvi knob that's having an issue.

I'm working under some pretty significant time pressure so I managed to convince the boss that having the subvi front panel open does not violate application requirements. I guess that this solves my isse. 😛

[Arpsy]

Regardless, thanks for all your help. You guys rule!

[RavensFan]

What happens if a user decides to close the subVI on their own?  Doesn't the problem still occur?  Wouldn't that still be a problem with your application?

[altenbach]

---

@Arpsy wrote:

That event triggers a serial write to the actual hardware. The hardware is only sent a command when something changes.

---

Well, since you are polling the knob anyway you can sense a value change using a feedback node and a "not equal". No events needed. Whenever the value changes, just trigger another state, then revert back to the timeout state.