LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

will parrallel loops running in my real time code, conflict when they both call my FPGA code?

I have a Real-time vi which has 2 parallel loops;

Loop 1 checks status every 1 ms or so. i.e. writes or reads to the FPGA vi.

Loop 2 receives UDP messages, decodes them and then writes to the same FPGA vi.

 

My questions are;

1) Will I get conflicts if they both talk to the FPGA at the same time, or do the parallel loops automatically have separate threads?

2) If there is a conflict, how does Labview handle it, do they buffer up the calls? or take the first and drop the second?

 

Any help would be appreciated.

 

Thanks

 

0 Kudos
Message 1 of 12
(2,955 Views)

I'm assuming here that you have an FPGA VI running continuously. If so, it will just work. Of course, if you try to update the same control from both loops, you may run into race conditions because you can't guarantee the order in which they update, but as long as the two loops interact with different parts of the FPGA (different controls or FIFOs) there won't be any problem. LabVIEW may run both loops in the same thread, or in different threads, but either way you don't need to worry about it.

0 Kudos
Message 2 of 12
(2,932 Views)

nathand,

 

Thanks for responding.

 

The FPGA vi is running continuously. I have not seen problems in the past, but someone asked whether or not this would be an issue. I was hoping for a difinitive answer,

It's hard to stand up in a meeting and say "it just works".

I don't know if Labview buffers up the calls to the FPGA, or runs each loop in a different thread, or ?

0 Kudos
Message 3 of 12
(2,924 Views)

What I typically do is have one location (VI, Loop, whatever) that sends data down to the FPGA.  This almost always with a DMA.  I very rarely use front panel interfaces from the FPGA.  So I use a queue to send the commands to this one loop that then takes the data in the queue and shoves it down the DMA to the FPGA.

 

I then have a single loop that does nothing but read from the FPGA, again almost always a DMA.  So it reads the DMA and passes the data on to whoever needs it via a queue.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 12
(2,913 Views)

 

crossrulz,

 

I'm not using DMA becuase there is very little data transfer, mostly sending a handul of bytes to hardware and hitting a "go" button. (though DMA transfers have worked well for past projects)

 

I would prefer to keep the two loops separate, for housekeeping purposes, not to mention that one loop is a timed loop.

 

It just seams like Nationa Instruments must have documentation on whether 2 parallel loops run in different threads or how they handle it.

 

Thanks

0 Kudos
Message 5 of 12
(2,908 Views)

@go_sox wrote:

 

crossrulz,

 

I'm not using DMA becuase there is very little data transfer, mostly sending a handul of bytes to hardware and hitting a "go" button. (though DMA transfers have worked well for past projects)

 

I would prefer to keep the two loops separate, for housekeeping purposes, not to mention that one loop is a timed loop.

 

It just seams like Nationa Instruments must have documentation on whether 2 parallel loops run in different threads or how they handle it.

 

Thanks


That should work fine.  I'm used to sending a lot more information than that to the FPGA.  If you are actually writing to the FPGA very little, I don't see an issue.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 12
(2,906 Views)

 

It has worked in the past, I guess I was looking for the bullet proof legal disclaimer that it works because ..... and have NI documentation to back it up.

0 Kudos
Message 7 of 12
(2,902 Views)

@go_sox wrote:

 

It has worked in the past, I guess I was looking for the bullet proof legal disclaimer that it works because ..... and have NI documentation to back it up.


You do, in the sense that what you are trying to do is inherently a feature of the language. You would never ask, "can I write to front panel terminals on the user interface in two different loops, or will they conflict?", right? Because it's inherent in the language that it will work. Why should it be any different for front panel items on the FPGA, allowing that the mechanism for writing to them is slightly different? Same goes for all sorts of other resources that could be shared between multiple loops.

0 Kudos
Message 8 of 12
(2,898 Views)

@go_sox wrote:
 

It just seams like Nationa Instruments must have documentation on whether 2 parallel loops run in different threads or how they handle it.


Threads don't matter. That's one of the amazing things about LabVIEW - you don't need to know how many threads are being used to handle your code. The number of threads doesn't map directly to the number of loops. You could have parts of the same loop executing in two different threads, if the contents of the loop can be parallelized; conversely, if there aren't enough threads available, LabVIEW may handle two parallel loops in the same thread, alternating execution between them (at a finer resolution than loop iterations - it might complete part of one loop, then part of the other, back to the first, etc).

 

That said, if you are curious about the internals, you can find some details by searching the LabVIEW help and the NI site. The basics are that by default LabVIEW allocates 4 threads per processor core per execution subsystem, the user interface is special, and timed loops run in a single thread. As a starting point see these resources:

How Many Threads Does LabVIEW Allocate?

Multicore Programming Fundamentals

0 Kudos
Message 9 of 12
(2,895 Views)
Both will get processed, wichever gets there first wins. If a lower priority loop gets there and forces a higher priority loop to wait it will cause priority inversion but that is probably not an issue for you. FP nodes are very fast and on many situations out perform dma. I have fpga projects where I have switched to FP terms. in place of dma and seen performance improve. It depends very much on the rt system in use as they work different under the hood. I also have had applications where I put all fpga io in a single loop and other apps where I put the io mode where I need it. Both work fine and it is down to tje programmer to decide. In short what you are doing is fine.
0 Kudos
Message 10 of 12
(2,890 Views)