How set state of unused control lines on 653x card

[DoctorNick]

I'm using a 6533 card to perform interlocked handshaking (8255 style) for all four data ports (total of 32 bits). I'm using PFI2 for REQ and PFI6 for ACK. Is it possible within the same task to set the output levels of the unused control lines (to use as general purpose I/O)?

[CharlesD]

If you are using those PFI lines for handshaking those particular lines are reserved.  However any of the other lines can be configured within the same task by simply creating a new virtual channel in LabVIEW.  Have you tried this?  Are you getting an error when doing so?

There is some special considerations outlined in the manual for some of the lines regarding handshaking, I have copied the excerpt below.

From the manual:

If you are not using Group 1 and/or Group 2 as timing controllers to
perform pattern I/O or handshaking I/O, you can use their control lines as
extra data lines. These lines constitute Port 4. The direction and output
driver type of these lines are not configurable—four lines are used as input
only and four are used as standard output only. Even though there are eight
actual lines, the port width for Port 4 is 4 bits. In software, these lines are
collectively referred to as Port 4. When writing to Port 4, the output lines
are affected; and when reading from Port 4, the input lines are read.
Table 2-1 displays how Port 4 lines are organized.

Post back if you are still having issues. 

Thank you

[DoctorNick]

OK. I checked the documentation. It looks like I can write to port5, not port 4 (that's for

the inputs). I'm still not sure how I can create additional virtual channels within the same

