Algorithm that can calculate the shortest path between 0-360 degrees for an AC servo motor.

[constructionworker]

---

@Bob_Schor wrote:

I give up.  To me, the problem seems very simple and conceptual -- one has a rotary positioner with a rotary "position indicator", with the following properties:

1. The Positioner can rotate either CW or CCW for an arbitrary distance (including an arbitrary number of full revolutions).
2. Position is specified in Degrees, in the interval [0, 360).  This notation means that 0 is included in the range, but 360 is not (when it gets to what would be 360, it auto-resets to 0, so Position is expressed as a non-negative number mod 360).
3. To move from Position A to Position B, you want to make the shortest movement that takes you from A to B.  This will result in a CW or CCW rotation between 0 and 180 (whereas going in the other direction will be between 360 and 180).

My algorithm does this.  I think the confusion lies in sloppy definitions of terms.  I'll check back in a week and see if this has been resolved.

Bob Schor

---

I don't think the algorithm will be very simple, but I agree that my English is bad.

I explain how the motor works, starting from the beginning.

-No matter how much the motor rotates in any direction, if "0" is sent, the motor will return as far as it turns forward or backward (doesn't matter the direction of rotation) until it reaches the 0 position. Because when the motor is energized, it accepts its position as 0 If I send 0, it returns to the position where the servo is energized.

-For example: I energized the motor. I sent +360 degrees to the motor The motor turns and comes back to the point where it stopped when energized. If we look at the motor shaft we know it has reached 0 degrees but the 38000 position the motor knows.Motor have encoder.Because the motor knows every step it takes.
If I write 0, the motor reaches the point where it is energized and it is the 0 position that the motor knows.

The same is true for the CCW side.

I've explained it a little more in the photo below.

When information is read from the motor's encoder, the current position must be compared to go true 0 degrees or 360 degrees. If the motor is in the first tour, typing 0 brings the motor to the 0 Position, but in the second cycle, the number 0 should not be sent to the motor. 360 actually becomes the 0 position. If it is in the second round, it is necessary to write 360 for it to reach the 0 position. If it is in the 3rd round, it is necessary to write 720. The same is true for the CCW direction.

The encoder I want to create here should go to the given degree from the closest path for positioning between 0-360 given according to its (current) position.

I don't know how to explain more.

If the situation isn't clear, I guess I'll have to deal with it myself.
Thank you everyone for your effort.

[LLindenbauer]

---

@constructionworker wrote:

I don't know how to explain more.

If the situation isn't clear, I guess I'll have to deal with it myself.
Thank you everyone for your effort.

---

Try using your own language, then. Explain it like you would explain it to a 8 year old child in your own language.

If you want to be extra cautious, you can translate it into english using a translation program, then translate it back and see if it still means the same thing. This is not necessary, but it can catch problems with metaphors.

There is another thing: I took a look at the manuals for that motor. Can you please explain what actually happens when you "send a command"? Do you open a program? Do you have a LabVIEW-Block? Do you type the number into a keyboard?

[constructionworker]

---

@LLindenbauer wrote:

---

@constructionworker wrote:

I don't know how to explain more.

If the situation isn't clear, I guess I'll have to deal with it myself.
Thank you everyone for your effort.

---

Try using your own language, then. Explain it like you would explain it to a 8 year old child in your own language.

If you want to be extra cautious, you can translate it into english using a translation program, then translate it back and see if it still means the same thing. This is not necessary, but it can catch problems with metaphors.

There is another thing: I took a look at the manuals for that motor. Can you please explain what actually happens when you "send a command"? Do you open a program? Do you have a LabVIEW-Block? Do you type the number into a keyboard?

---

actually the following algorithm arrives at the result I want to do.
Apart from being a bit complicated it seems to have solved the problem but I'm not quite sure 🙂

If anyone knows a better and easier way than this code that tries to explain what I want to do, please give suggestions.

[altenbach]

This is pure Rube Goldberg! You are still stuck in the same old rut.

• The shift register has no purpose, you can connect the current encoder directly to the code.
• The code for the simulated motor makes no sense.
• You still have that exceedingly complicated birds-nest of wires with no recognizable logic.
• You are not updating the "current encoder" according to the new position

If I can be described in a few words, it should not need a screenful of code!!!!

[constructionworker]

---

@altenbach wrote:

This is pure Rube Goldberg! You are still stuck in the same old rut.

• The shift register has no purpose, you can connect the current encoder directly to the code.
• The code for the simulated motor makes no sense.
• You still have that exceedingly complicated birds-nest of wires with no recognizable logic.
• You are not updating the "current encoder" according to the new position

If I can be described in a few words, it should not need a screenful of code!!!!

---

It's just a Quickly created example. That's why it's a bit confused 🙂

• yes shift register is not needed because value will be updated from encoder.
• It's just there to see the degree of rotation of the motor. What matters is the position displayed on the "Send to motor " indicator. (in which direction and how far from point 0)
• I will distribute the bird's nest 🙂
• For now I am writing the current position manually just to test it. Because later I will read the current stopping point of the motor from the encoder of the motor.
  According to the current position, the motor should move to the new position entered.

I don't know if this much code is needed or not, but this code is working now. I just thought you were describing the algorithm I wanted to create, and I thought I could make it better if anyone could help.
Still not understood what is intended to be created?

[daveTW]

Hello Worker,

I want to put my two cents in (after that I'm skint).

I took your VI (Position v2.0.36.vi), connected all inputs and outputs to the connector pane and fed in a table of predefined values. I defined a set of values and its negatives, where either [current/encoder] or [New position]  is zero, and one set where [current/encoder] starts with 90 or 180 degrees. See the snippet below:

These are the results:

Position v2.0.36.txt

Position v2.0.36 (2).txt

Please explain, which values in [Send to motor] and [real position] are expected (and why) and which values are not.

[wiebe@CARYA · Accepted solution]

This seems to give the same results as the presumably working example.

At least for the 5 values I've tested:

[altenbach]

---

wiebe@CARYA wrote:

At least for the 5 values I've tested:

---

Well, In this case it is simple to do an exhaustive analysis of all 360x360 possible inputs. For at least 1/8th of the samples, there is a difference in the "send to motor" command. I doubt any version is actually correct. 😄

[altenbach]

After adjusting the z axis of the lower left graph for the actual range, here's what we get:

[wiebe@CARYA]

---

@altenbach wrote:

---

wiebe@CARYA wrote:

At least for the 5 values I've tested:

---

Well, In this case it is simple to do an exhaustive analysis of all 360x360 possible inputs. For at least 1/8th of the samples, there is a difference in the "send to motor" command. I doubt any version is actually correct. 😄

---

Not that it helps, but I think the Current input isn't limited to 0 or 360, it can be anything...