Experimental Physics and
Industrial Control System

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]

p: +61 2 6125 2862

w: http://physics.anu.edu.au/nuclear/