Virtual axis for feedback on position control axis

I have an absolute encoder measuring the position of a conveyor belt, but one full rotation of the belt is 6.5 turns on the encoder. This has made some of the math I need to do for homing and positional control through power cycles rather complicated. I was wondering if I could put the encoder on its own axis and gear that axis to a virtual axis with a 6.5 ratio and then use the virtual axis for feedback on my control axis?

I saw no obvious way to do it, so I’m thinking I have to set up custom feedback on my control axis and feed the positional data from the virtual axis to the custom feedback via a continually running program. That’s no problem if it’s the only way to do it, but I was wondering if there was a simpler way? I’d love to just be able to gear the control axis to an axis with the encoder. Or maybe there’s another approach I haven’t thought of. Any advice or help is greatly appreciated.

This is a classic problem. I recall that it’s very difficult to make it work if the number of encoder turns is not an even number multiple of the number of machine rotations. I think that with some fancy math and maybe custom feedback as you mentioned, it’s possible to make it work up until the encoder wraps from its largest number back to zero, at which point complicated calculations and logic is required.

If you can provide the following, I’ll see if I can come up with something:

  • Do you have a multi-turn SSI encoder?
  • How many bits per turn and how many bit for the number of turns?
  • What is the position travel for the 6.5 turns?

-Jacob

Is this a case where a simple quadrature encoder might be better than an absolute? You’d have to do a homing routine but it might be possible to use 1/2 the total counts as a “turn” of the encoder and 13 turns of the encoder for one loop of the belt…

Stinky if you already have the hardware though.

I do have a multiturn SSI Encoder with 13 bits for single turn (8192 counts) and 12 for multiturn. It travels 8 positional units per rotation with a total axis rotation of 52 positional units.

A requirement to be able to run the machine from power up without a homing routine was added very late in development. Originally everything had quadrature encoders. Fortunately the other axis are even turns. I knew the math was going to be complicated, but I thought I could possibly cheat and use some of the fancy features of the controllers to make my life easy.

Unfortunately they are all rotary axis and I read that custom feedback is not compatible in this situation? I did some tests in simulation where I geared a virtual axis to my real axis with a 6.5 to 7 gear ratio and it translated the motions correctly, but the virtual axis doesn’t keep a virtual position.

I can dynamically reset the physical encoder’s counts with a digital output and I have homing sensors on the axis that I can use to facilitate this in operation. What I cannot do is a blind homing routine on power up because the axis may have product on it.

The axis originally had a quad encoder on it, however the customer added a requirement to eliminate the need for a homing routine on power up, so it was swapped for an absolute SSI encoder.

I haven’t thought this all the way through, but I think it may be possible to set the axis to incremental mode, and then on startup, use the raw encoder counts to determine where you are and update the Actual Position accordingly. You could perhaps have a continuously-running user program that stores the Actual Position or Counts to a non-volatile variable, which may be of help when powering up to determine where the belt is. This still means some complicated math.

I think you will need to keep track of when the encoder wraps over the 25 bits. 25 bits is 33554432 counts. Each machine cycle has 6.5x8192 counts, which is 53248. After 630 machine revs, the encoder will be 8192 counts shy of the 25-bit wrap point. When it wraps, I believe the RMC will smoothly ride through the wrap, but the counts relative to the original machine cycle counts will now be off by 8192. You need to adjust for this in order to continue. You do have access to the raw counts, so it should be possible. I think you need a non-volatile variable to record how many times the encoder has wrapped around the 25 bits.

I’ll try to think on this a bit more.

-Jacob

My thought that I’m going to try implementing here in a moment is to ignore an extra bit so I get a wrap every half turn of the encoder on a count of 4096 bits. Then I’ll write a routine to count the roll overs that I’ll reset every full belt rotation. I can also capture the raw encoder counts and have a startup routine that compares the current raw count to the last known count that’ll help me know if there’s been significant movement when the machine was off. Any severe variance is going to be a fault condition anyhow. But it should allow me to return to a good state and make the math a bit simpler with even rotations.

I like that idea! It certainly does simplify some aspects. Let me know how it works out!