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

Subject: RE: Newport XPS-Q8 and Motor Record - armv5teb architecture
From: Tonia Batten <Tonia.Batten@lightsource.ca>
To: Torsten Bögershausen <torsten.bogershausen@esss.se>, "Johnson, Andrew N." <anj@aps.anl.gov>, "Rivers, Mark L." <rivers@cars.uchicago.edu>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 9 May 2014 13:13:34 -0600
Good Morning,

Thank you for all of your responses/suggestions.  I want to provide feedback on a fix currently in place for this problem.  

I was incorrect about the variation in the values being a result of a conversion, the value was being altered when it being assigned to pmsg->dvalue.  When we added a statement to print values right after the assignment Mark discovered that a value of zero was being printed before the queueRequest.  

Mark then suggested that the problem may be associated with memory allocation and recommended that following changes in devMotorAsyn.  This has resolved the problem.

devAsynMotor::build_trans
    /*pmsg = pasynManager->memMalloc(sizeof *pmsg);*/
pmsg = (motorAsynMessage *)malloc(sizeof *pmsg);


devAsynMotor::asynCallback
    /*pasynManager->memFree(pmsg, sizeof(*pmsg));*/
free(pmsg);

Note: I was not able to compile a new version that Mark provided with the__sync_synchronize call before the queue request because the cross compiler we are using for the Moxa DA-662 equipment is old. (__sync_synchronize was added in gcc 4.4.0).  The tool chain we are using is using gcc 3.4.3.  Unfortunately I have not been able to find a newer tool chain for this equipment.

All testing was done with the following:
Epics.R3.14.12.4
asyn 4-22
motor 6-8
seq 2-1-13

The intent is to collect additional information so that the memory allocation issue on the armv5teb architecture can be addressed.

Thank you again for everyone's input!!  It is greatly appreciated!!

Regards, Tonia


-----Original Message-----
From: Torsten Bögershausen [mailto:torsten.bogershausen@esss.se] 
Sent: May-08-14 12:14 AM
To: Johnson, Andrew N.; Rivers, Mark L.
Cc: tech-talk@aps.anl.gov; Tonia Batten
Subject: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture



On 5/7/14 11:32 PM, Johnson, Andrew N. wrote:
> Hi Mark,
>
> You could try adding a call to the gcc built-in routine __sync_synchronize(); after the last write to the asynUser structure. This implements a full memory barrier, which is equivalent to the two memory barriers inside the mutex operations. If this fixes it for ARM there is probably a better solution, but this will at least identify if this is the cause of the problem.

This would be needed on a multi-core system.

What system is in use ?
single core or multi core?

I just got the motor simulator working on the Raspberry PI, (after some days of debugging) The trick was to use this block in motorApp/MotorSrc/motor.h:

==============
/* Define, from top to bottom, how bit fields are packed. */
/* This works for gnu, SunPro, MS Visual C. */ #include <epicsEndian.h> #if (EPICS_BYTE_ORDER == EPICS_ENDIAN_LITTLE)
     #define LSB_First (TRUE)
     #warning LSB_First
#endif

#if (EPICS_BYTE_ORDER == EPICS_ENDIAN_BIG)
     #define MSB_First (TRUE)
     #warning MSB_First
#endif


===============

What do you get when you compile with this change ? MSB_First or LSB_First ?






References:
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture J. Lewis Muir
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Stephen Beckwith
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Stephen Beckwith
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Jens Eden
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture J. Lewis Muir
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Johnson, Andrew N.
RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Mark Rivers
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Johnson, Andrew N.
Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Torsten Bögershausen

Navigate by Date:
Prev: Portable Channel Access Server Event Queue Christopher J. Pendleton
Next: CSS: The difference among Javascript 、Python Script and Execute Command hongchunxia
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: Newport XPS-Q8 and Motor Record - armv5teb architecture Torsten Bögershausen
Next: RE: Newport XPS-Q8 and Motor Record - armv5teb architecture Tonia Batten
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·