Problem with a change detection in a loop

[grega]

Hey,

I have a NI-9423 module in a cDAQ chassis (besides other modules), and it is used for change detection for an input bit. This is a busy bit coming from a motor controlled via a digital IO. I want to enqueu a certain task when the busy bit goes from low to high and some other task when it goes from high to low.

The problem is that my whole VI stands still and waits for the detection, because the error is not passed through.

Also if I put a -1 to the timeout, then of course everything hangs, since the read VI waits indefinitely for the change.

So basically all I need to do is detect an edge change and put a proper task into the queue.

Any help, thanks...

[grega]

I forgot...here are the VIs

[BillMe · Accepted solution]

You need to move the "Start input trigger" and associated logic (enqueue) into a separate loop. This will allow the upper logic to run on its own while you wait for a start trigger.

[grega]

Ok, the loop now works. However I still have some issues.

If I want to be ready to capture signals, I have to set the read timeout for the edge detect part to infinity. Doing so I always get stuck. I also don't want for my VI to wait for any kind of timeout before it totally finishes. So what would be the best practice?

And how "fast" does this edge detect work? If I have a signal that changes let's say in half of a second or a little bit sooner, will the module detect it and read the sample?

Thanks...

[nathand]

---

@grega wrote:

If I want to be ready to capture signals, I have to set the read timeout for the edge detect part to infinity. Doing so I always get stuck. I also don't want for my VI to wait for any kind of timeout before it totally finishes. So what would be the best practice?

---

Can you clarify "get stuck" and "wait for any kind of timeout before it totally finishes"?  I'm not sure what you mean by either of these statements.  You can set the timeout to -1 to wait forever, and if you need the task to stop before the edge occurs, stop or clear the task.  That will cause the DAQmx Read to stop waiting and return an error.  With the DAQmx Read in its own independent loop, you can set the timeout to -1 without causing the rest of your code to wait.

---

@grega wrote:

And how "fast" does this edge detect work? If I have a signal that changes let's say in half of a second or a little bit sooner, will the module detect it and read the sample?

---

Again, please clarify.  Are you asking how long it takes to set up the task before it starts detecting, or are you asking how long a pulse needs to be in order to be detected as an edge?  Half a second or sooner than what - the start of the task, or the previous edge?  In either case you're probably fine, although I'm not certain exactly how much setup time is required to set up the task.

[grega]

Sso to avoid waiting for read to finish, all I need to do is clear the task.

About the other thing - I was wondering how much time can pass between an edge change if I want to detect both falling and rising edge (is it mseconds or useconds). OK I know that I have to take into consideration the code that is being run. But purely from a hardware point of view...

[grega]

---

@nathand wrote:

Can you clarify "get stuck" and "wait for any kind of timeout before it totally finishes"?  I'm not sure what you mean by either of these statements.  You can set the timeout to -1 to wait forever, and if you need the task to stop before the edge occurs, stop or clear the task.  That will cause the DAQmx Read to stop waiting and return an error.  With the DAQmx Read in its own independent loop, you can set the timeout to -1 without causing the rest of your code to wait.

Hm, and how can I stop my task in other loop other than with local variables? Because if I put a clear task in the upper loop's **bleep**down case, the whole loop waits for the response?

[nathand]

According to the specifications for the 9423, it is capable of measuring at up to 1us, so any pulse longer than that should register as a rising edge and a falling edge.

---

@grega wrote:

Hm, and how can I stop my task in other loop other than with local variables? Because if I put a clear task in the upper loop's shutdown case, the whole loop waits for the response?

---

Create the Change Detection task outside the bottom loop, then fork the task wire to the upper loop.  Don't clear the task inside the loop (you probably don't even need to stop it).  In general it's inefficient to create and destroy a task in a loop - do the setup once before the loop starts and clean up when the loop exits, so that the task's resources stay reserved through multiple loop iterations.  Not sure what you mean by "whole loop waits for the response" - response from what?

[grega]

---

@nathand wrote:

Create the Change Detection task outside the bottom loop, then fork the task wire to the upper loop.  Don't clear the task inside the loop (you probably don't even need to stop it).  In general it's inefficient to create and destroy a task in a loop - do the setup once before the loop starts and clean up when the loop exits, so that the task's resources stay reserved through multiple loop iterations.  Not sure what you mean by "whole loop waits for the response" - response from what?

I tried, but the stop task still waits for the read to finish.

Kind Regards

[nathand]

Try using just Clear Task with no Stop Task first.