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: | motorApp R6.8 Mclennan PM600 opposite limit datum search mode on linux-arm |
From: | Peter Linardakis <[email protected]> |
To: | "[email protected]" <[email protected]> |
Date: | Mon, 1 Sep 2014 06:37:17 +0000 |
Hello all I am using a Mclennan SimStep unit that contains a PM600 motor controller. I am trying to implement a datum search using the PM600s opposite limit search mode (set in hardware) whereby a write to .HOMF/.HOMR field in the motor record
will send the motor all the way to the opposite limit switch, it will then reverse and continue until it finds the datum switch. The idea of course is that the datum switch is approached from the same direction every single time. However, it seems to have a problem whereby the moment the limit switch is hit, EPICS will stop sending out “request for status” commands and just sits there waiting for something to happen, even though the motor keeps moving and successfully
finds the datum switch. Since the PM600 “move complete” status bit is not set when the limit switch is hit (because the hardware knows it still has something to finish), the .MOVN field is stuck on “moving”. The motor is then unresponsive to any other commands.
I usually restart the IOC at this point (which is a Raspberry Pi sandbox). Also note that about 10% of the time, the entire move completes successfully – I have no idea why. Now, I have managed to solve this problem by potentially breaking a whole lot of other things in the motorApp. In ../motorR6-8/motorApp/MotorSrc/, I looked at motordrvCom.cc and lines 254 to 282 (with my test modifications) are: … if (motor_motion->status.Bits.RA_DIRECTION) { if (motor_motion->status.Bits.RA_PLUS_LS) //ls_active = true; ls_active = false; ** MY MOD else ls_active = false; } else { if (motor_motion->status.Bits.RA_MINUS_LS) //ls_active = true; ls_active = false; ** MY MOD else ls_active = false; } if (ls_active == true || motor_motion->status.Bits.RA_DONE || motor_motion->status.Bits.RA_PROBLEM) { (*tabptr->query_done) (card, index, motor_motion); brdptr->motor_in_motion--; motor_free(motor_motion, tabptr); motor_motion = (struct mess_node *) NULL; motor_info->motor_motion = (struct mess_node *) NULL; } …. I haven’t delved into the last if block, but I took its intention to be that if a limit switch is hit, then that’s equivalent to a move finishing or there being a problem, which is not what I want for an opposite limit datum search mode.
Anyway, by removing the effect of the limit switches in this code, I get 100% success rate at finding the datum using the desired mode. i.e It works how I want it to. In addition, normal operation when hitting a limit switch is not affected, since when a
switch is hit, the PM600 hardware sets the “move complete” status bit and EPICS/the motor record seems to know what is going on. However, I’m assuming this code is used in other motorApp drivers and I can see when having the move be considered complete when hitting a limit switch (say a soft motor?) would be useful. So my questions are: what have I broken by doing
this and is there a better way to solve my problem? Much appreciation and thanks in advance… Regards Peter Dr Peter Linardakis Accelerator Research & Development Engineer Nuclear Physics | Research School of Physics and Engineering Australian National University p: +61 2 6125 2862 w:
http://physics.anu.edu.au/nuclear/ |