RE: [Ext]RE: Help with BiSS encoders and Galil controller

["Pearson, Matthew via Tech-talk" <tech-talk at aps.anl.gov>]

Hi,

 

You may be able to use a negative ERES value to get the behavior you need, and also disable the driver encoder stall detection (by setting the stall time to a large value). The motor and encoder will be moving in opposite directions at the controller and driver level, but in the motor record they’ll look consistent. Although I’ve never tried this with absolute encoders, and as Mark and Mark mentioned it’s best to have them consistent at the controller level.

 

Also, when I was testing BiSS status readback a few years ago, I think I noticed a problem with it not working correctly for some axes (B-H maybe). I never got chance to look at it in detail though, and now I don’t often work with Galil controllers.

 

You can test the status readback by sliding a sheet of paper between the optical readhead and the encoder scale.

 

Cheers,

Matt

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Mark Rivers via Tech-talk
Sent: Tuesday, May 13, 2025 6:49 PM
To: Jesse Hopkins <jhopkins1 at iit.edu>; EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: [EXTERNAL] RE: [Ext]RE: Help with BiSS encoders and Galil controller

 

Hi Jesse, Did you have these slits working previously with an OMS? I have verified that using LA Stepper from the Galil to the Step-Pak results in the same rotation direction and limit sense as the OMS, so we did not need to change any wiring?

Hi Jesse,

 

Did you have these slits working previously with an OMS?  I have verified that using LA Stepper from the Galil to the Step-Pak results in the same rotation direction and limit sense as the OMS, so we did not need to change any wiring?

 

What driver are you using?  If switching the limits is difficult then perhaps it would be easier to reverse a motor winding in the cable.  Then HA Stepper will move in the direction that works with the limits.

 

Mark

 

 

From: Jesse Hopkins <jhopkins1 at iit.edu>
Sent: Tuesday, May 13, 2025 5:27 PM
To: Mark Rivers <rivers at cars.uchicago.edu>; EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: Re: [Ext]RE: Help with BiSS encoders and Galil controller

 

Hi Mark,

 

Thanks for asking the obvious question, I probably should have tested that already. Yes, If I flip the motor type to HA Stepper it seems to work fine, requested motor motion and encoder readback align in terms of direction, and the motor stops running away. So it definitely seems to be related to the Rev HA Stepper setting.

 

Unfortunately, given the system (slits in UHV) I’m kind of stuck with the Rev HA Stepper setting as I need the stepper motor motion to align with the limits, and rewiring the limits would be non-trivial.

 

All the best.

- Jesse

 

----
Jesse Hopkins, PhD (he/him)
Director, BioCAT

Sector 18, Advanced Photon Source

Research Associate Professor, Illinois Tech

 

From: Mark Rivers <rivers at cars.uchicago.edu>
Date: Tuesday, May 13, 2025 at 5:20 PM
To: Jesse Hopkins <jhopkins1 at iit.edu>, EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: [Ext]RE: Help with BiSS encoders and Galil controller

Hi Jesse,

 

I have a Galil with the -SER option but I don’t have any motors with BISS encoders yet.

 

What happens if you change the motor type to HA Stepper?  Do the motor motion and the encoder then agree in sign?

 

Mark

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Jesse Hopkins via Tech-talk
Sent: Tuesday, May 13, 2025 4:56 PM
To: EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: Help with BiSS encoders and Galil controller

 

Hi folks,

 

I have several motors with BiSS encoders (RL26BVE050D15V from Renishaw) that I would like to use with a Galil 4183 motor controller. The Galil controller is configured for absolute encoders with the -SER option for axes 1-8.

 

I’m using EPICS base 7.0.8, motor 7.3.1, and GALIL 4.0.02.

 

I’ve attempted to configure the motor and encoder appropriately. I’ve attached a screenshot of the various configuration screens. When I move the motor with the ‘Use Encoder’ option set to No, everything seems to work fine. The motor moves and the encoder counts change by roughly the expected amount. For example, I move the motor a nominal 0.4 mm, which is a full turn, and the encoder increments by 8008 counts, with the 50 nm per count resolution that is a total motion or 0.4004 mm. The nominal resolution is 0.5 um per step with the present microstepping settings, so this is an expected/acceptable level of accuracy.

 

However, if I turn on the Use Encoder setting, the motor moves in the wrong direction. So, for example, if I try to move the motor positive the motor moves negative as indicated by the encoder readback. If I try to move the motor negative the motor moves positive as indicated by the readback. This persists whether I set the calibration direction as Positive or Negative. In practical terms, this results in the motor getting stalled out with a controller message “Encoder stall stop motor C” unless the duration of the move is less than the encoder stall time.

 

As a side note, I encountered similar behavior when setting up quadrature encoders for different motors, but was able to fix the issue by changing from normal quadrature to reverse quadrature, which flipped the direction of the encoder count relative to the motor. However, there doesn’t seem to be any such option for the BISS inputs. So I’m currently wondering if this is related to these motors being configured as Rev HA Stepper, and the encoder counts coming in in the opposite direction of the expected motor motion and the GALIL driver not accounting for that.

 

Another possible concern, if I turn on the BiSS status poll the timeout, crc, warn, and error in the BiSS status all stay red/high, so maybe there’s an issue there? However, since I’m getting the right number of encoder counts with a given motion it feels like maybe this is an error on the driver side? Also, if I send the command MG _SSC0 to the controller I get a return value of 0.000, which would indicate no errors, so it seems likely the BiSS status display isn’t correct.

 

I did double check and SSC=? and SY? return the expected values (1,27,0,0,9 and 0 respectively), so it seems like the control settings and level are set correctly on the controller side.

 

Any advice/help would be greatly appreciated.

 

All the best.

- Jesse

 

----
Jesse Hopkins, PhD (he/him)
Director, BioCAT

Sector 18, Advanced Photon Source

Research Associate Professor, Illinois Tech