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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: 2 MAXv problems
From: Eric Norum <eric@norum.ca>
To: "Ernest L. Williams Jr." <ernesto@slac.stanford.edu>
Cc: EPICS <tech-talk@aps.anl.gov>
Date: Wed, 10 Mar 2010 21:05:46 -0800
On Mar 10, 2010, at 9:02 PM, Ernest L. Williams Jr. wrote:

> Ron Sluiter wrote:
>> Eric Norum wrote:
>>> "I have also conditionally added your fix for sprintf() not callable from the RTEMS interrupt context ..."
>>> 
>>> I wasn't aware that sprintf() was legal to call from an interrupt context on vxWorks.  Or did I misunderstand the change?
> I think sprintf is reentrant in vxWorks and doesn't block.

But that still doesn't mean that it's safe to call from an interrupt handler.  It may use instructions or resources that are not saved on entry nor restored on return from an interrupt handler.  The vxWorks documentation to which I have access does not include sprintf on the list of functions callable from an interrupt handler.

> 
> 
> Cheers,
> Ernest
> 
> 
> 
>> Hello Eric,
>> 
>> No. You did not misunderstand the changes.  I was not aware that sprintf() is
>> an illegal call from a VxWorks ISR.  Now that I look more closely at the
>> restrictions you pointed out; there is very little allowed from a VxWorks
>> ISR; e.g., no ANSI string library calls, strcpy(), strlen(), etc.
>> 
>> I guess if I really want an error message sent from an ISR I will have to a
>> assemble it using stone tools and animal skins.
>> 
>> Thanks for catching this error.
>> 
>> Hello Jens,
>> 
>> I have redone the MAXv ISR error messages using a version of your code.
>> 
>> The latest (unreleased) version is available here;
>> https://subversion.xor.aps.anl.gov/synApps/motor/trunk/motorApp/OmsSrc/drvMAXv.cc 
>> 
>> Ron
>> 
>>> 
>>> 
>>> On Mar 8, 2010, at 1:18 PM, Ron Sluiter wrote:
>>> 
>>>> Hello Jens,
>>>> 
>>>> The common code for the old device support record
>>>> initialization; "motor_init_record_com()" was not always
>>>> passing positive encoder ratio values.  This has been a
>>>> bug for a long, long time that is now fixed.
>>>> 
>>>> I have also conditionally added your fix for sprintf()
>>>> not callable from the RTEMS interrupt context to the
>>>> MAXv ISR.
>>>> 
>>>> Both of these changes will be available, soon, in the
>>>> next release.
>>>> 
>>>> Thanks for pointing out these problems,
>>>> Ron
>>>> 
>>>> 
>>>> Jens.Eden@ptb.de <mailto:Jens.Eden@ptb.de> wrote:
>>>>> Hello Ron,
>>>>> 
>>>>> 
>>>>>> but the motor record has not issued negative
>>>>>> encoder ratio commands for a long time.
>>>>>>   
>>>>> here is an extract of the boot messages with drvMAXvdebug=10, while autosave writes -5.55123456e-06 to the ERES-field.
>>>>> 
>>>>> -- 
>>>>> send_mess: sent card 0 message:'
>>>>> AX  ER-180140,52359 UU-3.440496
>>>>> -- 
>>>>> This command (ER-180140,52359) does not work for
>>>>> current firmware versions.
>>>>> 
>>>>> 
>>>>>> Are you using a really old
>>>>>> version of the motor record?
>>>>>>   
>>>>> No, this is the motorR6-4-4
>>>>> EpicsRelease 3.14.11
>>>>> 
>>>>> Jens
>>>>> _______________________________
>>>>> Jens Eden
>>>>> Physikalisch-Technische Bundesanstalt
>>>>> Albert-Einstein-Straße 15
>>>>> 12489 Berlin
>>>>> 
>>>>> Tel +49 30 6392-5086
>>>>> Fax +49 30 6392-5082
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Von:
>>>>> Ron Sluiter <sluiter@aps.anl.gov <mailto:sluiter@aps.anl.gov>>
>>>>> An:
>>>>> Jens.Eden@ptb.de <mailto:Jens.Eden@ptb.de>
>>>>> Kopie:
>>>>> tech-talk@aps.anl.gov <mailto:tech-talk@aps.anl.gov>
>>>>> Datum:
>>>>> 05.03.2010 21:12
>>>>> Betreff:
>>>>> Re: 2 MAXv problems
>>>>> 
>>>>> 
>>>>> 
>>>>> Hello Jens
>>>>> 
>>>>> There has been a recent (R6-4 and above) fix to prevent intermittent MAXv command
>>>>> errors from occurring when User Units are turned off, but the motor record has not
>>>>> issued negative encoder ratio commands for a long time.  Are you using a really old
>>>>> version of the motor record?
>>>>> 
>>>>> Ron
>>>>> 
>>>>> 
>>>>> Jens.Eden@ptb.de <mailto:Jens.Eden@ptb.de> wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> I found, that in recent firmware versions (1.31) of the MAXv cards the command to set
>>>>>> negative encoder resolutions (e.g. "AX ER-2,3") as used by the MAXv     
>>>>> driver  
>>>>>> does not work any more.
>>>>>> Instead a command error is returned and the encoder resolution will     
>>>>> remain  
>>>>>> unchanged.
>>>>>> I couldn't find this "new feature" documented anywhere.
>>>>>> 
>>>>>>   
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> -- 
>>> Eric Norum
>>> eric@norum.ca <mailto:eric@norum.ca>
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 

-- 
Eric Norum
eric@norum.ca






Replies:
Re: 2 MAXv problems Ernest L. Williams Jr.
References:
2 MAXv problems Jens . Eden
Re: 2 MAXv problems Ron Sluiter
Re: 2 MAXv problems Jens . Eden
Re: 2 MAXv problems Ron Sluiter
Re: 2 MAXv problems Ron Sluiter
Re: 2 MAXv problems Ernest L. Williams Jr.

Navigate by Date:
Prev: Re: 2 MAXv problems Ernest L. Williams Jr.
Next: Re: 2 MAXv problems Ernest L. Williams Jr.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: 2 MAXv problems Ernest L. Williams Jr.
Next: Re: 2 MAXv problems Ernest L. Williams Jr.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·