LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Functional Global run from Source vs Executable

Solved!
Go to solution

Hi...  Imagine a simple Functional Global (uninitialized shift registers on a while loop with internal Set/Get Case Structure) where in one instance I run the code from source and I use the Set mode to enter data into the circulating shift register at relatively high rate, say once per second.  Then I have, running on the same computer, another insance of the same Global where I Get data at some slower rate, say once per minute...  And in fact, what I'm doing here is having three different instances of the Global Setting data from three different pieces of hardware and then I use the one instance set to Get to get all three samples of data at a lower rate (I only care about seeing the data change over a 60 second time frame...  When I build all this from source code and run it, it all works perfectly...  I Set data from three different instances of the Global from three different sources...  Then I bring all those together in one place and use one more instance of the Global set to Get to Get all three pieces of data once per minute...  So far so good..

 

But in my real deployment, I can't run from Source code.  I need to compile this code into executables...  I've done so and tested it...  The three different Set executables appear to work just fine but the Get instance in executable form has no data.  I built this test because I realized I don't quite know how this Set/Get Functional Global concept works at the compiled code level...  Am I missing something???  Can this be made to work in some way????  

 

What do I need to do to get data to be read from the Functional Global (Get) when I work at the executable level???  Any help on this would be much appreciated...  thanks...  bob...

0 Kudos
Message 1 of 10
(2,428 Views)

Ok.

 

First things... read about the "functional globals" and "action engines". there is lots and lots of info available on this forum on those two terminologies.

 

Now.. i have some questions for you. apart  from the answers for it, it would be nice if you could post your global vi and the source code where you are reading from and writing to the global (FG).

 

I understand that following from your description:

 

1. You have a FG vi, with .. Get/Set option and ..?  what is the data type you have in the FG? Is it a number/array of numbers/waveforms?

2. You write data into the FG at three different locations. Are the three instances running in parallel or series?

3. You write data every second in three instances. Are all the instances updating data at the same rate?

4. You read data every minute. So, why do you write so fast and read so slow? Did you try writing every minute and reading every minute?

 

5. You say you write three samples of data from three instances. Please give us an example of data written and that read.

6. How are you displaying the data read from the Global vi? You said the executable mode does not read any data from the global. So, are you displaying the data on the GUI or something?

 

Again, showing the code would be more helpful. Atleast post the block diagram images

 

 

Regards
Freelance_LV
TestAutomation Consultant
0 Kudos
Message 2 of 10
(2,421 Views)

One thing I can't get is, do you have 3 executables or is it only one executable ? 

0 Kudos
Message 3 of 10
(2,411 Views)

First, let me try to answer the questions the two responders posed...  We have three large vi's that are already written, three vi's that collect three different groups of data from three different pieces of hardware.  The data from each of the vi's will be one dimensional arrays of numbers (non-integer).  We don't want to rewrite the vi's but we can drop something relatively simple into each of the three large vi's to GET the data from each of the three vi's, each of which will be running at about once every few seconds...  All three pieces of code will be running on their own so in parallel to answer another of your questions.  Each of the three pieces of code currently can run and update once every few seconds and when all three are running on one machine that will likely slow down somewhat but all we care about is that the values in all three can update at least once per minute...  We haven't tested whether that will be an issue with all three codes running in parallel on one machine but we think that will likely work ok...  You asked why we take data at a higher rate than we read it...  All we really care about is that each of the three codes takes data and makes that new data available once per minute to be consolidated all into one place by the GET data vi...  The entire purpose of doing all this is to be able to make all the data from all three main data collection vi's available at one place once per minute so we can put all three 1-D array numerical data outputs along with a time stamp into a single output spreadsheet...  Previous experiments had all three codes running on three different machines and then later someone sat down and brought all the data together by hand...  We want to automate that data consolidation task.  We want to drop a small Functional Global into each of the three main data collection vi's.  The Functional Global in each vi will be configured to SET data into each of three shift registers, one for each of the three main vi's.  Then elsewhere, running on the same machine will be a fourth instance of the Functional Global configured in the GET mode such that the data stored in each of the three shift registers can now be output.  That output data can then be combined (not shown here) along with a time stamp into a spreadsheet that will update periodically...  

 

