1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 <2013> 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: Thorlabs USB Hardare with EPICS |
From: | Mark Rivers <[email protected]> |
To: | "'Sorgenfrei, Florian'" <[email protected]>, "[email protected]" <[email protected]> |
Date: | Wed, 21 Aug 2013 17:28:59 +0000 |
Hi Florian, You would need to write an asyn port driver that is specific to USBTMC. USBTMC is basically like GPIB over USB. This driver will be similar to the VXI-11 driver, which is basically GPIB over Ethernet.
That driver would implement the asynOctet interface, just like the drvAsynSerialPort driver does. That should not be difficult. You need to implement the ioctl for special operations.
The following is from this document: http://www.home.agilent.com/upload/cmc_upload/All/usbtmc.html?&cc=US&lc=eng ******************************** ioctl(2): Special operations As show in the above examples, ioctl(2) is used for special operations (everything that goes beyond text-based communication). The second parameter to ioctl(2) is a request code which indicates what kind of special operation you want the driver to perform.
Valid request codes are defined in usbtmc.h. They are: USBTMC_IOCTL_GET_CAPABILITIES This request is used to get information about the device's capabilities. In this case, the third parameter to ioctl(2) is a pointer to a structure of type struct usbtmc_dev_capabilities (defined in usbtmc.h). This structure is filled by ioctl. See usbtmc.h
and the USBTMC specification for details. USBTMC_IOCTL_INDICATOR_PULSE This request asks the device to light its activity indicator for identification purposes. This is an optional capability and may not be available with your device. Inspect the device's capability values when in doubt. In this case, the third parameter to
ioctl(2) is not used. USBTMC_IOCTL_CLEAR This request is used to clear the device's input and output buffers. It is roughly equivalent to a GPIB device clear. In this case, the third parameter to ioctl(2) is not used. USBTMC_IOCTL_ABORT_BULK_OUT This requests aborts the last USBTMC BULK OUT operation, i.e. the last write operation to the device's command buffer. It is used to recover from I/O errors that occur during a write operation. Note that you can instruct the driver to do the abort automatically
if an I/O error occurs. See
Reference: Attributes for details. In this case, the third parameter to ioctl(2) is not used. … ******************************** Mark From: [email protected] [mailto:[email protected]]
On Behalf Of Sorgenfrei, Florian Hi,
> updating to a more recent kernel.
>
> Guy Jennings
>
> On Aug 2, 2013, at 10:36 AM, Eric Norum <[email protected]> wrote:
>
>> Since you can communicate with the unit using simple shell commands I'm inferring that the unit presents itself as a USB-connected serial port. Standard StreamDevice + ASYN support should work fine.
>>
>> On Aug 2, 2013, at 5:42 AM, "Drube, Hardy" <[email protected]> wrote:
>>
>>> Dear all,
>>>
>>> I have some problems to establish a longer lasting connection with a Thorlabs PM100USB Powermeter.
>>>
>>> It is listed in /dev as usbtmc0 and I can communicate with it through echo –e. But this is only possible for one time. A second time echo –e won’t work. I have to disconnect and reconnect the USB-cable. Then again it will work one time.
>>> Could you help me with this problem?
>>>
>>> Note: This device has two chips, the first one is a XILINX XCR3064XL (AD Converter) and the second a NXP LPC2387FBD100.
>>>
>>> Best regards,
>>> Hardy Drube
>>>
>>
>> --
>> Eric Norum
>> [email protected]
>>
|