|
Serial Communication
DWDY from United States [2 posts] |
14 year
|
Hello,
We are having some interfacing problems in Roborealm. When we try to communicate with our Roboteq AX2550 Motor Controller, we send a hexadecimal command “!A19” which should command our channel 1 motor roughly %20 throttle, forward. We first sent this as a trial, from our motor controller’s software (Roborun), to the motor controller (Roboteq Ax2550). The motor controller reads and echoes (+) it correctly and our motors respond. When we send that same command from Roborealm’s console serial module, it echoes the same command we sent but we aren’t getting any response from our motors. (a “+” response from the motor controller equals an executed command)
We think Roborealm is changing our command, due to the same command being sent ,with different results. Another potential problem may be the start bit(removing the start bit),. Roboteq is very specific in what serial it wants (9600 baud, 7-bit data, 1 start bit, 1 stop bit, even parity). We are able to set all of these parameters correctly, with the exception of the start bit.
Any information/help would be greatly appreciated.
Thanks in Advance,
DWDY
|
|
|
|
Anonymous from United States [28 posts] |
14 year
|
|
One thing you may check is the CF, sometimes things look for a CF or a return, and others don't. I'm not sure about the Roboteq protocol, but I'll do some reading and see if I can give you guys hand.
|
|
|
|
DWDY from United States [2 posts] |
14 year
|
Thanks for the quick response, we've resolved most of the issues we were having. We found out that the issue of no motor response was due to the lack of a correct carriage return"<cr>". Initially we had placed it at the end of our VB script we concatenated it with the command structure that the roboteq motor controller expected and it wouldn't execute the command, but it would execute motor commands by manually sending them in the serial console window
( !A7F<cr> = Channel 1 100% forward) . We then removed the "<cr>" from the VB script and manual put in the carriage return in the "send sequence" serial window and it has been working well ( [Variable]<cr> ). Also, apparently the start bit is automatically inserted into the frame, so no problem there.
This is the code we are using currently
nvLMotor128 = GetVariable("NV_L_MOTOR_128")
SetVariable "left_motor", hex(nvLMotor128/128*(32)+00)
left_motor = hex(nvLMotor128/128*(32)+48)
nvRMotor128 = GetVariable("NV_R_MOTOR_128")
SetVariable "right_motor", hex(nvRMotor128/128*(32)+00)
right_motor = hex(nvRMotor128/128*(32)+48)
SetVariable "Output_L", "!B" & left_motor
SetVariable "Output_R", "!A" & right_motor
|
|
|
|
Anonymous from United States [28 posts] |
14 year
|
|
Excellent, that was the problem I was expecting to see. Great to hear you got it working!
|
|
|
|
Anonymous |
14 year
|
DWDY,
The issue you were having is the different formats being used. Within VB you would need to append a CR as in
SetVariable "test", "my text line" & CR
which appends a carriage return at the end of the line (or \r in c++).
Like wise
SetVariable "test", "my text line" & CRLF
would append \r\n which some systems need.
Within the serial module it understands <cr> and <lf> instead but NOT when it comes from a variable. The values in the variables are NOT interpreted so if you add a "<cr>" as part of the VB variable setting this is not seen by the serial module. This is to avoid incorrectly processing values that may or may not contain out of band commands meant for the serial module.
Hope this helps clarify the issue.
STeven.
|
|
This Thread