1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 <2011> 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | question about fix for AssyGeneric_scanrec_v2.db patch in tpmac module (results in 0.25 s minimum move time) |
From: | Jay Steele <[email protected]> |
To: | "[email protected]" <[email protected]> |
Date: | Tue, 19 Apr 2011 11:16:58 -0700 |
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). # The information in this email, including any attachments, is confidential and intended only for the recipient(s) listed. Any use of this email for any other purpose is prohibited. If you have received this email in error, please notify me immediately by reply email, delete this email, and do not disclose its contents to anyone. |