Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Behaviour of P0 lines on connector0 and connector1 is different

Solved!
Go to solution

I am trying test my scan chain using PCIE6323. I am able to do that if I use P0<0:7> (P0 lines on connector0) but not if I use P0<8:31> (P0 lines on connector1). The Labview code runs without errors in both the cases, but the output waveform is not observed on the oscilloscope when P0<8:31> are used.

The behaviour of P0 lines on connector0 and connector1 is not identical. I believe the portion of the code that made use of the DAQmx Timing VI did not work for some reason for P0 lines on connector1.

The cable is not faulty as when the same cable is used with connector0 it works well. Rebooting the computer did not make any difference. I don’t think 6323 is faulty, as the same behaviour was observed with another 6323.

I observed the same kind of behaviour when I run the VI for continuous DO generation (largely same as the example VI except for the use of regeneration from on-board memory). The code runs without errors. But waveform is observed is case of P0<0:7> but not in case of P0<8:31>.

I have attached the VIs I have used for the scan chain test and continuous DO generation.

For scan chain test scan_test.vi is the main vi which calls scan_in.vi and scan_out.vi. The portion of the scan_in.vi which makes of synchronous_do.vi seems to be causing the issue. const_do.vi works fine for both the connectors.

For continuous DO generation, I used Digital - Continuous Output.vi

Please tell me why P0 lines on connector0 and connector1 behave differently. I am using LabView professional development System (2012 SP1, 12.0.1, 32bit) on a 64 bit Windows 7 computer.

0 Kudos
Message 1 of 10
(4,797 Views)

I would start by making sure that this issue is software instead of some hardware setting.

 

Could you try running one of the digital output example programs included with LabVIEW and testing the outputs to see if the 2nd connector outputs the expected values?

 

If the example doesn't work, its likely either the hardware failing or a hardware setting that isn't set correctly.

0 Kudos
Message 2 of 10
(4,741 Views)

I ran the example for Digital-Finite Output for P0<0:7> and P0<8:15>. The code runs without errors in both the cases. 

But the waveform is observed only when P0<0:7> is used.

 

The example for Digital-SW Timed Output works in case of the both P0<0:7> and P0<8:15>.

0 Kudos
Message 3 of 10
(4,736 Views)

That leads me to think its something with the hardware settings or hardware.

 

Try going into NI MAX and checking the configuration of your card and checking if any of the lines have different settings in the power-up states menu.

0 Kudos
Message 4 of 10
(4,734 Views)

All the lines have been set to tristate for the power up states

0 Kudos
Message 5 of 10
(4,731 Views)

In MAX can you setup a test panel and try outputting values to the outputs that are not showing up correctly on your oscilloscope?

0 Kudos
Message 6 of 10
(4,724 Views)

The issue is hardware timed tasks dont seem to work. The test panels on NI MAX are software timed and hence will work.

0 Kudos
Message 7 of 10
(4,720 Views)
Solution
Accepted by topic author pc2769

In synchronous_do.vi, you're passing in a U8 array into Digital 2D U32 NChan NSamp, with values 0 and 255.

 

What happens if you change it to a U32 array, with values 0 and 4294967295 (0xFFFFFFFF)?

——
Brandon Streiff
ni.com/compactdaq · ni.com/daq
Message 8 of 10
(4,702 Views)
Solution
Accepted by topic author pc2769

We set up your hardware and it looks like bstreiff is on the ball. The ports work like full 32 bit unsigned ints, and you need to write 256 (or higher) to write outputs to the bits from 8 to 31 of port 0. So you need to use 32 bit unsigned ints that match the location in the port (even if you're just writing to a subset of the port).

Message 9 of 10
(4,699 Views)

Changing 255 to 4292967295 did the job. Thanks a lot!

0 Kudos
Message 10 of 10
(4,687 Views)