linse/sics
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fixed a task and a tasdrive issue

Browse Source 
There is a rare condition when SICS has frehsly stared up and on the first call
to a coordinated driving, like in TAS, something fails. Then the group has ID 0,
the default and that one is always active. This has been fixed by starting valid
groups at 7, defining 0 ans IDUNDEFINED and checking in isTaskGroupRunning for
IDUNDEFINED

Then there is an issue in tasdrive. I added a call to CheckStatus when starting the
mono. This is necessary for the eiger monochromator as with that one starting is deferred
to the CheckSttaus function. The reason is that in other use cases, the looser might want
to drive a2 and a2w at the same time. This can only correctly be accomodated by deferring
the caclulations to the CheckStatus phase.
This commit is contained in:
koennecke
2014-04-07 14:02:07 +02:00
parent fc8798d012
commit 722fab935e
3 changed files with 20 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
interface.c
View File

@ -250,7 +250,7 @@ long StartDriveTask(void *obj, SConnection *pCon, char *name, float fTarget)
pDriv = GetDrivableInterface(obj);
if(pDriv == NULL){
SCPrintf(pCon,eError,"ERROR: %s is not drivable", name);
return 1;
return -1;
}
if(pDriv->CheckLimits(obj,fTarget,error,sizeof(error)) != OKOK){
SCPrintf(pCon,eError,"ERROR: %s cannot reach %f, reason %s", name,

5
tasdrive.c
View File

@ -364,6 +364,11 @@ static int startMotors(ptasMot self, tasAngles angles,
*/
status = self->math->mono->SetValue(self->math->monoData,
pCon,angles.monochromator_two_theta);
/*
The call to CheckStatus is necessary because the eiger monochromator may not
start until then. Deferred until all parameters are known.
*/
self->math->mono->CheckStatus(self->math->monoData,pCon);
if(status != OKOK){
return status;
} else {

19
task.c
View File

@ -24,6 +24,8 @@
#define READY 1
#define WAITING 2
#define YIELDING 3
#define IDUNDEFINED 0L
/*--------------------------------------------------------------------------*/
typedef struct __TaskHead {
long lID;
@ -46,8 +48,12 @@ typedef struct __TaskMan {
pTaskHead pCurrent; /* Think trice before you interfere with this! */
pTaskHead pHead;
} TaskMan;
/*---------------------------------------------------------------------------*/
static long lIDMama = 0L;
/*---------------------------------------------------------------------------
The 7 below solves a subtle bug which occurs when a groupID in user code
has been initialized to 0 and starting fails. Then it seems as if this
group keeps running. As there will always be some task running at 0.
----------------------------------------------------------------------------*/
static long lIDMama = 7L;
#define TASKERID 123399
/*---------------------------------------------------------------------------*/
@ -71,9 +77,10 @@ static pTaskHead MakeTaskHead(char *name, TaskFunc pTask, SignalFunc pSignal,
lIDMama++;
pNew->lID = lIDMama;
pNew->iStatus = READY;
pNew->groupID = IDUNDEFINED;
if(lIDMama < 0){
lIDMama = 0;
lIDMama = 7;
}
return pNew;
@ -529,7 +536,7 @@ long GetTaskID(pTaskHead it)
/*------------------------------------------------------------------------------*/
long GetGroupID(pTaskHead it)
{
return it-> groupID;
return it->groupID;
}
/*------------------------------------------------------------------------------*/
const char * GetTaskName(pTaskHead it)
@ -569,13 +576,15 @@ int isTaskGroupRunning(pTaskMan self, long groupID)
pTaskHead pCurrent, pNext;
if (self == NULL) return 0;
if (groupID == IDUNDEFINED) return 0;
assert(self->iID == TASKERID);
pNext = self->pHead->pNext; /* skip dummy task */
while (pNext != NULL) {
pCurrent = pNext;
pNext = pCurrent->pNext;
if (pCurrent->groupID == groupID) {
if (pCurrent->groupID != IDUNDEFINED && pCurrent->groupID == groupID) {
return 1;
}
}