07-16-2014 12:09 PM
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
07-16-2014 01:48 PM
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.
07-16-2014 02:13 PM
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 ?
07-16-2014 02:31 PM
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.
07-16-2014 02:48 PM
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
07-16-2014 02:52 PM
@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.
07-16-2014 02:55 PM
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.
07-16-2014 03:27 PM
@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.
07-16-2014 03:41 PM
@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:
07-16-2014 04:03 PM