01-04-2010 05:33 PM
When I try and call the DAQmxSetTrigAttribute function which is part of DAQmx(8.6.1) from python I receive the following error.
nidaq.DAQmxSetTrigAttribute( self.taskHandle,DAQmx_StartTrig_Retriggerable,True)
ValueError: Procedure probably called with too many arguments (12 bytes in excess)
The input parameters are defined as follows
TaskHandle = uInt32
DAQmx_StartTrig_Retriggerable = int32(6415)
I have been able to successfully call many of the other functions from the nidaq library but this one is being difficult. I believe that it is related to the function declaration which is as follows in the NIDAQmx.h
int32 __CFUNC_C DAQmxSetTrigAttribute (TaskHandle taskHandle, int32 attribute, ...);
I have tried specifying the input parameters with argtypes but, that didn't seem to work.
What is CFUNC_C and why the ... at the end of the declaration?
Please Help
Darren
01-04-2010 06:06 PM
Hey Darren,
The ... is a way of doing an optional parameter in C or an inferred data type (like printf). You might try declaring a uInt32 variable explicitlyand passing those for that parameter and assigning that to 1 (the True constant might be the problem).
Alternatively, I'd recommend using DAQmxSetStartTrigRetriggerable(TaskHandle taskHandle, bool32 data) in your case.
01-04-2010 06:43 PM
Hi Darren,
As for the other part of your question, __CFUNC_C is a macro (#defined at the top of the file) that selects the __cdecl calling convention. The DAQmx ANSI C API uses the __stdcall calling convention almost everywhere else, but __stdcall cannot be used with varargs functions (those that use "...").
Brad
06-11-2013 10:27 AM
Hi Andrew,
I've been having a similar issue to Darren. I started off trying to use DAQmxSetStartretriggerable(TaskHandle taskHandle, bool32 data), however this always returns an error:
RuntimeError: DAQmxSetStartTrigRetriggerable(AnalogOutputTask('_unnamedTask<0>'), c_ulong(1L)):
Specified property is not supported by the device or is not applicable to the
task.
I'm using a PCI-6733 analog out card, for which retriggering is entirely essential, and when I check the specifications online I see that retriggering is certainly supported for the device.
My next attempt was to try what Darren tried- use the DAQmxSetTrigAttribute function- but of course I likewise couldn't figure out how to perform the optional call properly.
Please let me know if you have any suggestions,
David
06-11-2013 04:29 PM
Hi David,
That property is supported for counter output tasks on your device, but not for analog output tasks. You can use the general purpose counters to generate a retriggerable finite pulse train, and then use that as your AO sample clock. See Can I Retrigger Analog Output with an E Series Data Acquisition (DAQ) Device? for more info and a link to an example.
X Series and SC Express allow you to enable retriggering on AI/AO tasks directly, but most other devices require using a general purpose counter to do this.
Brad
06-11-2013 06:51 PM
Brad,
Thanks so much. I'm finding it hard to believe that the AO is not retriggerable though for the following reasons:
1. When I go to the NI-DAQmx C Reference Help section for the PCI 6733: http://zone.ni.com/reference/en-XX/help/370471W-01/mxcprop/attr190f/ it explicitly lists Retriggerable under NI PCI-6733 Supported Properties, stating:
Specifies whether a finite task resets and waits for another Start Trigger after the task completes. When you set this property to TRUE, the device performs a finite acquisition or generation each time the Start Trigger occurs until the task stops. The device ignores a trigger if it is in the process of acquiring or generating signals.
2. When I look at the hardware corresponding to the instructions you linked me to: http://zone.ni.com/devzone/cda/epd/p/id/4787, the PCI-6733 is NOT listed among the hardware models.
3. When I communicate with the card via matlab's daq toolbox, it furnishes a property called "TriggersPerRun" that I can set to Inf to achieve re-triggering. I suppose matlab could be facilitating this via the counter output function, but it just seemed unusual to me.
Lastly just to make sure I am understanding the support page you linked me to properly well enough to pursue python implementation- I set my analog output channels to be triggered once and then to run continuously; I fix the clock rate according to the internal counter output; I can configure the counter output channel to be retriggerable by the external trigger input, and then the analog out will always be stnced up with the trigger, the counter output doesn't actually need to be physically connected.
Thanks again!
David
06-11-2013 08:52 PM - edited 06-11-2013 08:53 PM
Hi David,
1. When I go to the NI-DAQmx C Reference Help section for the PCI 6733: http://zone.ni.com/reference/en-XX/help/370471W-01/mxcprop/attr190f/ it explicitly lists Retriggerable under NI PCI-6733 Supported Properties...
Is this the page you meant? http://zone.ni.com/reference/en-XX/help/370471W-01/cdaqmxsupp/pci-6733/
That page lists all of the properties supported by the PCI-6733, but not which channels support them. Start >> More >> Retriggerable is only supported for ctr0:1.
2. When I look at the hardware corresponding to the instructions you linked me to: http://zone.ni.com/devzone/cda/epd/p/id/4787, the PCI-6733 is NOT listed among the hardware models.
You're right, the list of hardware models on that page is missing some devices.
3. When I communicate with the card via matlab's daq toolbox, it furnishes a property called "TriggersPerRun" that I can set to Inf to achieve re-triggering. I suppose matlab could be facilitating this via the counter output function, but it just seemed unusual to me.
I'm afraid I can't help you there.
Lastly just to make sure I am understanding the support page you linked me to properly well enough to pursue python implementation-
Sorry, the web page doesn't have all of the details. Here are screenshots of the VI:
Key points:
Also, 3019.zip on http://zone.ni.com/devzone/cda/epd/p/id/2345 demonstrates retriggerable AI in C/C++, which might be helpful.
Brad