copying values from front panel

[Been bitten by LabVIEW]

Hi all,

I am trying to decouple wiring from one vi to another.  This is done by having two intermediate SubVIs, one that that is wired to (a faux VI) and the other to do the drudge work (called VI_Vector..call.vi).  Inside the VI_Vector..call.vi it copies the VI's controls that is wired to by iterating through the "Get All Control Values" to the real SubVI via "Set Control Value" (the real SubVI is passed by name, if coping fails, it opens the VI and then does the copy).  The real SubVI is then run using Run VI and waits for it to complete.  It then copies the real SubVI's indicators back to the faux VI caller.

Before anyone says it, I know that this is not a very fast way of doing things, but I'm not worried about speed.

This does seem to work, except, when I do this initially upon staring LV, it doesn't pass the information unless the faux VI is manually opened prior to running the main VI which calls the faux VI.  However, upon the second execution, it will work no matter what.

Does anyone have any idea why this is so?


Adrian

P.S. I am using LV 7.0

Message Edited by Been bitten by LabVIEW on 10-10-2007 01:38 PM

[Wiebe@CARYA]

Could it be that the values are updated with "Get All Control Values" before
the original vi has updated them? So the copying does happen, but the copied
values are the default values?

Regards,

Wiebe.

[Been bitten by LabVIEW]

Could be, but that doesn't help.  How do I force an update?


Adrian

[Kevin_Price]

I got stuck with a similar-sounding issue a couple years ago.  First see this message, then this one.

I never did fully resolve the whole mess -- I wound up using a short-term workaround.  Since then, I've approached similar "spawned process" needs using different approaches in code.  Generally, these involve message sync'ing mechanisms like Queues and/or Notifiers.

What is your purpose for passing data via "Get Control Values" and "Set Control Values"?  What are you trying to accomplish with this approach?  Maybe your reasons are different than mine were and perhaps there's hope for a cleaner solution for you.

-Kevin P.

[Wiebe@CARYA]

Well, I can't look in to your application. This (if this is indeed the
problem) is a race condition. The vi that reads the values dynamically is
executed first (it won the race).

A simple (and kludgy) way to fix it is to put a wait before the vi you want
to execute last. Use a sequence frame to force the execution order. Or use
the Express Wait, so you can use the error out and wire it to the error in
of your vi.

There are much better ways, but they all fix this kind of problem on an
architectual level. For instance, I start parallel processes dynamically in
a main vi, and the order of the startup can be forced. I can wait for a vi
to startup before I start another if I need to, because the started VI's
trigger an unique occurence when they are initialized. The Sub VI that
starts the vi's dynamically waits for the occurence (as an option) so I can
synchronize the startup with the error line.

Another way to solve your problem is to communicate the control values
differently. For instance, by using an buffer (global data buffer). That
will be some work to get started, but will be much more flexible in the long
run. You can also use a buffer to prevent the reader vi to read before the
other vi started. It depends on the application...

Regards,

Wiebe.

[Been bitten by LabVIEW]

The purpose is to dispose of the connector pane, which is a pain in the ass. 😞  Seems like connector panes are not compatible when they should be (same layout, types and names).  I've tried to use ConPane property to copy as well, but it doesn't seem to work very well either, probably due to the same reason.

So the reason for doing this is to eliminate the connector pane from the problem, but I've been reading and this may be a hassle as well since I may have reentrent functions using this method.  I'll have to check out templates.

I just wish that types could be passed like C++ templates do, as this would simplify code centralisation while enforcing type safty to the nth degree.

Adrian

[tst]

It sounds to me like you're trying to coerce LabVIEW to match your thinking. Why not use the connector pane? It's the best way of passing data to called functions. Just use a standard connector pattern (4-2-2-4 is probably the most common one with the corner terminals reserved for references and error IO). In any case, always use a pattern which has more terminals then you'll need. 

As the others have mentioned, there are much better ways of inter-VI communication than what you're doing, but my guess would be that the FP of your VI is not loaded into memory. Try placing a property node for one of the FP controls in the BD of that VI. That should force it to be loaded.

[Been bitten by LabVIEW]

---

@tst wrote:

It sounds to me like you're trying to coerce LabVIEW to match your thinking. Why not use the connector pane? It's the best way of passing data to called functions. Just use a standard connector pattern (4-2-2-4 is probably the most common one with the corner terminals reserved for references and error IO). In any case, always use a pattern which has more terminals then you'll need.

---

Yeah, I tried that.  Didn't have much success.  Do I need to use a standard connector pattern?  Perhaps that was my problem.  I just used a pattern that had the correct amount of terminals which didn't neccessarly confrom to a standard one.  But they did have the same layout as the others.

---

@tst wrote:

As the others have mentioned, there are much better ways of inter-VI communication than what you're doing, but my guess would be that the FP of your VI is not loaded into memory. Try placing a property node for one of the FP controls in the BD of that VI. That should force it to be loaded.

---

Tried that.  Didin't work.  Anyway, I think I'll abandon that since it will become problematic if I were to do recursion or multi-thread stuff.

Thanks,


Adrian

[tst]

---

@Been bitten by LabVIEW wrote:
Do I need to use a standard connector pattern?

---

No, but it makes your code much cleaner and easier to use. If you see that you are nearing the number of terminals, that should be a hint that some of the inputs\outputs belong in typedef clusters or that you need to divide the functionality into more than one VI. Leaving empty connectors is never a problem and is very useful when you need to add inputs or outputs later. As I said, the most common pattern is probably 4-2-2-4 and it's the one I use.