I agree with all that Joe has written in detail here. Basically, the motivation of the “generic driver” idea is to make it so that when someone wants to make a controller for a new type of hardware, they can do so by just tinkering with/expanding an existing controller template, rather than having to create the whole thing from scratch. This should hopefully reduce the chances of having broken/poorly written/poorly formatted drivers being written by scientists with widely varying Python experience trying to get something running in a hurry. Along these lines, commenting/documentation for the template (explaining why certain steps might be needed, for example) is important. These drivers will need to be a bit more complex (see Joe’s comments) than just the simple tutorial controller that has been written so far – something to get us to a point where you might just copy a template “set” or “get” method, change the commands (e.g. SCPI) inside, rename the method as appropriate, etc.
From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Joe Britton Sent: Wednesday, December 17, 2014 10:42 AM To: Sébastien Bourdeauducq; artiq@lists.m-labs.hk Subject: Re: [ARTIQ] PXI-6733 and other drivers Here's my take on this. > "Generic Devices with manufacturer-supplied DLL or C/C++ driver" This could be satisfied using ctypes and python. An example showing proper end-to-end coding is what I have in mind. Assume the PC hosting the hardware is running Windows 7 and a scientific python distribution, say, Enthought Canopy Express [0]. (1a) some generic code in C with functions passing a representative sample of types (char[10], int[10], double[10], my_struct[10]) (1b) instructions on how to compile to a suitable .dll (1c) example Controller using ctypes and Artiq methods (1d) error handling using exceptions or whatever method Artiq uses (1e) shell documentation using sphinx (or whatever we agree upon). > "Generic GPIB, USB, or RS232/485 Devices using VISA"? Similar to previous we'd like code templates. (2a) A properly implemented, robust interface to a generic serial device written in python 3. Assume the device manufacturer includes whatever HID driver is required to present the interface as a Windows serial port (eg port 3). (2b) Example of how to send/receive text commands and test that device responds properly (eg it echos back "OK\n"). (2c) Example of how to send/receive continuous stream of binary data. (2d) Example Controller using Artiq methods. (2e) Error handling using exceptions or whatever method Artiq uses. (2f) Documentation example using in-line sphinx annotation of the python (or whatever we agree upon). (2g) Windows has an unpleasant reality that there's not a static mapping between a particular USB-serial device and an assigned serial port. The mapping seems to depend on which physical port the device is plugged into and what other devices are in use on the system. So, upon launch it would be good if all serial ports registered on the host were polled to figure out which port is right for a particular Controller. Most devices have some sort of device-specific query and response strings (eg "ID?"). (3a) A light-weight, generic GPIB interface. I advocate we consolidate our lab setups to the Prologix USB-GPIB interface http://prologix.biz/ since this requires installing no drivers; the NI alternative works is $500 and requires installing about 1 GB of crud. The Prologix device presents to the host OS as a serial device and commands are sent/received GPIB text strings (e.g. GPIB formatted). While this is basically an application of (1a) it is helpful if it's a distinct example since configuring a prologix device requires a couple properly formatted text strings. (3b-f) as (2b-f) (3g) Most devices have some sort of device-specific query and response strings (eg "*IDN?"). Confirm upon startup the target device is responding as expected at the specified GPIB address. This prevents an accident where a hazardous device (eg high voltage or current) gets reprogrammed via random text strings intended for another piece of GPIB hardware. (4a) I think listing "USB" here was a bit sloppy on our part. If the device presents to the host OS as a serial port (eg USB-serial interface) I think (2a-g) fits the bill. If it presents to the host OS as some other sort of HID it's safe to assume that the vendor has supplied a DLL or C/C++ driver and (1a-e) applies. [0] https://store.enthought.com/downloads/ Note to ions... For convenience of documentation it would be helpful if we make a choice for a scientific python distribution for Windows. The two main contenders seem to be Enthought Canopy and Anaconda. -Joe On Wed Dec 17 2014 at 7:59:21 AM Sébastien Bourdeauducq <s...@m-labs.hk<mailto:s...@m-labs.hk>> wrote: Hi, are you still using the PXI-6733 DAC cards? If you do not need it, we can replace the driver with another one of similar complexity for another device. Also, what exactly do you expect from the "Generic Devices with manufacturer-supplied DLL or C/C++ driver" and the "Generic GPIB, USB, or RS232/485 Devices using VISA"? Sébastien _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
_______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
