Confused about PFI usage

[Norbert_B]

What happens if your remove the property node "CO.Pulse.Term" from the counter out task? Does it then run as expected?

Norbert

Edit: You should properly synchronize your tasks. Since your DAQmx Start Task for both tasks are concurrent, you have a race condition when the value for CI is read vs how many CO pulses have already been created. You have to start CI before starting CO. Use the error cluster to synchronize this.

[CoastalMaineBird]

What happens if your remove the property node "CO.Pulse.Term" from the counter out task? 

Exactly the same thing: no errors, but a DATA count of 1, not 1000.

I think the "1" is from the connection switching somehow.

[CoastalMaineBird]

You have to start CI before starting CO

I don't see why.

you have a race condition when the value for CI is read.

I don't see why.

I start both tasks, wait 1000 mSec and then read the CI task.

In any case, forcing CI to start before CO changes nothing.

[Norbert_B]

Hm, i never saw an example for CO Pulse Frequency which is not using a DAQmx Timing VI either set to "continuous" or "finite". I find it possible that without that function, your CO simply creates a single pulse with duty cycle 50:50 with a period of 1ms (1kHz).

Norbert

[Norbert_B]

---

@CoastalMaineBird wrote:

You have to start CI before starting CO

I don't see why.

you have a race condition when the value for CI is read.

I don't see why.

---

Since you have no start trigger for both of them, both tasks run right after calling "Start Task". If your CO would be continuous, your assumption would be correct (value somewhere around 1000). BUT if you create only 1000 pulses, you have to start input before output, otherwise you could miss pulses (race condition)!

hope this is now more clear...

Norbert

[CoastalMaineBird]

if you create only 1000 pulses

It's not a RACE problem, but that is pertinent.

I put a TIMING VI into the CO task and asked for CONTINUOUS.

Now I get a count of 1120, give or take a few.

I understand why it's not 1000 exactly. I'm not concerned.

What I didn't understand is that the CREATE CHANNEL and START TASK is not sufficient.

I thought that would start generating pulses until further notice. 

It just ain't so.

[CoastalMaineBird]

Arrrgh.  I just want a simple digital scope, why is it so difficult?

Thanks for your tips, Norbert, they have steered me more correctly.

But now, I still can't do what I want to do.

The digital input task (disabled in my original screenshot), now complains that it cannot do what I want to do - it cannot have a SAMPLE CLOCK on a digital input task.

But another device in my system can.  Apparently I can route the signal from this counter on CTR board to the port 1 on another board "RTEC".

And I can set up a timed digital input task for that digital input port.

But, alas, it complains: Only lines supporting buffered operations can be used.

So, can I use port 0: Why sure - it doesn't have this problem, I guess it has buffered lines.

Can I connect from my CTR board to port 0 on RTEC board?  Why no.  You can't make such a connection.

Arrrgh.

[Norbert_B]

Steve,

what device is "RTEC"?

Regardless, here is what could explain the behavior:

There are different types of digital IO regarding "clocking".

The 6602 states in the manual:

Data Transfer: Static

Handshaking: None

I am not sure about this terminology, but it appears to me that DIO on this device can only be software timed (request a value by DAQmx Read). No external clocking possible.

Other devices, like the M-Series devices from NI, do have some contraints:

DIO port 0 is correlated, so it can be hardware clocked, while other ports are still only software timed.

Possibly your device "RTEC" is similar.

And the third type of devices have a full capacity for hardware clocking DIO.

Regarding your last question:

What is the error you are seeing? What are you doing in the VI that you receive that error?

Norbert

[CoastalMaineBird]

what device is "RTEC"?

RTEC is a PXI-6221: 2 AO, 16 AI, 24 DI/DO, 2 CTR, board

Regarding your last question:

What is the error you are seeing? What are you doing in the VI that you receive that error?

The error is "Hardware doesn't support it".  I'm using the MAKE CONNECTIONS vi to try.

Basically, I can connect to the port that won't do clocked input, and I can do clocked input on the port that I can't connect to.

--- I've got my big-boy pants on today; not my whiny-baby suit.

Basically, I was trying to do this without engineering it.  A bad plan, it seems.

It just seemed theoretically so easy: just connect the counter output (the one I want to test) to a digital input port, and grab 10 seconds of data at 1000 Hz and look at it.

I was hoping to spend a half hour doing that, and instead I spent all day, and still got nothing.

[Norbert_B]

Steve,

the 6221 is a M-Series device. So only port 0 is correlated. That is the reason why trying to clock port 1 fails.

---

@CoastalMaineBird wrote:

[..]and I can do clocked input on the port that I can't connect to.

 [..]

---

This sounds like you have issues with the external connections. Is port 0 already connected to other parts of your DUT?

As long as the frequency of your clock signal does not exceed 10MHz, you can use the PXI backplane to route the clock signal from the 6602 to the 6221. But you are correct, this is only possible if you know and use the correct assignments for PFI/TTL lines.....

Norbert