Rapu Serial Communication, Anybody Cracked It?

jb_noob

Canada

Asked Sep 2016 — Edited Sep 2016

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!

Related Content

Synthiam

Based on your post activity, we found some content that may be interesting to you. Explore these other tutorials and community conversations.

ptp

PRO

USA

#1 Sep 2016

can you post your EZ-Script code ?

jb_noob

Canada

#2 Sep 2016

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(>)

jb_noob

Canada

#3 Sep 2016

grrrrr. the winks are hexadecimal characters! sorry

ptp

PRO

USA

#4 Sep 2016

use the code tags before and after.

do you have the EZ-Script code ?

fxrtst

PRO

USA

#5 Sep 2016

If you guys can figure this out you will be my Heros . I tried this 2 years ago and gave up. Here is my thread:

https://www.ez-robot.com/Community/Forum/Thread?threadId=5562

jb_noob

Canada

#6 Sep 2016

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?

fxrtst

PRO

USA

#7 Sep 2016

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

jb_noob

Canada

#8 Sep 2016

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.

ptp

PRO

USA

#9 Sep 2016

@jb_noob,

you need to cut some variables, if you connect the RAPU via RS232-USB to a PC and then via terminal, does the RAPU works as expected ?

jb_noob

Canada

#10 Sep 2016

yes, as noted in my comments above.

jb_noob

Canada

#11 Sep 2016

Let me outline this again:

Computer to RAPU via DB9 cable (no converters): works

Code to computer via Serial communication windows works perfectly

Code to TTL-to-RS232 into RAPU: random character switching, no success.

Code works.

Multiple TTL-to-RS232 converters work, all providing the same results in both scenarios.

Gremlin is in RAPU.
Gotta kill the gremlin.

ptp

PRO

USA

#12 Sep 2016

So it's a RAPU + Converter + EZB issue, you can't blame RAPU alone.

Did you tried different converters ?

jb_noob

Canada

#13 Sep 2016

look at above comment... (sorry, don't mean to be rude, but all the info you have asked for has already been posted, plus this stupid thing has my heart rate up to about 150 BPM, ready to fight it!)

rbonari

USA

#14 Sep 2016

I am sure you have looked into this, but if the voltage levels from the converters aren't compatible with the levels the RAPU is expecting on its serial port lines, this could be an issue. Does the RAPU expect 5 volt levels or 3.3 volt levels? If you send it 3.3 volt levels and it is expecting 5 volt levels the results could be intermittent communications. I have run into this at times communicating between two rs232 devices. Inputting 3.3 volt levels on a port pin that expects a 5 volt level may or may not work and if it does it could be intermittent at best. Rick

RobertL184

USA

#15 Sep 2016

If the text you see coming back from the RAPU always looks okay, and when you type the commands it appears to work, it could be that when you run the commands from code the RAPU is getting a buffer overrun and throwing some of the comand letters away. The RAPU may not even have a buffer.

The fix is to slow the code down when it is sending commands to the RAPU.
Typically the code will run a lot faster than your typing. The idea would be to send one character, wait a bit, send the next character, wait a bit, etc. I had a small 4 line LCD display that kept loosing text sent to it until slowed my code down. How often you need to wait is dependent on the buffer size in the RAPU and the speed of the RAPUs processor. It could take some tinkering with to figure out. Can't say for sure but that could be your problem.

The other way to wait is to send a letter and wait for that letter to be echoed back before sending the next letter.