[ARTIQ] PXI6733 controller
Hello, I'm trying to implement a controller for NI PXI 6733 even if I didn't receive the hardware yet. First task was to pick a library/driver to control it. So far I found 4 python libraries: PyDAQmx, pylibdaqmx, pycomedilib (debian package name python-comedilib) and pycomedi. I wasn't able to make any of them work under Linux for various reasons (python 3 vs python 2, or crashing while loading some shared library). I was able to import and call a few functions (under Windows 7) of PyDAQmx which makes it a potential candidate. Is the PXI 6733 used on Linux machines? Is there a real need for a Linux controller? Thanks! Regards, -- Yann ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] PXI6733 controller
Thank you for the question Yann. I spoke with John Gabler and Dan Slichter here at NIST and came up with the following advice. There's no need for the 6733 controller to run on a Linux machine. I've found the NI libraries on Windows to be reasonably straightforward (NI-DAQmx libraries with C++). I recommend building to a binary.dll then writing a python interface (using e.g. ctypes) for artiq. I'll send you a copy of the code we currently use as part of our HFgui environment. I recommend taking a look at QC-DAQ\src\6733wfm to see how this was coded in the past; reuse as much as you can. From an interface perspective it would be excellent if the 6733 looked identical to the PDQ interface. Some differences: * 6733 doesn't support waveform branching * The "waveform advance" pulse to the 6733 is what causes its output to transition from one ADC channel (voltage) to another. We usually generate this pulse from the FPGA not from a periodic clock (eg crystal oscillator). This makes it possible to a) conserve memory on the 6733 when a static output is desired and b) reduce noise on the 6733 analog outputs (its more noisy when being clocked). -Joe On Tue, Jan 20, 2015 at 3:55 AM, Yann Sionneau wrote: > Hello, > > I'm trying to implement a controller for NI PXI 6733 even if I didn't > receive the hardware yet. > First task was to pick a library/driver to control it. > > So far I found 4 python libraries: PyDAQmx, pylibdaqmx, pycomedilib > (debian package name python-comedilib) and pycomedi. > I wasn't able to make any of them work under Linux for various reasons > (python 3 vs python 2, or crashing while loading some shared library). > I was able to import and call a few functions (under Windows 7) of PyDAQmx > which makes it a potential candidate. > > Is the PXI 6733 used on Linux machines? Is there a real need for a Linux > controller? > > Thanks! > > Regards, > > -- > Yann > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] PXI6733 controller
On 01/22/2015 02:08 AM, Joe Britton wrote: > * The "waveform advance" pulse to the 6733 is what causes its output to > transition from one ADC channel (voltage) to another. We usually > generate this pulse from the FPGA not from a periodic clock (eg crystal > oscillator). This makes it possible to a) conserve memory on the 6733 > when a static output is desired and b) reduce noise on the 6733 analog > outputs (its more noisy when being clocked). Does the FPGA need to generate one pulse per DAC sample? Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] PXI6733 controller
> Does the FPGA need to generate one pulse per DAC sample? Yes, one pulse is required per sample. One way of doing this might be to have a fixed frequency clock that is gated by a RTIO channel. On Wed, Jan 21, 2015 at 7:46 PM, Sébastien Bourdeauducq wrote: > On 01/22/2015 02:08 AM, Joe Britton wrote: > > * The "waveform advance" pulse to the 6733 is what causes its output to > > transition from one ADC channel (voltage) to another. We usually > > generate this pulse from the FPGA not from a periodic clock (eg crystal > > oscillator). This makes it possible to a) conserve memory on the 6733 > > when a static output is desired and b) reduce noise on the 6733 analog > > outputs (its more noisy when being clocked). > > Does the FPGA need to generate one pulse per DAC sample? > > Sébastien > > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] PXI6733 controller
On 01/22/2015 01:07 PM, Joe Britton wrote: > Yes, one pulse is required per sample. One way of doing this might be to > have a fixed frequency clock that is gated by a RTIO channel. I'd rather put that oscillator in the FPGA, as it would need to be synchronized with the RTIO core to get repeatable sample counts. Should the clock frequency be configurable at runtime as well (as opposed to bitstream synthesis time)? Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] PXI6733 controller
>Should the clock frequency be configurable at runtime as well (as opposed to >bitstream synthesis time)? Runtime reconfiguration would be more flexible. I'd aim for reconfigurable at runtime if FGPA resources are available to support it. -Joe On Wed, Jan 21, 2015 at 10:15 PM, Sébastien Bourdeauducq wrote: > On 01/22/2015 01:07 PM, Joe Britton wrote: > > Yes, one pulse is required per sample. One way of doing this might be to > > have a fixed frequency clock that is gated by a RTIO channel. > > I'd rather put that oscillator in the FPGA, as it would need to be > synchronized with the RTIO core to get repeatable sample counts. Should > the clock frequency be configurable at runtime as well (as opposed to > bitstream synthesis time)? > > Sébastien > > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] PXI6733 controller
Hello Joe, Le 21/01/15 19:08, Joe Britton a écrit : > Thank you for the question Yann. I spoke with John Gabler and Dan Slichter > here at NIST and came up with the following advice. > > There's no need for the 6733 controller to run on a Linux machine. Ok > I've found the NI libraries on Windows to be reasonably straightforward > (NI-DAQmx libraries with C++). I recommend building to a binary.dll then > writing a python interface (using e.g. ctypes) for artiq. Actually I was thinking about using the PyDAQmx project ( http://pythonhosted.org/PyDAQmx/ ) and provide a direct access to the PyDAQmx API through the ARTIQ RPC mechanism. The PyDAQmx API being itself a direct wrapping/binding of the NI DAQ mx ANSI C driver API. So for instance you would be able in your ARTIQ client to directly call the following methods of the RPC'd object: - DAQmxCreateTask() - DAQmxCreateAIVoltageChan() - DAQmxCfgSampClkTiming() - DAQmxStartTask() - DAQmxReadAnalogF64() - DAQmxStopTask() - DAQmxClearTask() ... and so on. Would this be acceptable? > > I'll send you a copy of the code we currently use as part of our HFgui > environment. I recommend taking a look at QC-DAQ\src\6733wfm to see how > this was coded in the past; reuse as much as you can. From an interface > perspective it would be excellent if the 6733 looked identical to the PDQ > interface. See above for what I had in mind for the API. You mean you want the interface/API to look like the current ARTIQ PDQ2 driver API? ( https://github.com/m-labs/artiq/blob/master/artiq/devices/pdq2/driver.py ). It seems pretty low level. > Some differences: > * 6733 doesn't support waveform branching > * The "waveform advance" pulse to the 6733 is what causes its output to > transition from one ADC channel (voltage) to another. We usually generate > this pulse from the FPGA not from a periodic clock (eg crystal oscillator). > This makes it possible to a) conserve memory on the 6733 when a static > output is desired and b) reduce noise on the 6733 analog outputs (its more > noisy when being clocked). > > -Joe > > > > On Tue, Jan 20, 2015 at 3:55 AM, Yann Sionneau wrote: > >> Hello, >> >> I'm trying to implement a controller for NI PXI 6733 even if I didn't >> receive the hardware yet. >> First task was to pick a library/driver to control it. >> >> So far I found 4 python libraries: PyDAQmx, pylibdaqmx, pycomedilib >> (debian package name python-comedilib) and pycomedi. >> I wasn't able to make any of them work under Linux for various reasons >> (python 3 vs python 2, or crashing while loading some shared library). >> I was able to import and call a few functions (under Windows 7) of PyDAQmx >> which makes it a potential candidate. >> >> Is the PXI 6733 used on Linux machines? Is there a real need for a Linux >> controller? >> >> Thanks! >> >> Regards, >> >> -- >> Yann >> ___ >> ARTIQ mailing list >> https://ssl.serverraum.org/lists/listinfo/artiq >> ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] PXI6733 controller
On 01/27/2015 03:48 AM, Yann Sionneau wrote: > Actually I was thinking about using the PyDAQmx project ( > http://pythonhosted.org/PyDAQmx/ ) and provide a direct access to the PyDAQmx > API through the ARTIQ RPC mechanism. > The PyDAQmx API being itself a direct wrapping/binding of the NI DAQ mx ANSI > C driver API. > > So for instance you would be able in your ARTIQ client to directly call the > following methods of the RPC'd object: > - DAQmxCreateTask() > - DAQmxCreateAIVoltageChan() > - DAQmxCfgSampClkTiming() > - DAQmxStartTask() > - DAQmxReadAnalogF64() > - DAQmxStopTask() > - DAQmxClearTask() > ... and so on. > > Would this be acceptable? That should be fine for the controller part of the driver. Experiments using it will need another (local) class to provide higher level functions (that look like the PDQ API) and integration with the core device to generate the precisely timed waveform advance pulses. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] PXI6733 controller
Hello Joe, Le 28/01/15 04:22, Joe Britton a écrit : > I was thinking that the high-level interface would look as close as > possible to that for the PDQ DACs. See attached PDFs for the waveform > description language that we use in our current .dc files. -Joe Ok agreed for the low-level API then. About the high-level one, I'm not sure I understand which one exactly you are talking about. Do you have a document (or piece of code) which describes what kind of high-level API you expect to drive the DAC? Thanks! Regards, -- Yann ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
