Experimental Physics and
Industrial Control System

That should say:

                I fixed the problem by defining ERES in my motor template file.

 

 

 

Folks,

 

I figured out the problem.  The issue was that the Galil driver uses the EncoderRatio that is sent to it by devMotorAsyn.c during iocInit.  The encoder ratio is calculated as EncoderRatio=MRES/ERES, i.e. the motor resolution divided by the encoder resolution.  My issue was that the encoder resolution was not yet defined at iocInit, because it was not defined in a database or autosave file.  It was thus 0, and the encoder ratio was infinite.  That problem is invisible to the user, because later ERES is computed by the motor record, and so it appears OK in OPI screens.  I fixed the problem by defining MRES in my motor template file.

 

devMotorAsyn should be fixed so that if ERES=0 it sets EncoderRatio to 1, not to infinite.  That is the normal case, and would have avoided this issue.

 

Thanks,

Mark

 

 

 

Hi Mark,

 

I’ve not seen this before, and we do that all the time (but only ever with stepper motors).

 

You could try setting the Galil commands manually via Galil GDK/Tools, to figure out if it’s an issue with the driver or the Galil firmware. You could also check the Galil DMC log file (if you have that configured in the IOC) to see exactly the commands being sent to the controller. It should be DP and DE to set the positions, but the order of those two commands is inverted for servo type motors and I’m not sure why.

 

Cheers,

Matt

 

 

Folks,

 

I am having 2 serious issues with using “set” mode in the motor record to set the current motor position on a Galil controller.

 

-          It works fine to set the position when the motor is not using an encoder and when not at a hard limit.  Setting the position sets both the drive values (VAL, DVAL, RVAL) and the readback values (RBV, DRBV, RRBV).

-          When setting the position of a motor with an encoder the VAL, DVAL, and RVAL are set correctly.  However, the readbacks are not set.  This means that subsequent moves are not correct, because they act as if the motor is currently at the readback position, and move by the wrong amount.  I have attached a screenshot (Set_to_0_at_1.png) showing a motor that had been at DVAL=1, and then I set it to DVAL=0.  Note that the readbacks are still for DVAL=1.

-          If the motor has an encoder and is at a hard limit when I set the position then the result is that RVAL gets set to -2^31.  The system is totally unusable, because it now thinks the motor is outside the soft limits.  This is shown in screen shot Set_to_0_at_-10_on_limit.jpg.  The motor was on a limit with a DVAL of about -10.7.  I set the position to 0, and now the DVAL is -107374. 

 

Note that driving to a limit and then setting the position is a common operation, because we know what the absolute position of the limit switch is.  But this does not work at all with the Galil.

 

Have others seen these problems?  Am I doing something wrong?

 

Thanks,

Mark