Experimental Physics and
Industrial Control System

Hi EPICS folks,

       In the EPICS SynApps TPMAC module, AssyGeneric_scanrec_v2.db file has a note that this update is a patch based on a suggestion from Lewis Muir to fix occasional problems with the (assy)Busy record. This fix resulted in a minimum move time of 0.25 second. We want to fix this problem that a move has to have a minimum time of 0.25 second because (1) my scan logic requires sending a dummy move command from the inner fly scan record and I want this command to take a minimal amount of time, and (2) for step scans with small increments we want each individual move to take less than 0.25 second.

 

       Does anybody have any ideas or implementations to fix TPMAC so that there isn’t this minimum move time of 0.25 second? I have not dug into the internal logic yet but thought I would check with the EPICS community first.

 

Thanks,

Jay Steele

Xradia Corporation

 

P.S. Here is the note in the AssyGeneric_scanrec_v2.db file.

 

# NOTE: AssyGeneric_scanrec_v2.db is a patch to AssyGeneric_scanrec_v1.db

# suggested by Lewis Muir <[email protected]>. Use it in conjunction with

# ../pmacDb/bkgfix1pcs_scanrec_v2.db

# The rational for the change according to Lewis is:

# When performing an sscan module step scan of a tpmac drive, sometimes

# the (assy)Busy record does not get set to Done, and so the sscan record

# waits indefinitely for the move to complete.  The move has completed,

# but the (assy)Busy record doesn't reflect this.

#

# I tracked down the problem to the fact that for some moves (maybe small

# ones that complete very quickly?), (pcs)PrgExeSts is never processed

# (verified by setting its TPRO field to 1) and hence (pcs)InPos is never

# processed.  This makes Tim Mooney's (pcs)ClearBusy record not work

# right since it never sees (pcs)InPos transition to 0 (Moving) and then

# to 1 (Positioned) - so it never sets (assy)Busy to Done and so the step

# scan waits indefinitely.

#

# Attached is a patch against tpmac 3-5 to fix this problem.  The fix uses

# a software-only "in-position" indicator that gets set to 0 (Moving) at

# the start of the move and 1 (Positioned) 0.25 sec later.  0.25 sec was

# chosen because in the cases where (pcs)InPos did process, it always

# seemed to process within 0.1 sec of having started the move, so 0.25 sec

# seemed safe.

#

# The idea is that if (pcs)InPos has not transitioned to 0 (Moving)

# within 0.25 sec of starting the move, it never will.  In this case, the

# software-only "in-position" indicator is observed by the (pcs)ClearBusy

# record and it sets (assy)Busy to Done after 0.25 sec.  If, however,

# (pcs)InPos does transition to 0 (Moving) within 0.25 sec of starting

# the move, (pcs)ClearBusy will track it for determining when the move

# completes.

#

# The downside of this patch is that every move will take a minimum of

# 0.25 sec.  The upside is that step scans will work correctly - the sscan

# module will not lock up.

#

# A cleaner fix would be for (pcs)InPos to transition to 0 (Moving) and

# then to 1 (Positioned) for every move (even if the move takes a very

# short time).  I didn't look at the C code, but perhaps there's a way to

# force (pcs)PrgExeSts to update right after starting the motion program,

# and again once the motion program completes.  Or maybe that won't work,

# and a separate flag would be needed that gets set to 0 (Moving) before

# starting the motion program and get set to 1 (Positioned) after the

# motion program completes (maybe even the motion program itself sets it

# as its last instruction).

#