Find attached five very simple vi's...  One is the Functional Global itself called "MyTest Functional Global.vi".  Then find four other vi's called "Data1 Test.vi", "Data2 Test.vi", "Data3 Test.vi" and "Data Output Test.vi"...  See where I am just faking some meaningless data by using the while loop counter to make up 2 numbers and forming them into a 1-D array to input to the Functional Global for each of the Data1, Data2 and Data3 Test vi's...  The Functional Global has three shift registers, one for each of the three vi's that feed data into that global...  And see where I have set the Mode switch on each vi to SET data from Data1 for the Data1 Test.vi, Data2 for the Data2 vi and so forth...  And then see where I have the Mode switch set to Get All Data (get all three paths and dump them out into three 1-D arrays to be combined later with a time stamp (that combination and time stamp is not coded in these vi's)...  

 

Note, these vi's are written in LabVIEW 2011.  So open "Data1 Test.vi", "Data2 Test.vi", "Data3 Test.vi" and "Data Output Test.vi".  Click the run arrow on each one in any order you wish.  I have set the first three Datax vi's to run at once per second and "Data Ouput Test.vi" is set to run at once per 10 seconds...  When really deployed that 10 seconds will be more like 60 but this is just a demo and I don't want you to have to wait all day...  

 

You will see how the Functional Global works as expected (at least by me) as data can be seen in the output indicators on the front panel of each of the four vi's updating as expected...  

 

However, when I take these same four vi's and convert them in to four executables, each instance of the compiled functional global is NOT seeing the data.  Simply stated, when compiled what you will see here at the source level does NOT work.  My question is why....????  

 

Anyway, rather than saying more, if you're interested in helping out, download the five very simple lv2011 vi's attached (four top level and one, the functional global itself, that is contained within each of the four top level vi's)...  Run the four top levels, watch what happens and then ask me more questions, noting that when I build these four into exe's, the data does NOT communicate as it does when running from source...  

 

thanks...  bob...  see 3 attachments here as I see you can only attach three attachments at one time...  I will then try to attach the other two in a subsequent post if it will let me...  If not, you can still learn most of what is needed from the three I've posted here...

0 Kudos
Message 4 of 10
(2,392 Views)

And here are the other two vi's I couldn't attach to the previous post...  thanks.. bob....

Download All
0 Kudos
Message 5 of 10
(2,391 Views)

Each executable has it's own application instance. Global data (fgv, global, etc) are local to the application instance. To communicate between application instances you need to use something like network shared variables.

=====================
LabVIEW 2012


0 Kudos
Message 6 of 10
(2,388 Views)

I was afraid you might say that but that makes perfect sense...  thanks for the help...  bob...

0 Kudos
Message 7 of 10
(2,377 Views)
Solution
Accepted by topic author paris1_

Why do you need 4 executables ?

 

You could launch each vi dynamically from the main vi, and then they will run independent, but still be able to use the FG. 

0 Kudos
Message 8 of 10
(2,366 Views)

well...

 

 

i have exactly the same feedback. when run as different executables, each FG belongs to a different environment.

 

when called from source code, the FGs and the vis belong to one environment - LabVIEW Developmnet Environment.

 

That is why you could not get them to work as you want.

 

i can make two suggestions: Make one VI, call each vi Data1, Data 2, etc using dynamic ref or as sub vis running in parallel. then use your FG to Get Data.

 

Or, you can obtain a Queue with name 'DATA' in all the four vis, enqueue data in the first three and dequeue it in the fourth EXE. Ensure that when you 'Obtain' a queue in four different places, use the same Queue Name and Queue data type.

 

 

Regards
Freelance_LV
TestAutomation Consultant
0 Kudos
Message 9 of 10
(2,343 Views)

thanks guys...  both of the last two posters had the idea that worked, to call the other three vi's dynamically from within the fourth.  When I made that fourth vi into an executable it worked as desired...  thanks... I gave the "accept as solution" to the first of the two of you..  Seemed the only fair way to do that...  thanks...  bob...

0 Kudos
Message 10 of 10
(2,317 Views)