LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

global variable not updating in main vi

A global variable is not available to other applications, only available to other parts of your application.

 

You can still use globals with my suggestion or johnsold's example - simply write the values to both your top level VI's indicators and the globals at the same time, rather than writing to global in the subVI's and then having your top level VI read from the globals to populate its indicators.



Message 21 of 27
(1,223 Views)

Queues are often used to move data across parallel loops.

 

Reducing the timeout will only have an effect if the DS reads are actually timing out. If they are timing out, then you do not have any data.  I have not used those functions but they probably return default values (likely zero) on a timeout.

 

You need to find out what is actually happening before you try to fix it.

 

Lynn

0 Kudos
Message 22 of 27
(1,219 Views)

@ashnu wrote:

If I reduce that timeout seconds, will tat help in updating? 


Only if that was causing you any issues.  I do not know of the source of your data (the source that is populating your DataSockets with data that you are reading here).  If that source is only updating them every 5 seconds, for instance, then you will be waiting 5 seconds each time; your default timeout of 10000 ms allows it to wait for up to 10 seconds before returning.  What you can do is use a much shorter timeout and then check the "timed out" output to determine if you should use the output from the DataSocket Read or not.



0 Kudos
Message 23 of 27
(1,218 Views)

Ok thanks a lot for your patience... I'll will think and implement all your inputs and get back tomorrow... 

Before that is it possible to tell now, what is wrong with my MAIN.vi? Is it the loop that is creating the problem or the global variable is not supporting? 

0 Kudos
Message 24 of 27
(1,210 Views)

Beyond the nested while loops (one in a subVI) that have already been mentioned, we really cannot tell where the problem is.

 

You may have race conditions but they would not keep the program from running - just produce strange results. If the remote device is not updating the DataSocket we cannot tell from the program. Only you have the hardware to test that.  I suggest you put indicators on each of the outputs of the DS Read (timed out, error out) and watch to see what might be happening. Also wire an indicator to the "i" terminal in the main while loop.  That will show whether the loop is iterating and how fast.

 

Lynn

 

 

0 Kudos
Message 25 of 27
(1,169 Views)

We keep bringing up the race conditions.  But, I don't see why exactly.  Yes, they exist.  Yes, they're a habit you want to break... NOW.

 

They wouldn't prevent the indicators from updating.  Whether the global is read before or after the subVI's execution doesn't change that it is read.  If it's always read before, it'll post the value from the last iteration.  If it's always read after, it'll post the value of the current iteration.  If it's sometimes read before and sometimes after, it'll eventually post a value that's different.

 

The global variables are definitely a poor choice.  If nothing else, this is true based on the stated reason for using them.  The idea that you can use the variables in other applications simply isn't true in any programming language I've worked with.  Making them global means they're accessible to the entire program rather than accessible locally to a function.  That never means "any other program can use these."  I'm not sure why you'd think that would be true in this case.  It really doesn't make sense.  There are mechanisms in place with LabVIEW, like other languages, where you can use external variables within an application.  But, I'm not even sure that makes sense with what you've given us for this application so far.  It's likely it'd make more sense to remove some of the complexity of the application and then you'll find you don't need to create this mess you're making now.

 

As of right now, you're making several mistakes in both architecture and dataflow.  Instead of pushing forward, you should consider taking a break from the application.  You're not helping yourself by getting into bad habits.  You'll eventually have to break those.  Take some time to learn the language.  Follow the tutorials RavensFan linked you to.  Help yourself avoid the simple mistakes and learn to use the tools to help debug the complex mistakes.

0 Kudos
Message 26 of 27
(1,157 Views)

Here are some links for getting started with LabVIEW 😉

 

Learn LabVIEW - National Instruments
http://www.ni.com/academic/students/learn-labview/

 

And if you need to communicate between several VIs you should check the opportunities of Functional Global Variables out!

Functional global variable - LabVIEW Wiki
http://labviewwiki.org/Functional_global_variable

0 Kudos
Message 27 of 27
(1,139 Views)