task (I'm working in Measurement Studio for VC2005).

The code I had previously created a single DIChannel and read from it.

[DoctorNick]

I've created two separate tasks to write to these lines. Does it

matter in which order I call the tasks?

Here's a snippet of my code in which I start the work:

event_task = std::auto_ptr<CNiDAQmxTask>(new CNiDAQmxTask());

event_task->DIChannels.CreateChannel(

"Dev1/port0_32", "EventChannel",

DAQmxOneChannelForAllLines);

// Make sure we're routing handshake signals appropriately

event_task->ExportSignals.HandshakeEventOutputTerminal = "PFI6";event_task->Triggers.HandshakeTrigger.Interlocked.SetSource("PFI2");

event_task->Triggers.HandshakeTrigger.Interlocked.AssertedLevel

= DAQmxInterlockedHandshakeTriggerAssertedLevelLow;

event_task->Triggers.HandshakeTrigger.Type =

DAQmxHandshakeTriggerTypeInterlocked;

event_task->ExportSignals.HandshakeEventInterlockedAssertedLevel

= DAQmxHandshakeEventInterlockedAssertedLevelLow;

event_task->ExportSignals.HandshakeEventInterlockedAssertOnStart = TRUE;

event_task->Timing.ConfigureHandshaking(DAQmxSampleQuantityModeContinuousSamples,

4096);

event_task->Timing.HandshakeDelayAfterTransfer = 0.0;

// event_task->Timing.HandshakeSampleInputDataCondition =

// DAQmxHandshakeSampleInputDataConditionHandshakeTriggerAsserts;

event_task->Stream.Timeout = 200; // 250 ms

// Verify the task

event_task->Control(DAQmxTaskVerify);

event_task->Start();

event_reader = std::auto_ptr<CNiDAQmxDigitalSingleChannelReader>

(new CNiDAQmxDigitalSingleChannelReader(event_task->Stream));

// Set up first callback

event_reader->InstallEventHandler(&Event_Handler);

event_reader->ReadMultiSamplePortUInt32Async(1024,event_data,NULL);

state = false;

CNiDAQmxTask control_task1;

control_task1.DOChannels.CreateChannel("Dev1/port5/line1", "2660_RESET", DAQmxOneChannelForEachLine);

CNiDAQmxDigitalSingleChannelWriter control_writer1(control_task1.Stream);

control_writer1.WriteSingleSampleSingleLine(true,state);

CNiDAQmxTask control_task2;

control_task2.DOChannels.CreateChannel("Dev1/port5/line3",

"AIM_RESET", DAQmxOneChannelForEachLine);

CNiDAQmxDigitalSingleChannelWriter control_writer2(control_task2.Stream);

control_writer2.WriteSingleSampleSingleLine(true,state);

[CharlesD]

To have multiple channles within on task uyou can do one of two things. 

1. Call the create Channel function again but reference the origianl task. 

2. use on createChannel function and use the following syntax : "Dev1/port0_32:33" or "Dev1/port0_32, Dev1/port0_33"

In both cases this will put lines 32 and 33 in the task.  The first one will place all lines between the two values separated by the colon in the task. 

No it should not matter which order you create the tasks. only thing that matters is how you want your program to execute.  This is user defined. There are no rules as to how you should create the tasks.  The only thing is that lets say you create a task to act as the sample clock for another task, then you should probably create that task before creating the task thatis dependent on the sampling clock task. But this is just like any other programing.

Remember that you can only create one DI/O task that is hardware timed. You can however create multiple software timed DI/O tasks.  It is therefore important to clear the first task before creating the second task if you desire to do that

[DoctorNick]

When I try to create the DOChannels in the same task in which I have created the DIChannel I get an exception that one must create one task for each channel type.

[DoctorNick]

This is really getting frustrating. I should have mentioned previously that I'm porting a previous program written in NI-DAQ 6.9 to DAQmx 8.1. The NI-DAQ program runs great and the DAQmx program is a dud. I have swapped 6533 cards between the two machines and find that both cards yield the same result on each computer (I do _not_ have NI-DAQ6.9 and DAQmx on the same machine).

The device I'm controlling connects 5VDC to CPULL on the 6533 card so that the undriven lines pull high. I need lines PFI5 and PFI7 to be driven low in order for the device to operate. I'm using PFI6 for handshaking I/O. The fact that the NI-DAQ program can drive these lines low while the DAQmx program cannot drive them certainly tells me that it's all about the program.

I have created tasks to clear these lines which I run and stop before starting the timed I/O. I have monitored the state of these lines with a scope and find that I am not driving them low. Here's my code. I call the routine Clear_Resets() before the routine Event_thr():

void Clear_Resets()

{

    bool state;    state = false;

    CNiDAQmxTask control_task1;

    control_task1.DOChannels.CreateChannel("Dev1/port5/line1","2660_RESET", DAQmxOneChannelForEachLine);

    CNiDAQmxDigitalSingleChannelWriter control_writer1(control_task1.Stream);

    control_writer1.WriteSingleSampleSingleLine(true,state);

    control_task1.WaitUntilDone(100);

    control_task1.Stop();

    CNiDAQmxTask control_task2;

    control_task2.DOChannels.CreateChannel("Dev1/port5/line3","AIM_RESET", DAQmxOneChannelForEachLine);

    CNiDAQmxDigitalSingleChannelWriter control_writer2(control_task2.Stream);

    control_writer2.WriteSingleSampleSingleLine(true,state);

    control_task2.WaitUntilDone(100);

    control_task2.Stop();

}

UINT __cdecl Event_thr(void *dummy)

{

    bool state;     try {

        event_task = std::auto_ptr<CNiDAQmxTask>(new CNiDAQmxTask());        event_task->DIChannels.CreateChannel(

"Dev1/port0_32","EventChannel",DAQmxOneChannelForAllLines);

       // Make sure we're routing handshake signals appropriately

       event_task->ExportSignals.HandshakeEventOutputTerminal = "PFI6";       event_task->Triggers.HandshakeTrigger.Interlocked.SetSource("PFI2");

       event_task->Triggers.HandshakeTrigger.Interlocked.AssertedLevel = DAQmxInterlockedHandshakeTriggerAssertedLevelLow;

       event_task->Triggers.HandshakeTrigger.Type = DAQmxHandshakeTriggerTypeInterlocked;

       event_task->ExportSignals.HandshakeEventOutputBehavior = DAQmxHandshakeEventOutputBehaviorInterlocked;

       event_task->ExportSignals.HandshakeEventInterlockedAssertedLevel = DAQmxHandshakeEventInterlockedAssertedLevelLow;

       event_task->ExportSignals.HandshakeEventInterlockedAssertOnStart = false;

       event_task->Timing.ConfigureHandshaking(DAQmxSampleQuantityModeContinuousSamples,4096);

       event_task->Timing.HandshakeDelayAfterTransfer = 0.0;

       event_task->Timing.HandshakeSampleInputDataCondition = DAQmxHandshakeSampleInputDataConditionHandshakeTriggerAsserts;

       event_task->Stream.Timeout = 200; // 250 ms

       // Verify the task

       event_task->Control(DAQmxTaskVerify);

       event_task->Start();

       event_reader = std::auto_ptr<CNiDAQmxDigitalSingleChannelReader> (new CNiDAQmxDigitalSingleChannelReader(event_task->Stream));

       // Set up first callback

       event_reader->InstallEventHandler(&Event_Handler);

       event_reader->ReadMultiSamplePortUInt32Async(1024,event_data,NULL);

    }

    catch (CException *e)

    {

        e->ReportError();

        e->Delete();

    }

    return 0;

}

Will the handshaking task step on the task that tries to clear the lines in port 5?

[CharlesD]

Hello Nick,

Have you tried runnig an example program to see if you can drive the lines low from your computer without considering the handshaking aspect of things.  A good example would be found at : .....\National Instruments\NI-DAQ\Examples\MStudioVC2005\Digital\Generate Values\WriteDigChan\WriteDigChan.2005.sln  basically we need to check that we are able to drive the lines low without considering handshakin.

As for whether the task will be overwritten by the handshaking, it will if and only if the PFI line that is trying to be set low is part of the handshaking group than it cannot be used for unstrobed I/O as mentioned in the following excerpt from the manual.   More specifically all of the lines that are part of the handshaking group are reserved and cannot be used, however if you aren't using that particular group you should be able to drive those lines low if needed. 

1. Note If you configure either group to perform handshaking I/O or pattern I/O, the
associated timing control lines for that group are not available for unstrobed I/O.

2. If you are not using Group 1 and/or Group 2 as timing controllers to
perform pattern I/O or handshaking I/O, you can use their control lines as
extra data lines. These lines constitute Port 4. The direction and output
driver type of these lines are not configurable—four lines are used as input
only and four are used as standard output only.

Let me know if you can drive those lines low with a simple digital write to that PFI line.