Canada
Asked — Edited

Rapu Serial Communication, Anybody Cracked It?

Hi Folks

Unfortunately Brookshire's documentation on the RAPU is lacking many details. The short section on controlling with serial is fine, if you are connected to a COM serial port with an ancient DB9 straight-through cable (or USB-to-RS232 converter). Pull up RealTerm or similar, set the 19200 baud rate, and power up the RAPU. Console shows the boot up and the command prompt is hot and ready in your terminal window. Commands work exactly like they are shown in the manual.

NOW...

Get that to work with your microcontroller.

Yes, you will need a TTL-to-RS232 converter (5V level).

Yes, you need to code a "serial wrapper".

Yes, you should be able to use the same command in the manual through serial communication from your controller to the RAPU.

It doesn't work!

I have been fighting this for a good long time, love some tips or to hear some success stories.

Here's where I'm at:

  • I can "see", using a serial monitor window, all commands and boot-up text and an active prompt
  • Despite using CRLF formatting it trips-up the input commands. For example it will not take in an "a". So if I type in "play" it reads "ply" and reports that it is an unrecognized command.....DUH!

For the record YES, I'm sending 8-bit, no parity, one stop bit at 19200 baud.

Seems like there something else a tiny bit off. For fun I tried shifting the baud rate. No real significant changes from about 19100 to 19300, outside that is gibberish.

Soooo close!

Ideas?

TIA!


ARC Pro

Upgrade to ARC Pro

Unlock the true power of automation and robotics by becoming a proud subscriber of Synthiam ARC Pro.

#2  

Here are the results from the serial monitor, maybe this will give a clue:

Command OK: $$1. Terminator set to CRLF Sent: 0x3E(>) 0x3E(>) 0x3E(>) 0x70(p) 0x6C(l) 0x61(a) 0x79(y) 0x0D 0x0A Sent: 0x0D 0x0A >>> 0x3E(>) >>> 0x9E() >>> 0x70(p) >>> 0xB1(±) 0x79(y) 0x8A() 0x0D >>> 0x0A >>> 0x75(u) 0x6E(n) 0x72(r) 0x65(e) >>> 0x63(c) 0x6F(o) 0x67(g) 0x6E(n) >>> 0x69(i) 0x7A(z) 0x65(e) 0x64(d) >>> 0x20( ) 0x63(c) 0x6F(o) 0x6D(m) >>> 0x6D(m) 0x61(a) 0x6E(n) 0x64(d) >>> 0x3A(:) 0x20( ) 0x3E(>) 0x9E() >>> 0x70(p) 0xB1(±) 0x79(y) 0x8A() >>> 0x0D 0x0A 0x3E(>)

#3  

grrrrr. the winks are hexadecimal characters! sorry

PRO
USA
#4  

use the code tags before and after.

do you have the EZ-Script code ?

#6  

I seriously suspect something is wrong in the RAPU. This is a brand new unit! It is randomly garbling communication. In fact if you plug it directly into a DB9 serial port and - again - use RealTerm it will accept even "p" as a legit command! BUT even though pulling the RAPU out of the system and sending any characters or strings from the code back into the serial port on the computer it reads perfectly in realterm. Baud rates are consistently 19200.

I call foul.

Did you get any support from brookshire on this?

PRO
USA
#7  

Only what was quoted in my thread. They responded to me once with regards to carriage return etc

#8  

That's the frustrating part: I can see why the format would mess up the strings placement (carriage return, new line, etc etc ), but that does not explain random garbled characters coming back. You should see at least the same characters you typed in.

Anybody out there a wiz at debugging RS-232 communications? I have consulted a few and they have never seen something like this.