LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using Globals

I have written a sub VI to read a serial port comm (GPS unit) and I am using Globals to read those GPS values generated from that sub  VI into my main VI.  I am doing this to make sure that the time it takes to get a new value from the GPS unit doesn't slow up the rest of my processing...... I simply reach in and grab the latest value when I need it.

 

This works perfectly however, when I close out my main program I close out the serial comm VI first through a global variable.  This takes about 60-90 seconds to do and can't determine why it takes so long.  I have checked out my main program and have checked out the serial comm VI and can't figure out why.

 

Any suggestions?

0 Kudos
Message 1 of 22
(3,411 Views)

Aside from the general comments that you will undoubtedly receive about globals being evil and all that nonsense, how exactly are you "closing out" the main program? It sounds like you are dealing with a VISA Read timeout issue.

 

Can you post some code? While globals may not be evil, perhaps your code is, which may bring some measure of satisfaction to the global variable haters.Smiley Very Happy

Message Edited by smercurio_fc on 11-17-2009 09:08 AM
Message 2 of 22
(3,404 Views)

irfocus wrote:

I have written a sub VI to read a serial port comm (GPS unit) and I am using Globals to read those GPS values generated from that sub  VI into my main VI.  I am doing this to make sure that the time it takes to get a new value from the GPS unit doesn't slow up the rest of my processing...... I simply reach in and grab the latest value when I need it.

 

This works perfectly however, when I close out my main program I close out the serial comm VI first through a global variable.  This takes about 60-90 seconds to do and can't determine why it takes so long.  I have checked out my main program and have checked out the serial comm VI and can't figure out why.

 

Any suggestions?


Re: the delay in shutdown

 

What is the timeout on your serial reads set for?

 

Re: Globals

 

I wrote this Nugget on Action Engines to share a method of sharing data between threads without the risk of Race Conditions associated with Globals. You may want to review that thread.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 3 of 22
(3,401 Views)
Read up on Action Engines (what Ben posted).  They are easy to impliment and have a lot of advantages over global variables (I'm not sure there are any disadvantages).  After learning about them, I think I have used the AE design pattern in every major project.
Message 4 of 22
(3,383 Views)

Nickerbocker wrote:
Read up on Action Engines (what Ben posted).  They are easy to impliment and have a lot of advantages over global variables (I'm not sure there are any disadvantages).  After learning about them, I think I have used the AE design pattern in every major project.

Disadvantage of an Action Engine (off the top of my head)

 

1) They can be a bottle-neck. If one of the Action takes too long this could inhibit other callers. Skip If Busy let us work-around that issue.

 

2) Strongly coupled to the application. All but the most general type of AE can be difficult to port to another app (LVOOP is an AE turned inside out so it get around this issue)

 

Just trying to hlp,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 5 of 22
(3,381 Views)

Ben wrote:

Nickerbocker wrote:
Read up on Action Engines (what Ben posted).  They are easy to impliment and have a lot of advantages over global variables (I'm not sure there are any disadvantages).  After learning about them, I think I have used the AE design pattern in every major project.

Disadvantage of an Action Engine (off the top of my head)

 

1) They can be a bottle-neck. If one of the Action takes too long this could inhibit other callers. Skip If Busy let us work-around that issue.

 

2) Strongly coupled to the application. All but the most general type of AE can be difficult to port to another app (LVOOP is an AE turned inside out so it get around this issue)

 

Just trying to hlp,

 

Ben


#1 I see as an advantage in most situations.  Although I guess I could think of situations where you want an AE to perform a function that may take some time (like dumping its data set to disk) where as in another thread you just want to read a value.  Performance issues haven't come up for me, as my AEs have been simple.  Of course a designer could delegate said save subroutine (through a queue or notified or something) to another VI, throwing it into another thread, and return to a wait state.  So there are work around...

 

#2 is absolutely true.  I've yet to make an AE that I could use in another project because my AEs revolve around the data structure that is needed for the project.  However, Global Variables have the same disadvantage....

 

I still don't see how Global Variables have any advantages over AEs.  If #1 ever came up I think I'd work around it rather than abandon AE for a GV.

0 Kudos
Message 6 of 22
(3,353 Views)

As has been mentioned, the problem is probably not due to you trying to close the serial port with a global, so an action engine will probably not help.

 

There is probably something else in the code staying open.

 

An easy was to debug this would be to put a breakpoint on the actual VISA close node. If you see the delay after stepping into the close node the problem is not to do with globals.

0 Kudos
Message 7 of 22
(3,346 Views)

Here is a sample of what I did.  It is not exact but it illustrates it and the global VI and the GPS.VI is pretty close.  I did notice that this does not take nearly as long as my overall program but there is a delay.

 

I use the Global because the time it takes to get a value from the GPS stream screws up my program if I have to wait for it.  Since I only need a new value every few seconds, this works very well.  If I could only figure out why it takes so long to shut it down.

 

Gary

Download All
0 Kudos
Message 8 of 22
(3,343 Views)

I think as others have mentioned that your issue is with the VISA Read Timeout. Once you hit that part of your code you will wait there until your read either completes or timeouts. If you have a long timeout period this will delay your closing the port.

 

I would also highly recommend that you consider changing the architecture of your code. Stacked sequences are not a very good design pattern. I would recommend you consider using a state machine. In addition there is no need to use the global variables. You can change your code to use a shift register and simply wire your data through the while loop. Bundle all of your GPS data into a cluster and simply pass that wire through your code.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 9 of 22
(3,337 Views)

I agree with Mark that a state machine is something you should consider.

 

If delays in getting data from the GPS disrupt other things the program is doing, consider two parallel loops - one for the GPS acquisition and the other for the processing.  The Producer/Consumer Design Pattern which ships with LV shows one good way to do this.

 

Lynn 

0 Kudos
Message 10 of 22
(3,330 Views)