RS232 return values

18 years 5 months ago #4048536 by slauziere
RS232 return values was created by slauziere
When I send "?P
" to the motor controller, what should I expect in return?

Should I see: "?P
FF
00
"? (where FF and 00 are values of ch1 and 2, respectively?)

Basically, the question is are newline/carriage returns sent back? And if so, is it how I have it labeled above? That is the way it seems.

This is an AX3500, btw.


I am having problems querying the board through the serial port, and I am not sure where the problem exists. I am writing my code in C on Linux.

It seems successive read calls return the same thing over and over, like an infinite buffer. I'll post code samples and results shortly, but I wanted to get the above question out first.
Thanks.

-steve

Please Log in or Create an account to join the conversation.

18 years 5 months ago #4051480 by cosma
Replied by cosma on topic Re:RS232 return values
The codes are correct. FYI, Carriage Retun is Hex 0D.

Best is to first practice using a terminal emulator (Linux's Microcom will do) to verify that the controller outputs what you are expecting.

Keep in mind that the controller must first be put in the RS232 mode. By default, it is in RC mode and it will output continuous strings of characters at power up.


Please Log in or Create an account to join the conversation.

18 years 5 months ago #4056536 by tonysantoni
Replied by tonysantoni on topic Re:RS232 return values
Source code is availble at <A href="www.tsatechnologies.com" target=_blank>www.tsatechnologies.com showing how to interface to the controller via the RS232. You can freely download it.
It is in Visual Basic 6.0 and it is an emulation of Hyperterminal specifically addressed to the Roboteq controller.
You can reach me for questions in case you have any problems at
This email address is being protected from spambots. You need JavaScript enabled to view it.


Robotony

Please Log in or Create an account to join the conversation.

18 years 5 months ago #4059693 by slauziere
Replied by slauziere on topic Re:RS232 return values

cosma wrote: The codes are correct. FYI, Carriage Retun is Hex 0D.

Good to know. I need to print out a list of those. It seems like the controller returns a character of each hex digit (so FF would be two bytes...assuming a character is one byte) instead of a hex value (where FF would be one byte).

Best is to first practice using a terminal emulator (Linux's Microcom will do) to verify that the controller outputs what you are expecting.

First thing I did, actually. And I am getting the desired behavior and output from both commands and queries.

Keep in mind that the controller must first be put in the RS232 mode. By default, it is in RC mode and it will output continuous strings of characters at power up.

Yes, it is set to RS232 (non-watchdog), and not RC.


I have started grepping through minicom source to try and figure out what my problem is. Once I get to my office, I'll post output from my sample program.

Thanks for the help.

-steve

Please Log in or Create an account to join the conversation.

18 years 5 months ago #4059720 by slauziere
Replied by slauziere on topic Re:RS232 return values

tonysantoni wrote: Source code is availble at www.tsatechnologies.com showing how to interface to the controller via the RS232. You can freely download it.
It is in Visual Basic 6.0 and it is an emulation of Hyperterminal specifically addressed to the Roboteq controller.
You can reach me for questions in case you have any problems at
This email address is being protected from spambots. You need JavaScript enabled to view it.



Thanks a bunch. I have looked through the VB source briefly (saw your post in another thread). I'll take a closer look for something I might be missing in my code.

-steve

Please Log in or Create an account to join the conversation.

18 years 5 months ago #4063207 by slauziere
Replied by slauziere on topic Re:RS232 return values
ok, here is some output from my sample test program.

I am getting erratic behavior as can be seen. Each time you see a "0" and then "bytes written: 3", that means a "?P
" was sent to the motor controller. The first response is garbage. The second and third response are both expected behavior.

The fourth response is not expected. Reponses 5,6,7,8...n are all not what would be expected responses. I see it being a timing issue or a buffer issue. There is no pattern to the responses after response 3.
0
bytes written: 3
***************
buf1:
[0]: h [1]: * [2]: þ
buf2:
[0]:  [1]: ‚ [2]: 
buf3:
[0]:  [1]:  [2]:
0
bytes written: 3
***************
buf1:
[0]: ? [1]: P [2]:

buf2:
[0]: 0 [1]: 2 [2]:

buf3:
[0]: 0 [1]: 0 [2]:

0
bytes written: 3
***************
buf1:
[0]: ? [1]: P [2]:

buf2:
[0]: 0 [1]: 2 [2]:

buf3:
[0]: 0 [1]: 0 [2]:

0
bytes written: 3
***************
buf1:
[0]: 0 [1]: 2 [2]:

buf2:
[0]: 0 [1]: 0 [2]:

buf3:
[0]: ? [1]: P [2]:


And here is my C code:
/*Function Prototypes*/
int initSerial(char*);
void getCurPos(int);
void flush(int);


int main()
{
        int fd = 0, input;

        fd = initSerial("/dev/ttyS0");

        while(scanf("%i", &input) == 1)
        {
                if(input == 0)
                {
                        getCurPos(fd);
                }
                else if(input == 999)
                {
                        close(fd);
                        return 0;
                }
                else if(input == 555)
                {
                        flush(fd);
                }
        }
        return 0;
}

/*
 *      FUNCTIONS
 *                                                                                                                                           */

/**
   * initialize serial port
   *
   *
   * @param device_name - string for device to init
   *
   * @return int - file descriptor
   *
   * @todo
   */
int initSerial(char* device_name)
{
        int fd;

        fd = open(device_name, O_RDWR|O_NDELAY);

        if(fd != -1)
        {
                struct termios options;

                tcgetattr(fd, &options);

                /*set to 9600 7bit even parity, no flow control*/
                cfsetispeed(&options, B9600);
                cfsetospeed(&options, B9600);

                options.c_cflag |= (CLOCAL | CREAD);
                options.c_cflag |= PARENB;
                options.c_cflag &= ~PARODD;
                options.c_cflag &= ~CSTOPB;
                options.c_cflag &= ~CSIZE;
                options.c_cflag |= CS7;
                options.c_cflag &= ~CRTSCTS;

                tcsetattr(fd, TCSANOW, &options);
                ioctl(fd, TCFLSH, 2);
        }

        return fd;
}
/* end initSerial() */

/**
   * get position of motor
   *
   *
   * @param file_desc - serial port to send commands
   *
   * @return int - integer of point
   *
   * @todo
   */
void getCurPos(int file_desc)
{
        int j, num_written = 0, num1 = 0, cur_pos = 0;
        char buf1[3];
        char buf2[3];
        char buf3[3];
        static const char command[] = "?P
";

        /* send "?P
" */
        num_written = write(file_desc, command, 3);
        printf("bytes written: %i
", num_written);

        /* sleep 20msecs */
        usleep(2000);

        /* read */
        num1 = read(file_desc, buf1, sizeof(buf1));
        num1 = read(file_desc, buf2, sizeof(buf2));
        num1 = read(file_desc, buf3, sizeof(buf3));

        printf("***************
");
        printf("buf1:
");
        for(j=0;j&lt;sizeof(buf1);j++)
        {
                printf("[%i]: %c ", j, buf1[j]);
        }
        printf("
");

        printf("buf2:
");
        for(j=0;j&lt;sizeof(buf2);j++)
        {
                printf("[%i]: %c ", j, buf2[j]);
        }
        printf("
");

        printf("buf3:
");
        for(j=0;j&lt;sizeof(buf3);j++)
        {
                printf("[%i]: %c ", j, buf3[j]);
        }
        printf("
");


}
/* end getCurPos() */

void flush(int file_desc)
{
        printf("flusing buffer
");
        ioctl(file_desc, TCFLSH, 2);
}

Please Log in or Create an account to join the conversation.

18 years 5 months ago #4063265 by slauziere
Replied by slauziere on topic Re:RS232 return values
And as an update. If i take out the non-blocking mode ("O_NDELAY"), I do not receive junk on the first response.

I still get two good responses, then all subsequent responses are not deterministic nor desired.

I have also tried flushing the I/O buffer on the serial port after each write, but that does not seem to help. I still get erratic behavior.

Please Log in or Create an account to join the conversation.

18 years 5 months ago #4063305 by slauziere
Replied by slauziere on topic Re:RS232 return values
And here is the minicom output. Sorry for all the posts, if nothing else, this might help someone else.
Welcome to minicom 2.1

OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Apr 12 2005, 08:56:47.

Press CTRL-A Z for help on special keys

?p
02
00
?p
02
00
?p
02
00
?p
02
00
?p
02
00
!A3a
+
?p
38
00
?p
38
00

Please Log in or Create an account to join the conversation.

18 years 5 months ago #4063632 by cosma
Replied by cosma on topic Re:RS232 return values
I am not exactly sure what it wrong with your code but as you can imagine, since Roborun is capable of querying the controller and displaying results, you should be able to make it work.

The way we do is is a bit different, however.

Commands and queries are sent in a continous manner, with a 50ms interval (it is probably possible to make it faster). Queries are sent one after the other. If there is a command change, it is sent in lieu of the next scheduled query.

Separately, all the received data is read from the serial port's buffer and parsed. During the parsing is extracted the query code (that was echoed) and the reply which immediately follow. This step is totally asynchronous from the sending, and you don't have to worry about timing. The loop reads the data as they come, but should the OS do something else and suspend your program for a little while, the data is still in the buffer for parsing.


Please Log in or Create an account to join the conversation.

18 years 5 months ago #4064619 by sww
Replied by sww on topic Re:RS232 return values
Our linux software ended up working much like what Cosma described. We read into a buffer whenever there are characters on the serial port. The commands are written asnychronously.

I started out trying to time/wait for things to happen, but the code did not work well.
You problem sounds like a software problem with your buffer, not an hardware issue.

Please Log in or Create an account to join the conversation.

Moderators: tonysantoni
Time to create page: 0.085 seconds