Fast acquisition with DAQ

[GerdW]

Hi George,

---

@GeorgeMartin wrote:

I doubt that my company will accept to buy a different licence from the one we already paid, in order to get running an example that might not help at all with the problem that I have.

---

Then you need to replace all those "advanced" functions (subVIs) with your own replacement VIs to get the example VI into an executable state. (Take into account the time you need to do this work and your hourly wage, then recalculate the costs for the different license.)

Or you just use this example VI as is: an example.

Create your own routines fro scratch (and the knowledge you got from looking at the example) without using any advanced features, but with all the requested features.

[GeorgeMartin]

---

Create your own routines fro scratch (and the knowledge you got from looking at the example) without using any advanced features, but with all the requested features.

---

That's exactly what I did, hard way - the good way, I wrote from scratch, using tutorials, NI documentation (link) and dozens of forum replies (mostly concerning the "time / timer-ed" functions in my code).

Then I got stuck with a problem (the triggering at each loop), and now the whole focus of your replies are around running an example that I believe will not help me since I believe (as I said many messages ago) the proposed example is not triggering at all.

@GerdW I believe there might be some sort of misunderstanding, I have "no interest" on running this example, running it won't fix "my problem" with my done-from-scratch code.

[GerdW]

Hi George,

---

@GeorgeMartin wrote:

@GerdW I believe there might be some sort of misunderstanding, I have "no interest" on running this example, running it won't fix "my problem" with my done-from-scratch code.

---

Oh sorry, I thought your "any idea" question was because of your license problem with the example VI…

On your VI:

You really should cleanup the VI even more!

Example:

I prefer Select nodes over case structures with just some simple code within…

Question:

Why do you stop the DAQmx task in each iteration without creating a new task in the next iteration?

For me this "stop the task, create a new one conditionally, get data, stop again" doesn't look right…

[GeorgeMartin]

I'll take a look to select nodes

---

@GerdW :

Question:

Why do you stop the DAQmx task in each iteration without creating a new task in the next iteration?

For me this "stop the task, create a new one conditionally, get data, stop again" doesn't look right…

---

probably wrongfully, but in my logic the Task existed, and will continue to exist outside LV because it was created in NI MAX, I'm just eventually modifying it.

I haven't tried creating a new task, but I did tried creating a new channel, so using no available NI MAX tasks... just like in NI documentation (link)

and the behavior was the same, only triggering on the first loop.

[GerdW]

Hi George,

---

@GeorgeMartin wrote:
in my logic the Task existed, and will continue to exist outside LV because it was created in NI MAX, I'm just eventually modifying it.

---

The task doesn't "exist" in MAX, it is "defined" in MAX. There's a subtle difference between "defined" and "exist"…

The DAQmx task exists (aka "runs") once you start it!

---

@GeorgeMartin wrote:

I haven't tried creating a new task, but I did tried creating a new channel, so using no available NI MAX tasks... just like in NI documentation (link)

and the behavior was the same, only triggering on the first loop.

---

In your VI you explicitely STOP the task before you go to the next iteration. There will be no "next triggering" for a stopped task!

[GeorgeMartin]

I will plug the test bench again on monday, but  from memory

If I put the STOP outside the while, it doesn't work. it only triggers on 1st iteration, then completely random.

if I put it inside, it does triggers every time, but loop time is humongous (I suppose because task is being stopped every loop

[GeorgeMartin · Accepted solution]

I just found on this THREAD a VERY interesting NI article

---

Non X Series with no available counters: If you are not using an NI 63xx Multifunction I/O (X Series) DAQ board, analog input is not inherently retriggerable. However; you can retrigger a board by starting and stopping the DAQmx task each time a trigger is received. This will reconfigure the settings on the card and therefore re-arms the analog hardware trigger. This method, however, introduces significant hardware delays and...

---

but since it seems I have an X series, This might be the key to what I'm looking for

Next episode on Monday

[GeorgeMartin]

Just for information in case someone else is looking for this. The DAQmx Trigger node with the property "Start.Retriggerable" works perfectly.
So node inside the first loop, and Stop task outside the loop. This only works if your hardware has this capability... for more info read the article I linked in the solution.