Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

nidaqmx base 2.1.0-f0 synchronized analog input output

<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><meta name="GENERATOR" content="OpenOffice.org 2.3 (Linux)">
Main issue:

As far as I can tell, you cannot run simultaneous, synchronized analog input and output tasks from NIDAQmxBase 2.1.0-f0.

Workaround:

Try and install NIDAQmx 8.0?

System: (see sys_output in attached tarball for more system information)

Ubuntu 7.10 Gutsy Gibbon, clean install with NIDAQmxBase 2.1.0-f0 mostly following Johannes (studentTUD)
http://forums.ni.com/ni/board/message?board.id=250&message.id=34226
(Still needed to patch NIDAQmxBase, even after installing NIKAL-1.6)
NI-PCI-6052E card

Details:

I attempted to reproduce
Timing and Synchronization Features of NI-DAQmx
http://zone.ni.com/devzone/cda/tut/p/id/4322
Figure 2
In NIDAQmxBase, adding some command line options to control clock source and input/output task starting order.

It is interesting that using /Dev1/ao/SampleClock as a master gives
This routing is not possible in DAQmx Base because only one operation of the board is supported at a time.
When configuring the input clock.

While using /Dev1/ai/SampleClock as a master gives
An attempt has been made to perform a route when the source and the destination are the same terminal.
When configuring the output clock!

Does this mean that the input and outputs are already using the same clock?
No, because of the ~ms delay between the input and output data depending on which started first
(`simult_AIO o - -` vs `simult_AIO i - -`, hard to tell with 10 points, but clear if you do 2000 points at 20kHz).

I'm not sure what to do about this.
I think I'll go back and dig through the NIDAQmx 8.0 on modern linux threads...



Side Issue:

Programs linking to libnidaqmxbase.so segfault on exit if they complete too quickly.
This is possibly related to Miguel Ãngel (maht), klt, and tivoter123's problem.
http://forums.ni.com/ni/board/message?board.id=250&message.id=35359

Workaround: Take more time before exiting.

Details: (see wait* in attached tarball)

It is interesting that wait and wait_pthread_ldl both segfault in WStartTimeer(),
but do so in different subfunctions (402396be vs b77ee6be).
I don't know if that is significant.

==> gdb_wait_core <==
Program terminated with signal 11, Segmentation fault.
#0 0x402396be in ?? () from /usr/local/lib/liblvrtdark.so.8.0
(gdb) bt
#0 0x402396be in ?? () from /usr/local/lib/liblvrtdark.so.8.0
#1 0x40239855 in WStartTimer () from /usr/local/lib/liblvrtdark.so.8.0
...

==> gdb_wait_pthread_ldl_core <==
Program terminated with signal 11, Segmentation fault.
#0 0xb77ee6be in ?? () from /usr/local/lib/liblvrtdark.so.8.0
(gdb) bt
#0 0xb77ee6be in ?? () from /usr/local/lib/liblvrtdark.so.8.0
#1 0xb77ee855 in WStartTimer () from /usr/local/lib/liblvrtdark.so.8.0
...

Any thoughts?

Trevor
0 Kudos
Message 1 of 9
(3,287 Views)
Oops, got confused with the attachments.
The tarball seems to unpack fine, sorry about the tar2.gz extension...
0 Kudos
Message 2 of 9
(3,286 Views)

Hello Wtking,

I am not sure I understand your question.  Please clarify what the question you have is.  Also include what hardware models and software versions you are using.

Regards,

Ima
Applications Engineer
National Instruments
LabVIEW Introduction Course - Six Hours
Getting Started with NI-DAQmx
0 Kudos
Message 3 of 9
(3,263 Views)
Ima,

Sorry I was unclear...

Problem:

I am attempting to reproduce the synchronized analog IO demonstrated in LabVIEW here
 Timing and Synchronization Features of NI-DAQmx
 http://zone.ni.com/devzone/cda/tut/p/id/4322
 See figure 2

I don't understand the results of my tests well enough to summarize my current understanding, see the `notes' file in the tarball for what I've tried.

Basically, I'm hoping someone's already figured out this `common use case' on NIDAQmxBase.
Ubuntu is not officially supported, so it's possible that it's just a driver-on-ubuntu issue.

system from the sys_output file in the tarball:

$ uname -a
Linux loki 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3007
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) 3007
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
$ rpm -la
nispyi-2.4.0-f0
nirpci-3.3.0-f0
nidimi-1.5.0-f0
nicvirte-8.0-5
nivisa-4.0.0-f0
nivisa-config-4.0.0-f0
nidaqmxbase-usb-support-2.1.0-f0
nidaqmxbase-cinterface-2.1.0-f0
nidaqmxbase-labview80-VIs-2.1.0-f0
nikali-1.6.0-f0
nipali-1.11.1-f0
niorbi-1.5.0-f0
nipxirmi-1.6.0-f0
labview80-rte-8.0.1-1
nivisa-devel-4.0.0-f0
nivisaserver-4.0.0-f0
nidaqmxbase-board-support-2.1.0-f0
nidaqmxbase-common-2.1.0-f0
nidaqmxbase-labview82-VIs-2.1.0-f0
$ lsdaq
--------------------------------
Detecting National Instruments DAQ Devices
Found the following DAQ Devices:
NI 6052E:    "Dev1"    (PXI3::13::INSTR)
--------------------------------

Thanks,
Trevor

p.s.
If it would be more convenient, I could attach the 13 files in the tarball seperately.
Let me know if anyone wants the contents, but doesn't have access to tar or gzip.

0 Kudos
Message 4 of 9
(3,254 Views)

Hi Trevor,

From my understanding, the program in the "Timing and Synchronization Features in DAQmx" Developer Zone article does what you need for your application.  The only problem is that you are using Linux and DAQmx Base.  You should be able to re-build this code in DAQmx base using the DAQmx Base VI's.  The only differences are:

  1.  You will need to add DAQmx Base create task VI's before your create channel VI's
  2.  You will need to type in your device names.  DAQmx Base does not have drop down menus the way DAQmx does. 

I hope this helps!Smiley Happy

Regards,

Ima
Applications Engineer
National Instruments
LabVIEW Introduction Course - Six Hours
Getting Started with NI-DAQmx
0 Kudos
Message 5 of 9
(3,225 Views)
Ima,

I do create tasks explicity in my simult_AIO.c program (in the tarball).
Other than that, the program is pretty much a direct translation of the `Timing and Synchronization Features of NI-DAQmx' vi to NIDAQmxBase.

