Sorry for my previous incomplete reply. Here is the complete one:
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 non-asyn-based 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"). The limitation of not setting the values of fields *VL is that you only can write a value ranged from 0 to 15 to a hardware/record link.
I guess the reason why you got this problem is that the asyn mbbo device support uses the RVAL instead of VAL and the RVAL is always 0 when the values of fields *VL are all zeros.
2. I strongly agree with Ralph that it is better to use the index (option number) if and only if all ..VL fields are zeros in the mbbo record support. There are many ways to implement this change. One simple way is to add a few codes at the convert( ) in mbboRecord.c:
epicsUInt32 *pvalues = &(prec->zrvl);
epicsUInt32 valuesSum = 0;
int i = 0;
for (i=0; i<15; i++) valuesSum += pvalues[i];
/* convert val to rval */
//if(prec->sdef) {
if(prec->sdef && (valuesSum>0)) {
Then rebuild your EPICS base and your driver. Please give a try and let me know how it works.
Cheers,
Yong
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 |
>>> ----------------------------------------
>>>
>>
- References:
- Re: AsynInt32 device support and mbbo records Ralph Lange
- Re: AsynInt32 device support and mbbo records Hu, Yong
- Navigate by Date:
- Prev:
Re: AsynInt32 device support and mbbo records Hu, Yong
- Next:
Spring 2013 EPICS Collaboration Meeting: Registration Open ian.gillingham
- 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
- Navigate by Thread:
- Prev:
Re: AsynInt32 device support and mbbo records Hu, Yong
- Next:
RE: AsynInt32 device support and mbbo records Mark Rivers
- 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
|