How to optimize this labview fpga vi??

[nathand]

If you do not need to acquire an image until after the trigger occurs, then why do you need the vision acquisition to run continuously?

It would be easier to wait for the trigger to occur, acquire one image, process it, and write the value to the FPGA.

Your current code does not show that you are waiting for a trigger, it only shows continuous acquisition of a value from the FPGA.

[mangood]

---

@nathand wrote:

If you do not need to acquire an image until after the trigger occurs, then why do you need the vision acquisition to run continuously?

Your current code does not show that you are waiting for a trigger, it only shows continuous acquisition of a value from the FPGA.

---

dear::

"""It would be easier to wait for the trigger to occur, acquire one image, process it, and write the value to the FPGA.""

this is exacly  what i want

one image for each trig

i change the vi

please check it if you' can

i add second loop so the system stop until another trig come

best reagrds

[nathand]

That looks approximately right, but you'll have to test it when you have the hardware available. You do not need the sequence structure and the inner while loop around it. Also, it is a good idea to have a wait (even 0ms) inside a loop like the one that's looking for the trigger so that other tasks can run; otherwise that loop will run as fast as possible, keeping your computer busy unnecessarily. An even better solution would be to handle the trigger on the FPGA, and when the trigger condition occurs, set an interrupt or put a value into a DMA FIFO. That was the host side can simply wait until the FPGA indicates that the trigger occurred.

[mangood]

---

@nathand wrote:

That looks approximately right, but you'll have to test it when you have the hardware available. You do not need the sequence structure and the inner while loop around it. Also, it is a good idea to have a wait (even 0ms) inside a loop like the one that's looking for the trigger so that other tasks can run; otherwise that loop will run as fast as possible, keeping your computer busy unnecessarily. An even better solution would be to handle the trigger on the FPGA, and when the trigger condition occurs, set an interrupt or put a value into a DMA FIFO. That was the host side can simply wait until the FPGA indicates that the trigger occurred.

---

dear nathand :
""An even better solution would be to handle the trigger on the FPGA, and when the trigger condition occurs, set an interrupt or put a value into a DMA FIFO. That was the host side can simply wait until the FPGA indicates that the trigger occurred"".

 is this  what you  mean????
http://zone.ni.com/reference/en-XX/help/371599H-01/lvfpgahosthelp/synchronizing_using_interrupts/

This thing  probably hard for me to do
i never use this method before

also i send to you private message for ni event

best regards

---------------------------------------------------------

---

[mangood]

HIIIIIII

I search for some in ni and find  amazing toturial for intrrupt

but what is the advatage of the loop timer in fpga vi side????

is the sampling rate or what

best regards

[nathand]

---

@mangood wrote:

but is the advatage of the loop timer in fpga vi side????

---

I don't quite understand the question. Did you mean to ask, "What is the advantage of putting the loop timer in the FPGA VI?"
Since the host has to wait for data from the FPGA, putting the timer on the FPGA means only one timer is necessary to set the loop rate on both the host and FPGA.

[mangood]

---

@nathand wrote:

---

---

I don't quite understand the question. Did you mean to ask, "What is the advantage of putting the loop timer in the FPGA VI?"
Since the host has to wait for data from the FPGA, putting the timer on the FPGA means only one timer is necessary to set the loop rate on both the host and FPGA.

---

yes this is what i mean
for privous figure you can see that the lllop rate with constant=1000 ms

is this mean the rate or frequency of system will be 1 HZ??

[nathand]

That's right. The FPGA will wait 1000ms (1 second), then read a new value from an analog input and write a new value to an analog output. It then sets the IRQ to indicate that a new reading is available. The host reads the new value (from a front-panel control), does a calculation, writes the result of the computation to a control, and clears the IRQ to indicate to the FPGA that it finished processing. The next second the process repeats.

[mangood]

---

@nathand wrote:

That's right. The FPGA will wait 1000ms (1 second), then read a new value from an analog input and write a new value to an analog output. It then sets the IRQ to indicate that a new reading is available. The host reads the new value (from a front-panel control), does a calculation, writes the result of the computation to a control, and clears the IRQ to indicate to the FPGA that it finished processing. The next second the process repeats.

---

yes

the total delay in this case as my small experince  will be=

1000ms (the loop timer) +max(delay of read of anloge input,,,,dealy of write to analoge output)) because both work in parralell+ delay during host reads the new value+ delay of((((does a calculation, writes the result of the computation to a control, and clears the IRQ to indicate to the FPGA that it finished processing.)))

this total dealy right!!!!

best reagrds

[nathand]

No, because the loop timer is a timer, not a wait function. It waits until 1000ms have elapsed since the previous time it ran. It does not wait 1000ms every time. If it takes 900ms to read and write the IO and do the calculation, the loop timer will wait only 100ms in order to maintain the 1hz loop rate. The only time this does not work is if the IO and calculations take more than 1000ms, in which case the loop timer has no effect.