Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

how to import 6602's counter output to PFI3 of the 6534 board?

Dear friends,

I have the following problem:

I am trying to import the output of one of the counters of the 6602 board (counter 4) to the REQ2 (PFI3) line of the 6543 board (please see the VI attached). But I do not see any signal on the PFI3 line though the VI runs without errors.

The situation is the same if I connect output of the counter to the PFI3 directly in the "Connect Terminals" VI instead of connecting it via PXI_Trig4 line.

I need your help to understand why is it so and how can I accomplish the "import" task.

Thanks in advance!

0 Kudos
Message 1 of 7
(4,903 Views)
Hi ampm,

From taking a quick look at your VI, I believe you may be running into an issue in the PFI line you have assigned for CTR 4 OUT.  The current default value in your VI is for PFI26 (actually CTR 3 GATE); however, the PFI line for CTR 4 OUT is PFI20 (physical pin number 26).  Modify this and see if you are then able to use the routed counter signal on the 6534.

Regards,
Andrew W
National Instruments
0 Kudos
Message 2 of 7
(4,896 Views)

Hi Andrew,

You are absolutely right - there should be PFI20 instead of PFI26.
It works now. Thank you!

.....I hope you can give some ideas with regard to the following problem:

In a program I used four 6602's counters (counters 0-3) to generate single trigger pulses on the backplane of the PXI.
It worked fine.
Now I want to incorporate the fifth counter into the program (counter 4) to generate a finite pulse sequence on the PFI3 line of the 6534 board.
And I can not do this.
Code example is in the VI attached.

When I try to run this VI it gives error:

Error -89137 occurred at DAQmx Connect Terminals.vi:4
Possible reason(s):

Specified route cannot be satisfied, because it requires resources that are currently in use by another route.

Source Device: TimingIO
Source Terminal: PFI36
Destination Device: TimingIO
Destination Terminal: PXI_Trig0


Required Resources in Use by

Source Device: TimingIO
Source Terminal: PFI20
Destination Device: TimingIO
Destination Terminal: PXI_Trig4

I do not understand why it happens and how to correct this....

Thanks!




 

0 Kudos
Message 3 of 7
(4,885 Views)
Hi ampm,

I would recommend using the DAQmx Channel property "CO.Pulse.Term" instead of the "DAQmx Connect Terminals.vi" to specify the terminals (in your case the PXI_Trig lines) on which to generate the counter pulses.  You can write to the "CO.Pulse.Term" property by right clicking on the property node and selecting "Change All To Write".  In addition, instead of using the PFI line numbers for the counter output signals, use the internal names as defined in MAX.  Here is a KnowledgeBase article that gives more information about this.  I was using simulated devices to test this, and after a reset of my devices in MAX I was no longer getting the -89137 error.

Regards,
Andrew W


Message 4 of 7
(4,859 Views)

Hi Andrew,

Thanks for your reply!
I had used internal names instead of the PFI line numbers and the -89137 error disappeared and there was a signal on the PFI3 line of the 6534 board.
 
But..... I've got a new strange error instead:

Error 3 occurred at an unidentified location
Possible reason(s):
LabVIEW:  Internal error. Wrong memory zone accessed.
=========================
NI-488:  GPIB Controller not addressed correctly.

I replaced "DAQmx Connect Terminals.vi" with "CO.Pulse.Term" (just in case) but the error did not disappear.

My current VI is in the file attached.  I am using LabVIew 8.2 Full Development System. OS is Windows XP Professional Version 2002 Service Pack 2.

Thanks! 

 

 

0 Kudos
Message 5 of 7
(4,840 Views)
Hi ampm,

I received the same error that you did when running your code.  I was able to trace it to the Simple Error Handler.vi in frame 1 of your stacked sequence structure.  You currently have the "OK message + warnings" parameter wired to the "error code" input, but this should actually be wired to the "type of dialog" input on that vi.  The error message that we were getting seems to be a generic error that LabVIEW produces because it is not sure how to handle the input to the Simple Error Handler.

Regards,
Andrew
0 Kudos
Message 6 of 7
(4,809 Views)
Thank you Andrew!
 
Regards,
ampm
0 Kudos
Message 7 of 7
(4,793 Views)