|
|
|
Supreme Being
Group: Administrators
Last Login: Monday, October 31, 2011 9:18 PM
Posts: 640,
Visits: 819
|
|
| It sounds like you have some bugs in your code that implements the protocol. What's happening is that you send one command that is correct, and it works, then you send another one that might not have a '\r' on the end and isn't correct, then send another command that's correct. What will happen is that the serializer tries to interpret both of those commands as one, and NACKs them. For instance if you sent this sequence of commands: 'digo 1:40 2:40\r' 'pids' 'stop\r' Notice the 2nd command doesnt' terminate with a '\r'. So, when the 3rd command is sent, the serializer tries to interpret 'pids stop\r', since that's what's in the receive buffer. BTW, the receive buffer empties when it sees the terminating '\r' and processes the serial command buffer. Otherwise, the characters are buffered. Are you terminating every command with a '\r'? Are you parsing the return values correctly? You should be sending a command like 'digo 1:30 2:30\r', and getting back an response like '\rACK\r>'. Best Regards!
Jason Summerour
President,
Summerour Robotics Corporation
www.roboticsconnection.com
|
|
|
|
|
Supreme Being
Group: Administrators
Last Login: Monday, October 31, 2011 9:18 PM
Posts: 640,
Visits: 819
|
|
WoW! That's an awesome video Modena4re! I need to get your pics posted up on the Featured Customer Project pane...I forgot to do that!  Thanks for sharing this video, and your project information. I LOVE to see customers leverage our products for such projects. I'm jealous! I wish I had time to work on your project! Best Regards,
Jason Summerour
President,
Summerour Robotics Corporation
www.roboticsconnection.com
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: Saturday, April 24, 2010 11:05 AM
Posts: 22,
Visits: 32
|
|
rpid t was the first configuration attempt I tried. This is the same serializer I was having problem with earlier getting the motors to settle and I had to up the B parameter to 25 in the dpid settings.
We are also implementing the '\r' after every command, because we have a separate function in our code that sends every command string to the serializer with a '\r'. This problem isn't the serialzer giving a 'nack'..sometimes it does 'nack', but other times it just completely ignores the commands..no nack, no ack, no nothing. I also tried reloading the firmware to version 3 and after reloading it, all of the previous default values I set on the serializer did not get reset to the defaults the serializer came with...should the default values be reset if I reload the firmware?
|
|
|
|