Hello,

I'm attempting to talk to a maxon motor controller through the RS232 interface. I've created a serial port and I'm using the putc and getc commands.

The way the communication works is that I send the first byte, wait for a byte in reply, and then continue to send the rest of the packet.

The first communication works fine.

On all the communications after, I do a putc IMMEDIATELY followed by a getc, however (using a comm analyzer) I see that I put my byte, the motor controller responds with a byte, however it isn't picked up by the getc like in the first communication.

I've tried slowing down the baud rate, which should give ample time for the mbed to get the byte compared to the first communication.

It appears to me that the mbed is simply missing the byte from the getc, however I don't see any reason why this should happen considering it catches the first communication.

Any ideas?

What kind of RS232 voltage level converter are you using?

Hey Jim,

It's a Max232cwe that we just got and are using. We're able to successfully send the first command which will get the motor to move, however each command after that fails since the mbed doesn't read the "ready to receive" byte from the controller.

You might just jumper the TX pin to the RX pin after the converter to make a loopback test. That would eliminate most of the mbed hardware issues. Also might setup the LEDs to show if you are in the TX or RX state in your mbed code.

You could just try it out using a serial bridge code and a terminal application window attached to mbeds serial USB port (like for printf) to see exactly what happens. Whatever you type gets sent out on the serial port and whatever comes back displays in the terminal application window.

#include "mbed.h"

Serial pc(USBTX, USBRX); // tx, rx
Serial device(p9, p10);  // tx, rx

int main() {
    while(1) {
        if(pc.readable()) {
            device.putc(pc.getc());
        }
        if(device.readable()) {
            pc.putc(device.getc());
        }
    }
}

Motors take a lot of power, I assume they are on a different power supply and the grounds are connected.

P.S. If the motors are on the same power supply, inrush current to start motors could put noise on the power supply and crash or reset mbed. A different supply or decoupling caps might fix it.

I also like RealTerm a bit more for the terminal application - it displays RS232 lines and will display data in hex.

Also assume that the motor controller does not use RS232 handshaking.

Thanks Jim, trying this now and I'll get back to you.

hey Jim I'm pretty confident that the motors are sending the information correctly and that the controller initially sends the commands correctly not to mention I'm fairly confident that the power supply isn't putting any noise into the system through the motor controllers (the motor controllers are fairly high end and I doubt they are sending any noise over the bus, if they were I'd likely see a jump in the logic analyzer not to mention the max current I'm pulling on the motor controller is around .1 amps at 12 volts and both the controllers and power supply are rated for much more). The issue that I think is happening is there some sort of issue with the getc command, I believe it is stuck on the serial chip my theory for this is:

1: the first transmission works flawless, if I send a command byte I get a reply from the motor controller if "Ok" data gets sent, if "Fail" it tries the command byte again. That being said if I send successive transmissions where both command bytes receive an "Ok" the first set will get sent but the second transfer will not be sent and will repeat the command byte. Even after the motor controller reaches timeout. Basically it seems like the Mbed won't "read" from the RX line twice. 2: the only time that the transmission fails is when I try and send successive commands in one file. If I send a command, edit and re-download the code or if I just reset the Mbed and have it send the command again it works fine. 3: the motor controller is responding and due to the fact that I have a logic analyzer that will decipher the bytes being transferred I can see the "Ok" or "Fail" command being sent so it makes it easier to decipher where the fault might lie. 4: I've tried resetting the baud rate in the middle of my code but that doesn't seem to "clear" the issue I'm having, maybe if I reinitialize the bus it might "clear" it. Ideally I would be able to see whats going on with mbed for that command but as of right now I can't.

I guess the next step would be to try and send successive bytes back and forth over the single bus but I'm not sure if that will run into any timing errors.

One last idea - if it is so fast that you lose characters - check out the MODSERIAL code in the cookbook

http://mbed.org/cookbook/MODSERIAL

It is interrupt driven with a big buffer. The UART buffers a few characters, but not big enough at higher baud rates without handshaking. It is easy to change over and try. I had to use it on a GSM modem to get it to work.

At the other end, I had a serial device once where mbed was too fast and I had to put a wait() between characters or commands. The device at the other end lost characters when I sent them too fast.

If the motor controller sends just a single byte in return then the UART's buffer should handle that with ease. I would go for a loopback test first and see if the byte you are sending gets into the receive buffer. What baudrate are we talking of ?

Yeah I thought it might have something to do with baud rate but I tried both ends of the spectrum, 115200 (the motor controller default speed) and 9600 and in both cases it's not reading that confirm byte. The interesting thing about the mbed's serial communication is despite being documented as taking in an integer to write to the bus in fact it only ends up writing a single byte and I assume it's the same for the read. I guess really the only thing to do is do a loopback but I can't seem to get two serial COMs to work simultaneous ie if I have information running on pins 9 and 10 I can't run a terminal to watch print statements on my computer so I'll need to create a local file to store the information passed back and forth. I guess my question to anyone is can they get 2 serial communications working simultaneously? by initializing both the USBTX and USBRX as well as p9 and p10 and have both send and receive information. And my final overarching question is if the getc command is held in a while loop so that it is constantly trying to read or if I need to first use the reader command to recognize a byte is ready to be sent and then to read it.

I would use a PC to emulate the motor, as one test,

And replace MBED with PC, to test if you are sending, receiving bytes.

Also, if you are waiting for a byte, that never gets sent from the motor You could be waiting for a VERY LONG TIME :)

If the motor is expecting a value, or command, then I am guessing, It will wait until the end of the string.

what motor is it ?

Maybe someone is familiar with it !

Ceri

Well I can see the motor controller (Maxon EPOS 24/2) is responding (via the logic analyzer which listens in on a bus communication and deciphers whats going in and out) within milliseconds regardless of it being the first frame that I send or the second. I also have sent commands via a PC to the motor controller and had it respond. And the motor controller has a timeout feature (500ms) which is why when I try and send the command byte over and over because I haven't received a confirmation on the RX line the controller doesn't continue to respond with the confirmation "Ok" byte multiple times but instead leaves the communication open waiting for the data portion of the frame. Essentially I could lower the timeout feature on the motor controller but I don't think that would solve my problem and I'm pretty convinced that it has to be in the software for the Mbed considering the hardware should easily be able to receive multiple bytes and because the information is getting passed back onto the bus it simply isn't being read on the Mbed side.

Maybe the character from the mbed is not sent at all and is still in the output buffer ?

See: http://mbed.org/forum/bugs-suggestions/topic/1849/?page=1#comment-9216

Maybe it is also possible to disable the buffer completely.

At that high of a baud rate without handshaking you will definitely need MODSERIAL. Even if it is not the problem now, it will be later.