EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  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  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: AsynInt32 device support and mbbo records
From: "Hu, Yong" <[email protected]>
To: Ralph Lange <[email protected]>, EPICS Tech-Talk <[email protected]>
Date: Sun, 17 Feb 2013 16:00:30 +0000
Hi Florian,

Here is my two points:

1. If you read the mbboRecord.c thoroughly, you will realize that you don't have to set the values of fields *VL (ZRVL, ONVL ... FFVL are all default to zero) if you use prec->val instead of prec->rval in the mbbo device support write routine (write_mbbo( )) to put the data of prec->val  to hardware/record link. But the RVAL will be always 0 in this case. I have developed an EPICS/Linux driver for one digitizer. The EPICS driver is based on the vendor's Linux APIs so that the driver doesn't access the digitizer's register directly. I always use the prec->val in the mbbo device support routines for this digitizer and I always ignore the configuration of *VL in the database. This works perfectly. Another way to test this is giving a try on a soft mbbo record (DTYP is "Soft Channel").

You may test this  


  epicsUInt32 *pvalues = &(prec->zrvl);
        epicsUInt32 pvaluesSum = 0;
        int i = 0;
        for (i=0; i<15; i++) pvaluesSum += pvalues[i];

        /* convert val to rval */
        //if(prec->sdef) {
        if(prec->sdef && (pvaluesSum>0)) {



On 2/15/13 5:27 AM, "Ralph Lange" <[email protected]> wrote:

>For 3.15:
>Should we change the record support to use the index (option number) if
>and only if all ..VL fields are zero?
>This would even match the regular soft support behavior that writes the
>index value.
>
>I can't imagine someone relying on device support always being called
>with zero, no matter which state the record is in.
>
>~Ralph
>
>
>On 02/15/2013 10:38 AM, Burkhard Kolb wrote:
>> Hi Florian,
>> yes, you have to set also the values. The numbering scheme
>>distinguishes between sixteen states,
>> but their value does not have to be 0, 1, 2, 4..., but could be
>>anything.
>>
>> Burkhard
>> --
>> Dr. Burkhard Kolb
>> Tel +49 6159 712667
>> GSI Helmholtzzentrum für Schwerionenforschung GmbH
>> Planckstraße 1 | D-64291 Darmstadt | www.gsi.de
>>
>> Gesellschaft mit beschränkter Haftung
>> Sitz der Gesellschaft: Darmstadt
>> Handelsregister: Amtsgericht Darmstadt, HRB 1528
>>
>> Geschäftsführung: Professor Dr. Dr. h.c. mult. Horst Stöcker, Peter
>>Hassenbach
>>
>> Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph
>> Stellvertreter: Ministerialdirigent Dr. Rolf Bernhardt
>>
>>
>>
>>
>> Am 15.02.2013 um 10:14 schrieb Florian Feldbauer:
>>
>>> Hey,
>>>
>>> I have written an AsynPortDriver for the TMCM142 1 axis stepper
>>>driver/controller
>>> The motor driver is connected via CAN bus and expects a message with 7
>>>bytes of data:
>>> byte 0: command number
>>> byte 1: parameter number (I'm using the addr parameter from the asyn
>>>interface)
>>> byte 2: motor number (only one motor can be connected to the driver so
>>>it is always 0)
>>> byte 3-6: data (32 bit signed int)
>>>
>>> For setting the microstep resolution of the motor driver the data has
>>>to be a number between
>>> 0 and 11, each coding a different resoultion.
>>> I wanted to use a mbbo record, which looks like this:
>>>
>>> record( mbbo, "PANDA:$(subsys):MOTOR:$(SECTOR):SAP:USTEPRESOLUTION" ) {
>>>  field( DTYP, "asynUInt32" )
>>>  field( OUT,  "@asyn($(BUS),27,1)TMCM142_SAP" )
>>>
>>>  field( ZRST, "2048 micro steps" )
>>>  field( ONST, "1024 micro steps" )
>>>  field( TWST, "512 micro steps" )
>>>  field( THST, "256 micro steps" )
>>>  field( FRST, "128 micro steps" )
>>>  field( FVST, "64 micro steps" )
>>>  field( SXST, "32 micro steps" )
>>>  field( SVST, "16 micro steps" )
>>>  field( EIST, "8 micro steps" )
>>>  field( NIST, "4 micro steps" )
>>>  field( TEST, "2 micro steps" )
>>>  field( ELST, "1 micro steps" )
>>> }
>>>
>>> Unfortunately, the value inside my writeInt32 function from the
>>>asynPortDriver is always 0.
>>> Do I have to set the ZRVL,...,ELVL fields for asynInt32? Or do I need
>>>another asyn interface for
>>> this record?
>>>
>>> Best regards,
>>> Florian
>>>
>>> -- 
>>> ----------------------------------------
>>> | Dr. Florian Feldbauer                |
>>> |                                      |
>>> | Helmholtz-Institut Mainz /           |
>>> | Johannes Gutenberg-Universität Mainz |
>>> | Johann-Joachim-Becher-Weg 45         |
>>> | D-55128 Mainz                        |
>>> |                                      |
>>> | Office: 01/217                       |
>>> | Phone:  (+49)6131 / 39-25829         |
>>> ----------------------------------------
>>>
>>

Replies:
RE: AsynInt32 device support and mbbo records Hu, Yong
References:
Re: AsynInt32 device support and mbbo records Ralph Lange

Navigate by Date:
Prev: RE: aSub MAX_ARRAY_SIZE increase Hu, Yong
Next: RE: AsynInt32 device support and mbbo records Hu, Yong
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: AsynInt32 device support and mbbo records Ralph Lange
Next: RE: AsynInt32 device support and mbbo records Hu, Yong
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·