counter2 and digital write issue on 6602

[maueat]

Hi,

I'm using a PCI-6602 card with NIDAQmx, and I observed a strange behaviour.

When I'm using ctr0,ctr1 and ctr2 to generate a pulse train, when I write out a value on one of DIO line, ctr2 stops signal emission.

If I use ctr0 and ctr1 to generate pulse, and ctr2 to count or to measure a period (or anyway like a input), when I write out a value on one of DIO line, ctr2 continues its work.

This behaviour is the same on LabView under Windows and using C APIs of NIDAQmx 8.0 libraries under Linux, and seems to be a bug.
Is it so or is it a 6602 limit?

Thank you, regards

Mauro 

[Chuck_81]

Ciao Mauro,

it seems an odd behaviour, so I need some more information from you:

1. are generating a finite or continuous pulse train?
2. Does Ctr2 generation stop happen only when you try to write on a specific digital line or it shows up on every line you try to drive? I checked 6602 pinout and the Ctr2 Out terminal corresponds to the P0.28 (line 28 on the port 0) digital line. This could explain why Counter input tasks  (Edge count etc.) work while CtrOut operation don't

Hope this helps,

Fabio

[maueat]

Ciao Fabio,

thank you for your support.

I think the same that you say in 2nd point...but this behaviour happens both if I write on port0/line0 than if I write on another line.

In DAQmxWriteDigitalLineFunction, I use DAQmx_Val_GroupByChannel on dataLayout, and when I create channel, in DAQmxCreateDOChannel I tried to use DAQmx_Val_ChanForAllLines and  DAQmx_Val_ChanPerLine in lineGrouping, but behavior is the same: counter stops emitting when I write on DO.

All counters are generating a continuous pulse train.

Thanks in advance, have a great weekend

Mauro 

[reikira]

Hi Mauro!

I developed a simple application in Labview to test the simultaneous generation of 3 pulse trains and digital output.

In the application the pulse trains are generated continously and the digital output begins when you push the "OK BUTTON".

The pulse trains are also acquired as analog inputs (with another board) to test if the generation is still correct when the digital output starts. I tested with a PCI 6602 and everything works correctly.

I attach the application, could you please use it to test your system?

Thank you

Serena M.

Application Engineer

[maueat]

Hi Serena,

thank you for your support.

I opened your .vi file on Windows, and I report functions used there in my Linux code, but problem still persists.

Could be a Linux driver bug?

I report functions that I use to create a digital output line:

uInt8 data=1; 

DAQmxCreateTask("mytask",DOtask);

DAQmxCreateDOChan(DOtask,"/Dev1/port0/line0","",DAQmx_Val_ChanForAllLines);

DAQmxWriteDigitalU8(DOtask,1,1,0,DAQmx_Val_GroupByChannel,&data,NULL,NULL);

Functions works properly (no errors returned) but ctr2 stops emitting signal.

Thank you, regards

Mauro 

[reikira]

Hi Mauro,

this is really strange. Couldn't you test directly with the application in LabVIEW I gave you, in order to check if the problem is in the Linux drivers? You could modify my vi and set exactly the same properties you use in your application.

Regards,

Serena

[Kevin_Price]

This kind of problem was encountered somewhat commonly under traditional NI-DAQ when people would use LabVIEW's shipping examples to try things out.  The essence of the problem boiled down to the way the examples tended to configure the digital port for either 32 inputs or 32 outputs, creating potential conflicts with counter tasks.

The conflict is that counters 2-7 share pin assignments with DIO 8-31.   Ctrs 0,1 don't share and DIO 0-7 don't share.  The resolution was to configure the digital port more carefully using the line masking to specifiy input bits and output bits.  DAQmx handles a lot of that port config stuff behind the scenes now, and it hasn't seemed to be much of a problem any more.

The problem described sure looks and feels like one of those conflicts, even though the use of Dev1/port0/line0 seems like it should avoid any.

-Kevin P.

[maueat]

Hi Kevin,

thank you fot your help.

I tried each of all eight counters with simultaneous digital write. I can see this behaviour when, on running counter, I write a 1 onto /Dev1/port0/line0

ctr0: continue emission (no line sharing)

ctr1: continue emission (no line sharing)

ctr2: stop emission (line sharing with DIO28)

ctr3: stop emission (line sharing with DIO24)

ctr4: continue emission (line sharing with DIO20)

ctr5: continue emission (line sharing with DIO16)

ctr6: continue emission (line sharing with DIO12)

ctr7: continue emission (line sharing with DIO8)

So, probably the line mask enables line 0 and lines over 24 as digital output

I think that could be a good idea to make available the mask handling under C/C++ code (such as on NIDAQmx test panels) to avoid these conflicts.

Bye, Mauro 

[Kevin_Price]

Further thoughts because things are still acting curious:

I notice you're using a U8 type of Write function.  It kinda appears that the conflicts are limited to the 8 bit range from PFI24 through PFI31, though the reason why remains puzzling.

I *do* recall that under traditional NI-DAQ, the digital tasks always had to be specify a 32-bit port width.  Attempting to treat it as an 8-bit port would produce errors.  I'm a little surprised that a U8 Write seems to function without throwing an error.  Further curiousness: the conflict from bits 24-31 almost suggests that the U8 Write might actually write to the UPPER 8 bits of the 32-bit port rather than the LOWER 8 bits.

Some ideas for probing at what's going on:   Have you checked to see which DIO pin(s) actually change state when you perform the Write?  Do you see a change at PFI0-PFI7?  At PFI24-PFI31?  Both? (?!?)    Try doing U32 Writes in which only the lower 8 bits are toggled instead of the U8 Writes.  Also try setting up the line grouping property to be 1 Channel per line.  (I wonder if the 1 channel for all lines setting makes some assumptions about configuring more of the port for output.)

-Kevin P.

[maueat]

Hi Kevin,

first of all I apologize: resuts that I wrote in my last message was obtained with DAQmxWriteDigitalLines, not DAQmxWriteDigitalU8.

In facts, as you say,  DAQmxWriteDigitalU8 and DAQmxWriteDigitalU16 functions fails with error "specified digital channel contains more bits than supported by the x-bit version of DAQmx port write".

Then, I tried all combinations that you suggest: 1 channel per line with DAQmxWriteDigitalLines and DAQmxWriteDigitalU32, and 1 channel for all lines with DAQmxWriteDigitalLines and DAQmxWriteDigitalU32.

Result is the same for all combinations: only counters 2 and 3 stop emission.

I also checked all PFI outputs for each parameter-method combination: result is always that only PFI0 (as wanted) changes its status, and none of other PFIs do it.

So, I think that there is a driver bug, that disables ctr2 and 3 when drive a DIO write (also when this write does not affect shared signals). What do you think?

Thank you, have a great weekend.

Mauro