DI using change detection

[labviewette]

Dear Community,

is it possible to configure the timing of a DI task to detect the change on a counter signal?

[GerdW]

Hi Labviewette,

you can use PFI pins as digital triggers…

Which hardware do you use and what do you want to measure?

[labviewette]

I am using the X-Series PCIe 6363.

I am trying to create a dummy DI task in order to use the change detection event generated there for a DO task.

I have generated a pulse train on a counter line and want to use this line as the source for the rising/falling edge  of the Daqmx-Timing vi for the dummy DI task. I do not have the option to connect PFI lines. I only have the option to connect CTR lines. When doing so I get the error "Lines specified do not support change detection."
When selecting the corresponding digital lines to my PFI line (see image), in my case the P2.4 line, I get the error " Resource requested by this task has already been reserved by a different task."

What am I doing wrong here?

Kind Regards

[GerdW]

Hi labviewette,

error " Resource requested by this task has already been reserved by a different task."

You already defined a task, which uses that pin…

As you don't attach your VI I cannot help much better.

What am I doing wrong here?

You don't attach your VI, which is very wrong when you want help for your coding problem…

I do not have the option to connect PFI lines.

Why don't you have that option?

[labviewette]

What am I doing wrong here?

You don't attach your VI, which is very wrong when you want help for your coding problem…

---

I have attached the code. I didn't think it is that important because the code is the standard  NI example code for finite DI acquisition.

I do not have the option to connect PFI lines.

Why don't you have that option?

---

No PFI lines included in list. Even when i include all sorts of lines in the IO-Names-Filtering option of the physical channel.

[Kevin_Price · Accepted solution]

You will need to do some physical wiring.  X-series boards only support change detection on digital port 0 pins.  None of these pins are internally routed as PFI pins that the counter can output onto directly.

Summary:  you'll generate your pulse (train) out to a PFI pin, physically wire from that pin over to port 0 line x, configure a DI change detection task with port 0 line x in it, then configure a DO task for port 0 lines y-z that uses the change detection event as a sample clock.   Do that right and it oughta work.

-Kevin P

[labviewette]

Thank you for replying Kevin P

Although the question is solved I still need to understand something:

If in the case of the X-series no pins are internally routed as PFI pins then why is there the option to configure the change detection pin with a CTR signal?

[labviewette]

Another issue that is making me wonder if this approach is best one is: when wiring the counter output to a DI line the voltage of the counter signal goes down 50%.

[Kevin_Price]

1.  you wrote:

...why is there the option to configure the change detection pin with a CTR signal?

I can't fully make sense of this question, probably due to a difference in the way we use certain terms.  A DI task based on change detection will produce an internal signal known as a "change detection event" which acts as the sample clock for the DI task.  It's then *also* possible for another task, such as a DO or CTR task, to refer to that signal as a trigger or clock, much like many other internal and external signals can be specified for those purposes.

2. Is anything else connected to the DI line that might draw it down to 50% nominal voltage?  Does this 50% amplitude remain even while generating pulses or do you only see it when tasks are idle?

   This isn't a typical issue to run into, you can generally wire CTR out to DI or DO to CTR in without a problem.

-Kevin P

[labviewette]

---

@Kevin_Price wrote:

@1.  you wrote:

...why is there the option to configure the change detection pin with a CTR signal?

I can't fully make sense of this question, probably due to a difference in the way we use certain terms.  A DI task based on change detection will produce an internal signal known as a "change detection event" which acts as the sample clock for the DI task.  It's then *also* possible for another task, such as a DO or CTR task, to refer to that signal as a trigger or clock, much like many other internal and external signals can be specified for

This makes perfect sense and I fully understand what you are writing. A question mark was hovering over my head when I created a control from the daqmx timing vi's input terminal (rising edge physical channel) because the CTRs were listed. I always thought that one can only access the CTR signals through the PFI lines. In other words I would have expected to see PFI lines rather than CTRs.

---

2. Is anything else connected to the DI line that might draw it down to 50% nominal voltage?  Does this 50% amplitude remain even while generating pulses or do you only see it when tasks are idle?

   This isn't a typical issue to run into, you can generally wire CTR out to DI or DO to CTR in without a problem.

---

Interestingly this phenomena occurs then I connect the PFI line of my counter with the digital lines of port 0. No problem when connecting to the digital lines of port 1 or port 2. Smells like a grounding issue.