10-14-2012 05:02 PM
Hi all,
I have an NI-6534 DIO card and have been asked to put together a simple data acquisition task. For a test fixture I have 16 DIP switches and a push button wired to REQ1. The pushbutton goes from hi to low when I press it.
I'm using DAQmx and C.
I compiled and ran ReadDigChan.c and that works - it reads whatever I have set on the 16 DIP switches correctly. I'm using port0 and port1....so I know I need to use Group 1 signals: ACK1 and REQ1.
Now I want to add the simplest of handshaking to it:
I want the 6534 to send out an ACK on ACK1 telling me that it's ready to receive (I believe this is done at powerup).
Then I want it to wait until it gets a falling edge on the REQ1 line (because I pushed the button), and read a 16 bit word.
That's it.
I've read the NI-653x User Manual. It's clear I need to use Handshaking I/O. It's clear I have to reverse the polarity of the trigger.
Questions:
1) What call is it, exactly, that informs the 6534 that I want to use handshaking mode? I don't want to use burst mode or pattern mode, or an external clock......just simple handshaking ACK/REQ. How do I inform it that it is supposed to wait for a REQ and then read n words? The manual is very unclear as to how the user onforms the card what mode is to be used.
2) The only user manual I can find is "Traditional" and all the block diagrams for C use function names from Traditional DAQ like DIG_grp_config whereas I use DAQmxCreateDIChan().
Is there a manual that has block diagrams using the C calls?
3) I've looked at the samples in /usr/local/natist/nidaqmx/examples/ansi_c/Digital. I see ReadValues and Handshaking.
Handshaking has only an 8255 example. But my input device does not have an 8255 chip set.
ReadValues has ReadDigChan and ReadDig Port which are good starts but the other examples are no where near the mode I wish to use.
Are there online examples that are more in tune with what I'm trying to do?
thanks
Gregg
10-15-2012 08:42 AM
An attempt to do this is below. It failed with the error message you see below the code fragment. Evidently just adding a call to DAQmxCfgHandshakingTiming() does not do the trick:
/*********************************************/
// DAQmx Configure Code
/*********************************************/
DAQmxErrChk (DAQmxCreateTask("DigInWithREQ",&taskHandle));
DAQmxErrChk (DAQmxCreateDIChan(taskHandle,"Dev1/port0/line0:7, Dev1/port1/line0:7","",DAQmx_Val_ChanForAllLines));
/*********************************************/
// DAQmx Configure the handshaking
// - finite number of samples
// - just one sample
/*********************************************/
DAQmxErrChk (DAQmxCfgHandshakingTiming(taskHandle,DAQmx_Val_FiniteSamps,2));
/*********************************************/
// DAQmx Start Code
/*********************************************/
DAQmxErrChk (DAQmxStartTask(taskHandle));
/*********************************************/
// DAQmx Read Code
/*********************************************/
DAQmxErrChk (DAQmxReadDigitalLines(taskHandle,1,10.0,DAQmx_Val_GroupByChannel,data,100,&read,&bytesPerSamp,NULL));
printf("\nBytes Per Sample is: %d\n", bytesPerSamp);
// assuming 8 channels acquired
// NOW assuming 16 channels acquired
for(i=0;i<16;++i)
printf("Data acquired, channel %d: 0x%X\n",i,data[i]);
Error:
if( DAQmxFailed(error) )
DAQmxGetExtendedErrorInfo(errBuff,2048);
if( taskHandle!=0 ) {
/*********************************************/
// DAQmx Stop Code
/*********************************************/
DAQmxStopTask(taskHandle);
DAQmxClearTask(taskHandle);
}
if( DAQmxFailed(error) )
printf("DAQmx Error: %s\n",errBuff);
printf("End of program, press Enter key to quit\n");
getchar();
return 0;
}
Resultant Error Message:
./ReadDigChan DAQmx Error: Some or all of the samples requested have not yet been acquired. To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock. Property: DAQmx_Read_RelativeTo Corresponding Value: DAQmx_Val_CurrReadPos Property: DAQmx_Read_Offset Corresponding Value: Task Name: DigInWithREQ Status Code: -200284 End of program, press Enter key to quit
10-15-2012
07:26 PM
- last edited on
10-31-2024
01:25 PM
by
Content Cleaner
Hi,
You can find additional information on handshaking mode for your NI-6534 device in NI 6534 NI DAQmx Help -> Sample Timing Types -> Transferring Data Between Two Devices–Handshaking
You can find all the documentation related to using DAQmx functions in C in NI-DAQmx C Reference Help
Finally, the error -200284 that you are getting occurs because the timeout occurred before any samples were received. The following article provides several solutions how to resolved this: Why Do I Get Error -200284 from my DAQmx Read VI?
10-19-2012 01:33 PM
Mikhail K,
Thank you for your response.
However I probably should have mentioned that I'm running under OpenSUSE 11.3 and not Windows.
Also, as I mentioned in my original post, I do not want to use Burst mode - just simple ACK/REQ handshaking. There is no external or internal clock.
So I do not understand the relevance of steps 3,4 and 5 of the sample program you suggest I look at:
* 3. Specify the Sample Clock Rate of the output Waveform.
* 4. Specify the Output Terminal for the Exported Sample Clock.
* 5. Specify the Sample Clock Pulse Polarity. When set to Active
* High, the data lines will toggle on the rising edge of the
* sample clock.
The pseudocode for what I want to do is:
1. send an ACK to the external device stating tha tthe 6534 is ready recieve data
2. Wait for REQ
3. when the 6534 gets the REQ, it reads 100, 16 bit words.
4. Return to #2
Are you saying that the Burst mode example allows this with some changes?
I have the documentation for the C functions. What I do not understand is which to pick:
1) How does one signal to the 6534 to use ACK/REQ handshaking?
2) What are the character strings used to specify ACK0 and REQ0 of group 1 control lines (I'm using Port0 and Port1) together for a 16 bit read).
Thanks,
Gregg
10-19-2012 02:05 PM
Changed the title to make it more clear what I need help with.
10-23-2012
07:16 PM
- last edited on
10-31-2024
01:30 PM
by
Content Cleaner
Hi Greg,
The reason for steps 3,4 and 5 that you mentioned is that in the burst mode (synchronous handshaking) three control lines are used for data transfer - one status line from each device (ACK & REQ) and one shared clock line (PCLK). In the example I referenced, the data is transferred to NI 6534 board from an external device. This is accomplished by using the onboard Sample Clock of the NO 6534 board to control burst handshake timing and exporting that clock for use by the external device (since we are doing synchronous handshaking and need to share the same clock across two devices). The Sample Clock Pulse Polarity simply determines whether to toggle data lines or rising or falling edge of the Sample Clock.
In the example I referenced here is what happens and it can work for your application if you are able to feed in the NI 6534 Sample Clock into the external device you use to communicate with NI 6534 (btw, what is it? is it simply the test fixture you mentioned in your first post?):
1) The 6534 asserts ACK if it is ready to input data.
2) If the external device also asserts REQ indicating it has valid new data on the data lines, the 6534 latches data on the rising edge of the PCLK signal.
3) This process repeats in every PCLK clock cycle.
If you are not sharing a sample clock or the external device does not support it then you can use Asynchronous Handshaking to communicate with NI 6534 board. Communication is acomplished through 8255 protocol (Handshake sample timing) in this case. In addition to the data lines (port 0 & 1), the Handshake sample timing type uses two additional signals: the Handshake trigger and the Handshake event. The Handshake event can be configured for pulse or interlocked output behavior.
Handshake Trigger
A Handshake trigger is a control signal from a peripheral device used with handshake timing. The peripheral device asserts the Handshake trigger to signal to the DAQ device that it has acquired a sample (for output tasks) or generated a sample (for input tasks). For input tasks, the DAQ device acquires the sample, by default, when the peripheral device deasserts the Handshake trigger. You can choose to have the device acquire the sample when the peripheral device asserts the Handshake trigger by configuring the DAQmx Sample Input Data When property/attribute.
A Handshake event is a signal generated by a device that is used with the Handshake sample timing type.
For the NI 6533/6534, the default configuration mimics the 8255 protocol, which means that for input tasks, this event asserts after the device has space available in its FIFO; for output tasks, it asserts after valid data has been driven on the data lines; and in both input and output tasks, the event deasserts after the Handshake trigger has been asserted.
The Handshake event can be configured for one of two output behaviors:
Your NI 6534 device knows that it is in the ACK/REQ handshaking mode when you set the appropriate NI-DAQmx properties.
The NI-DAQmx properties you can use to configure the Handshake trigger and event for input are described in the handshaking properties table.
Finally, the lines that correspond to ACK1 and REQ1 on your NI 6534 device are PFI 6 (pin 3) and PFI 2 (pin 2) respectively (ACK0 and REQ0 don't exist on NI 6534). For more information refer to the following documents:
FYI: NI 6534 is scheduled for obsolescence on December 31, 2012.