LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Routing PXI-6602 TB-2715 Counter PWM Signals

Hi;

 

I have a PXI 6602 timer-counter card on which one TB-2715 is mounted.

 

I want Ctr0 to generate a PWM signal using  /Example/..../Gen Dig Pulse Train-Continuos.vi.

I want Ctr1 to receive this PWM and measure it, all of this using /Example/Meas Pulse Width-Buffered-Finite.vi.

 

Using the TB-2715, how can I pass the PWM generated by Ctr0 to Ctr1. How to wire my counters pins (PFIx) in such loopback?

 

Reference: TB-2715 Terminal Block Installation Guide, Figure 4.

 

0 Kudos
Message 1 of 7
(3,877 Views)

Hey KizKas,

From what you've described you should just have to run a wire from Pin # 5 (PFI_38(OUT_0)) to Pin # 7 (PFI_35(SOURCE_1). Give this a try and you should be able to see your PWM signal being routed. Hope this helps!

 

Lars

0 Kudos
Message 2 of 7
(3,853 Views)

Hi Lars;

 

Thank you for the reply.

 

Connecting my wire as you have described does not work.

 

Instead, I have connected Pin # 5 (PFI_38(OUT_0)) to Pin # 8 (PFI_34(GATE_1) and now it works.

However, the duty cycle that I'm getinng is inverted (ex: Ctr0 has a duty cycle of 0.3 while Ctr1 has a duty cycle of 0.7).

I wonder if it is the signal that has so changed or something inside the measurement done by Ctr1 block diagram.

 

Can you tell me why this inversion happens?

 

Again, I'm using the following NI examples: Gen Dig Pulse Train-Continuous (Ctr0) and Meas Duty Cycle-Buffered-Finite.vi (Ctr1)

 

Kizito.

0 Kudos
Message 3 of 7
(3,845 Views)

Hey Kizito,

My apologies. You are correct that you need to connect the wire to Pin # 8 (PFI_34(GATE_1). This is because counters at the base level can only count rising or falling edges and thus when you don't have a signal wired to your SOURCE, the timebase of the card is used as your signal input. Since your GATE turns the counting on if the signal is high and off if the signal is low, your pulse train should be wired to the GATE and thus it will turn the counting of the timebase on when your signal is high and off when it is low.

 

Regarding as to why this inversion would occur, I did some testing and I am seeing similar behavior on my end showing that the received signal from Meas Duty Cycle-Buffered-Finite.vi is returning an incorrect value for the first element of the array. Are you seeing this as well? If you are, then a simple modification can fix this issue for you. Since the first element is incorrect I simply deleted this using Delete From Array which then alligned the period measurements and fixed this issue. Refer to the attached screenshot as to how I implemented this.

 

I'm going to investigate this further as I believe this might be unexpected behavior on the DAQmx side of things as the first element of the array should be valid and I will let you know what I find out.

 

Lars
0 Kudos
Message 4 of 7
(3,814 Views)
Hi Lars;

Thank you for the reply.

I would distinguish between these two problems:

1) Initial duty cycle is wrong:

One of NI engineers told me (and I agree with him) that this is due to the fact that, at the beginning the measurement loop does not know whether the signal is high or low because it has not already detected a falling edge nor a rising edge. Therefore, the first measurement must be ignored.

I will analyze your proposal about this and lets you know.

2) Duty cycle is inverted.

This affects all the measurements in the array. I'm still not clear why this happens (or may be the signal does not change and this is simply a pure measurement issue).

Kizito.

0 Kudos
Message 5 of 7
(3,801 Views)

KizKas,

 

1) Confirm.  The initial value would represent the time from when the counter is armed & started until the 1st active edge.  This is often a meaningless value and can be ignored.

 

 2) Not sure why you only measure pulse width - is it because you assume you know the frequency?  In any event, you can use a DAQmx Channel property node to specify the "active edge" to use for the measurement.  When you don't set it explicitly, it probably defaults to be the opposite of what you want.  If you set it explicitly, you should be able to get the behavior you want consistently.

 

-Kevin P.

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 6 of 7
(3,794 Views)

Hey KizKas,

The initial duty cycle value is going to be wrong as the following two KnowledgeBase articles explain:

 

[Why Do I Get Erroneous Values on the Semi-Period Counter Input Measurement?]

http://digital.ni.com/public.nsf/allkb/8579D7E5CD494D9F86256B3E005798C2?OpenDocument

 

[When Performing Buffered Period Measurement, Why Is the First Value in the Buffer Incorrect?]

 

http://digital.ni.com/public.nsf/allkb/47BAA9569AEDFC0886257091007A217A?OpenDocument

 

Since calculating duty cycle involves doing a semi-period measurement and then decimating the data set, having your first value in the buffer is erroneous, it then makes the first duty cycle value incorrect and it inverts the others so you get 0.3 instead of the expected value of 0.7. To fix this, you can simple discard this value by deleting it as I showed in my previous post.

 

Also here's a good reference on how to do PWM using DAQmx from our DeveloperZone:

http://zone.ni.com/devzone/cda/tut/p/id/2991

 

Let me know if you have any questions about this.

 

Lars

 

 

0 Kudos
Message 7 of 7
(3,781 Views)