RS232 return values
- slauziere
- Topic Author
" 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.
- cosma
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.
- Posts: 22
- Thank you received: 0
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.
- slauziere
- Topic Author
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).cosma wrote: The codes are correct. FYI, Carriage Retun is Hex 0D.
First thing I did, actually. And I am getting the desired behavior and output from both commands and queries.Best is to first practice using a terminal emulator (Linux's Microcom will do) to verify that the controller outputs what you are expecting.
Yes, it is set to RS232 (non-watchdog), and not RC.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.
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.
- slauziere
- Topic Author
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.
- slauziere
- Topic Author
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<sizeof(buf1);j++)
{
printf("[%i]: %c ", j, buf1[j]);
}
printf("
");
printf("buf2:
");
for(j=0;j<sizeof(buf2);j++)
{
printf("[%i]: %c ", j, buf2[j]);
}
printf("
");
printf("buf3:
");
for(j=0;j<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.
- slauziere
- Topic Author
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.
- slauziere
- Topic Author
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.
- cosma
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.
- sww
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.