jb_noob
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!
Skip to comments
can you post your EZ-Script code ?
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(>)
grrrrr. the winks are hexadecimal characters! sorry
use the code tags before and after.
do you have the EZ-Script code ?
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://synthiam.com/Community/Questions/5562
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?
Only what was quoted in my thread. They responded to me once with regards to carriage return etc
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.
@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 ?
yes, as noted in my comments above.
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.
So it's a RAPU + Converter + EZB issue, you can't blame RAPU alone.
Did you tried different converters ?
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!)
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
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.
@jb_Noob what version of the RAPU do you have? Is it the new one with current firmware? I was using the older v3.13 firmware on an older RAPU.
Has anyone ready rbonari's response? Or acknowledged the voltage specifications?
The RAPU requires a 3.3v to 5v ttl converter.