Can no longer push buttons while code is running

[Baphelon]

I recently took out a series of placeholder values I had in my code and replaced them with tasks and DAQ Assistants. With this update I can no longer hit any buttons or even right click until the portion of the code containing these calls is finished running. It's not completely frozen as it does execute normally aside from this. Sadly I can't provide any code or screenshots, so please let me know if there's any I've left unclear, or if you'd like me to give other information about it that may be relevant. Thanks!

[altenbach]

1. See if there are any event structures that lock the front panel until the event completes (default setting). (If the event structure is after the DAQ stuff, but you have an event for e.g. a " DAQ start" button, for example, you would see that.)
2. Do you have any DLLs that are configured to run in the UI thread?
3. Do you have any unusual priority settings? (high priorities starve the UI to focus more on computations).
4. Do you have any greedy loops?
5. Make sure that the UI is decoupled from the hardware interactions, i.e. in its own loop. What is you overall code architecture?
6. Of course there are plenty of other possibilities, but since you are not showing us anything, we are stabbing in the dark.

[Jewsus]

Are you using ques in your code? I know that if youre using ques and you click a button (which adds the next que), then click it again before the que finishes.... it also locks you out and you have to manually exit via STOP sign button.

I would also be curious to see if others could explain this phenomenon.

[Baphelon]

---

@altenbach wrote:

1. See if there are any event structures that lock the front panel until the event completes (default setting). (If the event structure is after the DAQ stuff, but you have an event for e.g. a " DAQ start" button, for example, you would see that.)
2. Do you have any DLLs that are configured to run in the UI thread?
3. Do you have any unusual priority settings? (high priorities starve the UI to focus more on computations).
4. Do you have any greedy loops?
5. Make sure that the UI is decoupled from the hardware interactions, i.e. in its own loop. What is you overall code architecture?
6. Of course there are plenty of other possibilities, but since you are not showing us anything, we are stabbing in the dark.

---

of the 5 options, I'd say #4 is the most likely, I've got a data acquisition loop that records 5 channels at rates between 10Hz and 10kHz (user picks) for about 10 seconds. This is what I originally suspected, but if this is the issue, I'm not sure what to do about it

[altenbach]

Use continuous hardware timed acquisition and read out the buffer at leisure. Look at the examples.

[Baphelon]

---

@altenbach wrote:

Use continuous hardware timed acquisition and read out the buffer at leisure. Look at the examples.

---

This sounds like exactly what I need, can't find any examples of it though. If you could name one that'd be a great help!

[crossrulz · Accepted solution]

---

@Baphelon wrote:

---

@altenbach wrote:

Use continuous hardware timed acquisition and read out the buffer at leisure. Look at the examples.

---

This sounds like exactly what I need, can't find any examples of it though. If you could name one that'd be a great help!

---

Help->Find Examples.  Search for Hardware Input and Output->DAQmx->Analog Input->Voltage - Continuous Input.vi.

[billko]

---

@Jewsus wrote:

Are you using ques in your code? I know that if youre using ques and you click a button (which adds the next que), then click it again before the que finishes.... it also locks you out and you have to manually exit via STOP sign button.

I would also be curious to see if others could explain this phenomenon.

---

I've never seen nor heard of that phenom before.  Does all your queue stuff happen withing that event case?  (If so, that's a glaring example of why you should have as little code in the event structure as possible.)

[johntrich1971]

---

@Jewsus wrote:

Are you using ques in your code? I know that if youre using ques and you click a button (which adds the next que), then click it again before the que finishes.... it also locks you out and you have to manually exit via STOP sign button.

I would also be curious to see if others could explain this phenomenon.

---

It would be difficult to know what's going on without seeing your code, but your description makes it sound like it's a problem with the structure of your program. This is not queue behavior - you don't "click a button" to add anything to the queue (what does "adds the next queue" even mean? - Are you adding another queue or adding data to the queue?). 

[Baphelon]

---

@crossrulz wrote:

---

@Baphelon wrote:

---

@altenbach wrote:

Use continuous hardware timed acquisition and read out the buffer at leisure. Look at the examples.

---

This sounds like exactly what I need, can't find any examples of it though. If you could name one that'd be a great help!

---

Help->Find Examples.  Search for Hardware Input and Output->DAQmx->Analog Input->Voltage - Continuous Input.vi.

---

Not only did this solve this problem, it also solved the next question I was gonna post about changing the Hz not actually giving me the correct results! Thanks for all the help!