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

TOPIC: RS232 communication lockup

RS232 communication lockup 10 months, 1 week ago #2173

I have a Model SM34165DT motor with firmware 5.0.4.8.

It's being controlled via commands sent over RS-232 and works well except for one situation: If the CPU that is commanding it is restarted while it is sending "RBt " in a fairly tight loop, most of the time the smartmotor will then not respond until it's been power cycled.

I have tried sending " Z ", " END ", " WAKE ", and nothing brings the controller back.

However, the Smartmotor Playground tool can get it online using Detect Motors. Then it's fine, and restarting HyperTerminal I can see that the controller hasn't even been reset: I can type "Rc " and the motor prints the value I'd previously stored in variable c. (And the motor controller has been set to echo what it receives).

So -- what could the Playground tool be sending that gets the motor to start responding again?

Thanks
Brian
The following user(s) said Thank You: diglesia

Re: RS232 communication lockup 10 months, 1 week ago #2174

  • csearcy
  • OFFLINE
  • Posts: 480
  • Karma: 23
The SMI software and the Playground usually just set the baud-rate, address, and turns ECHO on.
Are you using an ADDR command and setting ECHO in your program?
Are you using the default baud rate of 9600,8,N,1? ...or something else?

Re: RS232 communication lockup 10 months, 1 week ago #2175

I reproduced the problem and recorded the data sent between Playground and the motor (using HDD Software's Device Monitoring Studio's serial port sniffer, by the way, very handy).

I had been sending "WAKE ". The playground software sends "\x80WAKE " where \x80 is hex character 80.

This does the trick.

I don't see much explanation of exactly how the eighth-bit-set address byte works in commands. There is a brief mention of it on page 677 of the Smartmotor Developer's Guide, in the discussion of SLEEP.

Does it apply just to SLEEP and WAKE, or all commands?

I am guessing that when a partial byte is received (due to halting the host CPU or unplugging the serial cable), it's possible for the motor to see the high bit set, as the most significant bit is sent last, and so the motor sees \x8x and stops listening. Does that seem plausible?

I'm not using addressing at all in this application. Can the addressing feature be disabled; or, might it be prudent to precede every command by \x80?

Thanks
Brian

Re: RS232 communication lockup 10 months, 1 week ago #2176

  • csearcy
  • OFFLINE
  • Posts: 480
  • Karma: 23
Hi Brian,
The motor comes up "de-addressed". 0x80 is used for global broadcasting to all motors on the network. When SMI2 or Playground do the detect/address, they set the addresses of motors they find. With one motor... the address set will be 0x81 ...motor2 (if it exists) will be given the address 0x82.
If you had two motors (detected and addressed by SMI... or by ADDR commands in the motor programs)... and sent 0x81 with the equivalent RPA(in hex) and a SPACE or CR. The 1st motor would respond. if you sent 0x82 with the equivalent RPA(in hex) the 2nd motor would respond.
If you had two motors... and sent 0x80 with the equivalent RPA(in hex) both motors would respond.

In your case (using only 1 motor)... I would leave out the ADDR command... and just prefix all commands with 0x80.

I hope that fixes the problem.
Regards,
Chuck
Last Edit: 10 months, 1 week ago by csearcy.
  • Page:
  • 1
Moderators: hsummer, csearcy
Time to create page: 1.06 seconds