Welcome, Guest
Username Password: Remember me
  • Page:
  • 1

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

Bi-directional communication with two daisy-chained motors 2 years, 11 months ago #1158

  • madmage
  • OFFLINE
  • 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!

Re: Bi-directional communication with two daisy-chained motors 2 years, 11 months ago #1159

  • csearcy
  • OFFLINE
  • Posts: 480
  • 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.

Re: Bi-directional communication with two daisy-chained motors 2 years, 11 months ago #1160

  • madmage
  • OFFLINE
  • 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?

Re: Bi-directional communication with two daisy-chained motors 2 years, 11 months ago #1161

  • csearcy
  • OFFLINE
  • Posts: 480
  • 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: 2 years, 11 months ago by csearcy.
  • Page:
  • 1
Moderators: hsummer, csearcy
Time to create page: 0.42 seconds