LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I control concurrency in my VI?

Solved!
Go to solution

labview_concurrency.png

 

Let's look at "time".

 

time is assigned a time string from "Format from String" VI.

Its value is given to another "Format from String" VI with the format string "where r_time=%s".

 

Since two "Format from String" VIs are executed concurrently, time's value is given to the second "Format from String" VI before time is assigned from the first one.

 

It leads to a resultant string "where r_time=" that is assigned to a "DB Tools Select Data" VI from the second "Format from String" VI.

 

How can I have time assigned a proper value before it is used?

0 Kudos
Message 1 of 26
(3,256 Views)
Get rid of those stupid local variables.
Message 2 of 26
(3,250 Views)

Why some people say Local Variables are bad...

 

Read that in its entirety before ever using a local variable again.

0 Kudos
Message 3 of 26
(3,245 Views)

How do I remove those stupid local variables and still not mess with wires?

 

Without the "table" local variable, I'll see a spaghetti code.

0 Kudos
Message 4 of 26
(3,238 Views)

Wires can branch.  Delete the local variable and wire from the wire going into the terminal to the broken wire you just created.

 

I would recommend looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours

0 Kudos
Message 5 of 26
(3,235 Views)

What the Knights are trying to say:

 

Those local variables are causing multiple "race conditions" the terminals and (read) locals are read once per iteration when the data is available- it might be data that you wanted to overwrite before you read it- but since LabVIEW doesn't even try to guess the order of operations you thought you meant (Dataflow) it is old data on a "next" operation.  Local and Global variables DO have uses, BUT, you MUST be careful with their use.

 

Check out the Community Nugget on Action Engines

 

Its only the top Kudoed post on the LabVIEW Forum of all time.  (You are not the first to get bit by a race condition)


"Should be" isn't "Is" -Jay
Message 6 of 26
(3,232 Views)

@Ravens Fan wrote:

Wires can branch.  Delete the local variable and wire from the wire going into the terminal to the broken wire you just created.

 

I would recommend looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours


I know that wires can branch, and I already have branched wires.

Brahching doesn't solve the spaghetti code problem.

0 Kudos
Message 7 of 26
(3,226 Views)

It would solve your race condition problem.

 

I don't see where you have a spaghetti code problem.  Eliminating local variables, straightening wire runs, and sorting things out so wires don't run backwards will make the code look better.

0 Kudos
Message 8 of 26
(3,222 Views)
It will be spaghetti only if you let it. Take a little time to do it right. Or, be a bit lazy and use the block diagram cleanup feature. Don't be totally lazy and use a local instead of a wire.

Local variables are one of those features that should only be available to programmers that have some experience.
0 Kudos
Message 9 of 26
(3,221 Views)

@Ravens Fan wrote:

It would solve your race condition problem.

 

I don't see where you have a spaghetti code problem.  Eliminating local variables, straightening wire runs, and sorting things out so wires don't run backwards will make the code look better.


The screenshot of my code reminds me of sparse spaghetti.

If I add a few more wires crossing over other wires perpendicularly, others will have difficulty reading my code.

 

Here's how I modified the code to remove as many local variables as possible.

 

labview_code.png

 

 

If the code looks readable to you, point one for you.

0 Kudos
Message 10 of 26
(3,217 Views)