Experimental Physics and
Industrial Control System

Peter Linardakis <[email protected]> · Tue, 2 Sep 2014 00:49:56 +0000

Mitch and Mark

Thank you for the assistance.  Moving the limit checking and reporting in drvPM304.cc into the motion complete check if block does indeed fix the problem and that is what I think I will go with (I rolled back to the original version of motordrvCom.cc) .  It's the much safer option!

Looking at the dubug output, I also think I figured out why the entire moved seemed to work 10% of the time before the fix.  On those occasions, the message timing seems to be such that a message with the "move complete" status bit unset and the "limit switch" bit set is never received.

Thanks again

Peter

-----Original Message-----
From: D'Ewart, J. Mitch [mailto:[email protected]] 
Sent: Tuesday, 2 September 2014 6:41 AM
To: Mark Rivers; Peter Linardakis; [email protected]
Subject: RE: motorApp R6.8 Mclennan PM600 opposite limit datum search mode on linux-arm

Hi Peter,

As you've said the changes may break other motor drivers in the motorApp.

                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;
                }

This was likely done due to some motor drivers not setting status.Bits.RA_DONE unless a motion command completes successfully (without hitting limit, etc.).  It is hard to say if anything will break without going through the other motor drivers that use this.  This may or may not be acceptable for your own use.

It looks like it would be fairly easy to follow Mark's suggestion of not reporting limit status if the drive is busy.  The first character of the PM600 status response is a 0/1 indicating if the drive is busy.  Looking at 268-283 of motorApp/McleannanSrc/drvPM304.cc

        if (response[0] == '0')
            status.Bits.RA_DONE = 0;
        else {
            status.Bits.RA_DONE = 1;
            if (drvPM304ReadbackDelay != 0.)
                epicsThreadSleep(drvPM304ReadbackDelay);
        }

        status.Bits.RA_PROBLEM = (response[1] == '1') ? 1 : 0;

        if (response[2] == '1') {
        status.Bits.RA_PLUS_LS = 1;
        }
        if (response[3] == '1') {
        status.Bits.RA_MINUS_LS = 1;
        }

you could move the limit checking and reporting into the motion complete check.

Mitch D'Ewart

________________________________________
From: [email protected] [[email protected]] On Behalf Of Mark Rivers [[email protected]]
Sent: Monday, September 01, 2014 6:55 AM
To: Peter Linardakis; [email protected]
Subject: RE: motorApp R6.8 Mclennan PM600 opposite limit datum search mode      on      linux-arm

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: [email protected] [[email protected]] on behalf of Peter Linardakis [[email protected]]
Sent: Monday, September 01, 2014 1:37 AM
To: [email protected]
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: [email protected]<mailto:[email protected]>
p: +61 2 6125 2862
w: http://physics.anu.edu.au/nuclear/

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System