RE: motorApp R6.8 Mclennan PM600 opposite limit datum search mode on linux-arm

[Mark Rivers <rivers@cars.uchicago.edu>]

Hi Peter,

I think the problem is that the motor record should ignore both soft limits and hard limits during a homing sequence.  Soft limit violations are expected because the controller does not yet know where the motor is, and hard limits are also to be expected because sometimes the homing operation involves hitting the limit switch, as in your case.

I have had problems with the motor record stopping a motor when a soft limit is exceeding during a homing operation too, but I believe that has been fixed in a recent release.

I think the best solution in your case would be to modify your driver so you don't report the limit status if the driver knows that a home search operation is in progress.

Perhaps Ron Sluiter can comment more.

Mark

________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Peter Linardakis [peter.linardakis@anu.edu.au]
Sent: Monday, September 01, 2014 1:37 AM
To: tech-talk@aps.anl.gov
Subject: motorApp R6.8 Mclennan PM600 opposite limit datum search mode on linux-arm

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
e: peter.linardakis@anu.edu.au<mailto:peter.linardakis@anu.edu.au>
p: +61 2 6125 2862
w: http://physics.anu.edu.au/nuclear/