To briefly follow up on this, for anyone who finds themselves in the same situation, switching the phase didn’t work. In order to maintain limit consistency when you switch the phase you also
have to switch the stepper type (e.g. from reverse high active to normal high active). That means there’s no effect on the discrepancy between motor direction and encoder direction. In the end, the only solution that worked was switching the limits. Because
of accessibility issues for our system, we did this at the breakout panel for the slits outside of vacuum. The stepper direction could then be flipped so that motor and encoder direction agreed while maintaining limit consistency.
All the best.
- Jesse
----
Jesse Hopkins, PhD (he/him)
Director, BioCAT
Sector 18, Advanced Photon Source
Research Associate Professor, Illinois Tech
From:
Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Jesse Hopkins via Tech-talk <tech-talk at aps.anl.gov>
Date: Wednesday, May 14, 2025 at 9:36 AM
To: EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: Re: [Ext]RE: Help with BiSS encoders and Galil controller
Hi folks,
Thanks to Matt, Mark R. and Mark C. for the suggestions. Given what’s been said, I think the easiest thing for us to do is going to be flip a winding direction in the connection cable, which
should allow us to flip the motor direction to be consistent with the encoder scale. It’s good to know that there’s no obvious easy way to flip the encoder direction in software, we’ll be careful in the future to ensure correspondence between high/low limits,
direction of travel, and encoder scale when we set up BiSS encoded motors.
To answer Mark R.’s question, we didn’t have the capability to use the BiSS encoders with our previous OMS setup (which only had quadrature support). When we changed over from that to the GALILs
we also changed drivers (from Step-pak to Gecko GR214V drivers,
https://www.geckodrive.com/product/gr214v-bulletproof-high-resolution-stepper-drive/), and perhaps in that changeover may have also flipped direction. So this is testing new capabilities for us.
All the best.
- Jesse
----
Jesse Hopkins, PhD (he/him)
Director, BioCAT
Sector 18, Advanced Photon Source
Research Associate Professor, Illinois Tech
From:
Pearson, Matthew <pearsonmr at ornl.gov>
Date: Wednesday, May 14, 2025 at 9:01 AM
To: Mark Rivers <rivers at cars.uchicago.edu>, Jesse Hopkins <jhopkins1 at iit.edu>, EPICS Tech-Talk <tech-talk at aps.anl.gov>
Subject: RE: [Ext]RE: Help with BiSS encoders and Galil controller
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
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
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
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
|