Welcome, Guest

TOPIC: Bi-directional communication with two daisy-chained motors

Bi-directional communication with two daisy-chained motors 5 years 4 weeks ago #1158

  • madmage
  • madmage's Avatar
  • OFFLINE
  • Fresh Boarder
  • Posts: 3
  • Karma: 0
Hi everybody,
I am using a Mesa Robotics Element robot, featuring two Smart Motors in RS232 daisy chain. I need to send commands to each of them and receive feedback from each of them.
I understand that using the #128,#129,#130 chars on the RS232, I can send commands to one or both of the two motors, but how can I synchronize the output sent by them through PRINT commands? Now they send odometry information on the RS232, but sometimes I read mixed output on the serial channel.

Moreover, it seems to me that sometimes my commands sent to the motors are mixed with the output of one of the motors, is this possible? (what happens is that "sometimes" the commands I send to the motors are not interpreted by my program).

Notice that the commands I send to the motors are just variables set, that are properly interpreted by the program.

Finally, I have some additional questions:
- is the ECHO command needed on both motors for the daisy-chain to work? is that the ECHO toward the other motor or the ECHO towards myself?
- what is the difference between ADDR= and SADDR# ? should I use SADDR# in the beginning of the motor program or ADDR= ?

Thanks!
The administrator has disabled public write access.

Re: Bi-directional communication with two daisy-chained motors 5 years 4 weeks ago #1159

  • csearcy
  • csearcy's Avatar
  • OFFLINE
  • Moderator
  • Posts: 459
  • Thank you received: 77
  • Karma: 23
ECHO makes the command that was sent... come back with the Data.

If ECHO is off... and you send RPA... you only get the position returned.

If ECHO is on... you get the command sent.... and the position returned.

ADDR=1 and SADDR1 both set the address for the primary And the secondary port.
The difference is you can query ADDR. That lets you download one program to all motors and they run different subroutines based on their own address.

Note: If you have random PRINT statements in your program... you can corrupt data that is being requested by SMI2 or other host programs.
The administrator has disabled public write access.

Re: Bi-directional communication with two daisy-chained motors 5 years 4 weeks ago #1160

  • madmage
  • madmage's Avatar
  • OFFLINE
  • Fresh Boarder
  • Posts: 3
  • Karma: 0
Thus, for what you are saying, I should set ECHO on motor 0, so that it send my commands in daisy chain to motor 1, but could it be interleaved with messages printed by the motor 0 itself?
Moreover, the ECHO should be set also on motor 1, because otherwise I cannot read messages that are PRINTed by motor 0, right?

What happens is that I have response messages from motor 0 and motor 1, for example:
'Motor 0
PRINT("a","a","a",#13)
'Motor 1
PRINT("b","b","b",#13)

and what I see from the console is, sometimes, something like
aaa
bbb
abbb
aa

how to avoid this?
The administrator has disabled public write access.

Re: Bi-directional communication with two daisy-chained motors 5 years 4 weeks ago #1161

  • csearcy
  • csearcy's Avatar
  • OFFLINE
  • Moderator
  • Posts: 459
  • Thank you received: 77
  • Karma: 23
All motors will pass the RS232 data. The ECHO command determines if a report command will return the command with the data.
If ECHO is on... and Actual Position is 12345... then I can send RPA... and the reply will be ... RPA 12345. If ECHO is off... the reply will only be the Actual Position... 12345.

If you allow 2 motors on a daisy chain to print out data at the same time... the data may get corrupted. This is like two people talking to you at the same time... about different subjects.

You need to have your host query each motor for it's data. You can use ECHO if you want to see your command come back with the data. Either way... you need to make sure the motors don't send data unless you request it. If you only have RS232 available for communications... you can have motor1 print it's data... then have motor1 call a subroutine in motor2 ... that causes it to print it's data. This approach could prevent the data collision you are seeing with the motors printing at random times.

If you are using the new Class5 motors with the CAN option... you have some very powerful options available such as the Combitronic protocol that would make this much easier.
Last Edit: 5 years 4 weeks ago by csearcy.
The administrator has disabled public write access.

Re: Bi-directional communication with two daisy-chained motors 5 years 4 weeks ago #1162

  • madmage
  • madmage's Avatar
  • OFFLINE
  • Fresh Boarder
  • Posts: 3
  • Karma: 0
There is something wrong with posting on the forum: I received your answer via email, but it is (still?) not published here.

However, I answer to your answer:

First of all, thanks a lot for your fast replies.
Your advice is that motor1 receives commands, print responses and then call a subroutine in motor2 that will do the same. When you say "call a subroutine" you mean it sends a "GOSUB" command on the serial channel to motor2?

However, as far as I can understand, the ECHO is asynchronous with respect to program and serial command execution (that are, on the other hand, synchronized). I mean that characters coming from the serial are echoed one by one, asynchronously wrt to program/serial execution. This causes a problem even with one motor: if the motor is printing a response while the client is sending something, the echo and the response will be mixed.

Example: client -> motor1 -> client
A) client sends a=1 on the serial
B) motor1, when a==1, prints "ack" on the serial
C) client sends a=2 on the serial

if B and C are happening in the same time, the characters "ack" and the echo "a=2" could be mixed, resulting in "aack=2" or "aca=2k", etc.

This should happen with one motor and with more probability when the motors are two: client -> motor1 -> motor2 -> client.

The only easy solution I found is to synchronize everything *from*the*client*, that is, the client sends something to motor1 and waits for its response, then sends something else to motor2 and waits for its response.

This should work (I am testing this solution right now), I do not know if there is a more efficient working solution. Please tell me what do you think.
The administrator has disabled public write access.
Time to create page: 0.258 seconds
Powered by Kunena Forum