I expected it to work, as you said, but when I configured the AO task to use the /Dev1/ai/SampleClock, I got:
"
An attempt has been made to perform a route when the source and the destination are the same terminal.
"

And when I tried the obvious alternative of configuring  the AI task to use the /Dev1/ao/SampleClock, I got :
"
This routing is not possible in DAQmx Base because only one operation of the board is supported at a time.
"

I go over all this in the `notes' file in the tarball, and you should be able to reproduce them on a POSIX setup of your choice by running `make' in the decompressed tarball directory.

Thanks for your time,
Trevor
0 Kudos
Message 6 of 9
(3,198 Views)
Hi Trevor,

There are some things to be aware of when using DAQmx Base in C.  As is mentioned in the KnowledgeBase article: KB 3STFET46: Synchronizing Tasks in DAQmx Base - ANSI C the sample clocks cannot be directly routed in C.  The workaround is to trigger the AI and AO from the same source so they begin at the same time.  You should be able to use the ai/StartTrigger to trigger the analog output task. 

Even in LabVIEW, there are some differences between DAQmx and DAQmx Base.  The way that you are configuring the sample clock for both tasks will work in DAQmx.  When using DAQmx Base in LabVIEW however, you cannot implicitly route the sample clock from the analog input task to the analog output task.  You would have to use DAQmx Base Export Signal VI which you can use to route the ai sample clock to a PFI line.  You can then use that PFI line as the source of the DAQmxBase Timing VI for the AO task. 


Best Regards

Hani R.
Applications Engineer
National Instruments
0 Kudos
Message 7 of 9
(3,181 Views)
Hani,

I don't know how I missed that knowledge base article in my searching.
Oh well, a learning experience :p.
Could you elaborate on what the
"
will closely approximate task synchronization.
"
qualification to the shared start trigger means?
I'd expect that sharing the same actual clock, or sharing a start trigger and identically divided versions of the master clock would yield exactly the same results.
Perhaps the start trigger/clocking synchronization is jittery enough to skip a beat at high sampling rates?
That seems unlikely, but I can't think of any other differences...
Would your suggested DAQmxBase command be
"
DAQmxBaseCfgDigEdgeStartTrig (outTask, "/Dev1/ai/StartTrigger", DAQmx_Val_Rising);
"
?
I imagine AI task triggers off the rising edge by default.
I suppose the 'Dig' in the name confused me the first time round ;).

As for the PFI trick, I started down that road, and triggering AI off /Dev1/PFI5 got all the way to DAQmxBaseReadAnalogF64 before crashing (see test_output in the tarball).
I imagine it crashed since I had no signal going into the PFI ;).
I couldn't figure out how to exporting the AO sample clock to PFI5.
Line 1303 of /usr/local/include/NIDAQmxBase.h is
"
//int32 DllExport __CFUNC     DAQmxBaseExportSignal                (TaskHandle taskHandle, int32 signalID, const char outputTerminal[]);
"
so I figured I couldn't export signals...
Is there a way to export signals from DAQmx base?
In any event, I expect I'd have to export the AO sample clock on PFI5, physically wire PFI5 to another PFI, and use the second PFI as an inport for the AI sample clock, since trying to trigger of an export PFI probably doesn't work.

In the meantime, I have started experimenting with Comedi drivers, since they had a register-level access API all set.
I'm currently using the shared AI-start-trigger-and-independent-clocks method, which I turned up in the PFI chapter of the DAQ-STC manual.
It currently works about 80% of the time, and doesn't update the output at all the other 20%.
I'll post a link here if I get that straightened out.

Thanks,
Trevor

0 Kudos
Message 8 of 9
(3,161 Views)
Hi Trevor,

You are correct in stating that sharing the StartTrigger and using the identical divide down of the master clock will give you fully synchronized AI and AO tasks.  The KnowledgeBase article will need to be edited to remove the ambiguity. 

You will not be able to export the AO sample clock to a PFI line using DAQmxBase in C.  You can export the clock in LabVIEW by using the Export Signal VI.  In your case, the best option is to use the ai/StartTrigger to synchronize AI and AO. 

The command you referenced (DAQmxBaseCfgDigEdgeStartTrig (TaskHandle taskHandle, const char triggerSource[ ], int32 triggerEdge);) is the one that you would use to trigger the AO task.  Specifying the trigger edge to be DAQmx_Val_Rising or DAQmx_Val_Falling will determine whether or not you trigger off of the rising or falling edge.  


Best Regards

Hani R.
Applications Engineer
National Instruments
0 Kudos
Message 9 of 9
(3,143 Views)