Experimental Physics and
Industrial Control System

On the older Linux system the scaler CNT widget behaves badly, as
described previously.  This version is:

corvette> more /proc/version 
Linux version 2.4.20-20.9smp ([email protected]) (gcc
version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 SMP Mon Aug 18
11:32:15 EDT 2003 


On a newer Linux system the scaler CNT widget behaves fine.  This
version is:

vincent> more /proc/version 
Linux version 2.6.9-22.0.1.EL ([email protected]) (gcc version 3.4.3
20050227 (Red Hat 3.4.3-22.1)) #1 Thu Oct 27 10:38:16 CDT 2005

Since I am running exactly the same medm binary on exactly the same X
server, the only difference is the run-time libraries that are present
on the Linux system that is running medm.  There must be a problem with
the X libraries on the old Redhat 2.4.20 system.  

I conclude that there
is no problem with the scaler record or with medm.

Mark


  

-----Original Message-----
From: Mark Rivers 
Sent: Thursday, March 30, 2006 4:55 PM
To: 'Tim Mooney'
Cc: 'Kenneth Evans, Jr.'; 'Jeff Hill'; 'Dirk Zimoch'; 
'Leicester, PJ (Pete)'; 'Ralph Lange (BESSY)'; 'Ned Arnold'; 
'Andrew Johnson'
Subject: scaler record medm problems

Folks,

I have applied this fix to the scaler record.  I used 
camonitor on the CNT field, and indeed it fixes the problem 
of two monitors being posted for CNT=Count when acquisition starts.

However it does NOT fix the problem with medm on Linux.  medm 
running on Windows continues to work fine, medm running on 
Linux (but displaying on Windows or Linux) does not work. The 
Count/Done choice button gets into a weird state with both 
states selected, not sending events, etc.

So the question is why is that particular choice button messing up?

- It does not have to do with 2 monitors being posted quickly 
on the PV it controls.
- It should not have to do with the caPutCallback behavior of 
the scaler record, because medm does not use caPutCallback, right?

Any ideas what to look for next?

Mark


    

-----Original Message-----
From: Tim Mooney [mailto:[email protected]] 
Sent: Thursday, March 30, 2006 2:14 PM
To: Mark Rivers
Cc: Tim Mooney; Kenneth Evans, Jr.; Jeff Hill; Dirk Zimoch; 
Leicester, PJ (Pete); Ralph Lange (BESSY); Ned Arnold; 
      

Andrew Johnson
    

Subject: Re: gateway enum writes

Tim Mooney wrote:

 > There's an error in the scaler software.  It should not be 
posting CNT
 > unless it changed CNT.  This will take some time to fix 
thoroughly, but
 > at least the record should never post CNT = 0 ("Done"), 
because it never
 > sets CNT to this value.  I've committed this fix to cvs. 
      

 The other
    

 > transition will take some thought, because 1->0 can come 
from the user
 > and from device support, and these can race.

Oops.  This hasn't been true for a long time.  I *can* post 
at the time of
change, and I actually committed that bug fix.  Here are 
      

the changes:
    

static long process(pscal)
	...
	/* If we're being called as a result of a done-counting 
interrupt, */
	/* (*pdset->done)(card) will return TRUE */
	if ((*pdset->done)(card)) {
		pscal->ss = SCALER_STATE_IDLE;
		/* Auto-count cycle is not allowed to reset 
.CNT field. */
		if (pscal->us == USER_STATE_COUNTING) {
			pscal->cnt = 0;
+			db_post_events(pscal,&(pscal->cnt),DBE_VALUE);
			pscal->us = USER_STATE_IDLE;
			justFinishedUserCount = 1;
			if (pscal->ppn) putNotifyOperation = 1;
		}
	}
	...
		if (handled) {
			pscal->pcnt = pscal->cnt;
-			Debug(2) "process: posting .CNT field 
(%d)\n", pscal->cnt);}
-			db_post_events(pscal,&(pscal->cnt),DBE_VALUE);
		}
	}



-- 
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab