Packet Serial Raw Command Structure

[RangerDave]

Hey Guys, I picked up a few Roboclaw 2x15a Motor Controllers for a project but i'm having to script my own driver from scratch because the control system i am using is a crestron processor. Simple Serial works perfectly fine but i definitely want to make a much more functional and reliable driver and for the life of me i cant figure out the packet serial commands i need to structure, whether its because im not creating the CRC right or what. If someone can post a few example of RAW serial commands and breakdown there structure and how they got the crc16 value it would be most help full. with a few examples in its raw form i should be able to go from there.

[Basicmicro Support]

The CRC is the tricky part for the packet serial structure. Commands are laid out in this basic format:

For write commands
address, command, arg1, ... argn, crc high byte, crc low byte

For read commands
send: address, command
receive data1, ... , dataN, crc high byte, crc low byte

The CRC is calculated across all bytes, sent and received for a single command packet.

I definitely recommend you look at the arduino library source code and/or the python library code to see how the CRC is calculated. The arduino library is almost pure C++ so snippets can be taken from it for almost any processor that supports C++.

[RangerDave]

I've looked at the c# code as well as the c code thats in on of the pdf's and to the best of my ability have tried to calculate the crc and i have yet to get it to respond one and even the command structure isn't exactly laid out to tell me exactly what it wants from me. first, is it expecting straight up hex values for the motor ID, command and speed? for instance 0x80 0x01 0x7f then the crc value? Even if i can just get get the exact commands itll except for full forward, forward stop, full reverse and reverse stop that will get me off to the races and i can go more later but i would really like to just have the absolute calculations for the crc and exactly what its expecting for the primary command string. Whats also wierd is when in standard serial, i can get the motors to respond but it doesn't do it in a way that seems like im still even sending the right command. for instance 1 will go what seems to be full reverse but then 2 goes say forward at a very slow speed and so on. the above isn't exact but it definitely wasn't linear in the speed nor the direction as i played with the commands. 64 also didn't make it stop and if i remember correctly it was reversing at a snails pace so even that doesn't appear to be well documented since the behavior is erratic and it may still be wanting to receive the commands in a different way. any absolute raw in formation and calculations would help. even if you literally just copy and paste what is being send to the motor for those raw commands so i can atleast get things functioning and deal with making my own c+ drivers later.

[Basicmicro Support]

You need to make sure your serial commands are sending actual bytes and not converting your numbers in to ascii strings. They are not the same thing. If your serial commands are sending strings this would explain your problems with standard serial as well.

Providing some code snippets of what you have done so far may help. Right now we have no information on what you are actually doing in your code.

[RangerDave]

I haven't started coding anything as im trying to figure out how to do it manually before i can start the code. I know its sending the actual hex bytes and not ASCII, with Crestron i can hook up to a device, set baud rate etc and send commands in live view and see the rx/tx as things communicate. i've been trying to work out on paper the crc calculation and follow the c code the best i can to mimick the calculations. I've sent \x80\x01\x7f with the last hex value on every crc calculation i've come up with with no response. I've controlled many other devices such as Qmotion shades that use hex as communication and it was fine, i just need to find out the actual straight up calculation thats going on. and if you can even for now supply me those 4 raw hex commands with the proper calculated crc, then at least i can get these motor controllers functioning and i can deal with figuring out the crc calculations and coding it later.

[Basicmicro Support]

If you are manually sending the bytes your timing may not be fast enough(I dont know how your terminal program transmits your manual bytes). The Roboclaw will drop the packet if the delay between any byte in the packet takes longer than 10ms. So typing them in one by one will never work if they are sent out as you type them.

There is nearly zero chance you can calculate the CRC16 checksum manually. You need to use a CRC16 checksum calculator.

Use this calculator: http://crccalc.com/?crc=123456789&method=ascii

The results for CRC-16/XMODEM should be the correct values(sorry I have not had a chance to setup a program to test this). Make sure you set the input type to Hex of course. For 80 01 7F I get 87 13 for result. However it may be the Check value you need(31 C3). I've not used this online calculator before and the one I used in the past appears to no longer be available.

[RangerDave]

So i played around with it again today with no luck. Everything is being sent through as straight up hex, including the simple serial that's also not reacting as expected, IE 64 0x40 sends it full speed forward while it should stop the motor. for the packet serial, i tried the results from your message as well as others from that calc with no luck an i even made a script with a 20ms delay to brute force the crc with 0 luck, all the way from 0x80 0x01 0x7F 0x00 0x00 to 0x80 0x01 0x7F 0xFF 0xFF. Crestron controller is tx to s1 rx to s2 and ground to ground. Below is a screen shot of the end of the brute force as well as the exact Hex values being send over the TX to the motor controller. On your side, is there any way to see the exact commands being sent to your controller that should 100% work instead of going off of a calculator that "should be correct" theoretically something else must be going on since i've sent it every possible crc unless there is yet something else i am missing.

https://imgur.com/a/JtyBV

[Basicmicro Support]

The simple solution would be to install python on your PC and then modify the python library to print the calculated packet data to the screen when its talking to the Roboclaw. Im assuming you have access to either a Linux or Windows PC, not just the Crestron controller. If you have a Linux PC python(2.7) is usually already installed. You will also need to install the pySerial library for python.

Im getting ready for ATX this week and will be gone for most of next week(at that show) so I wont have an opertunity to make that modification until I get back.

Assuming you get the packet data confirmed from the above, if you are still having problems talking to the Roboclaw the next step would be to look at the data on a scope. Check the bit rate timings. See if the Roboclaw is acking the packet or not. Low the baud rate if it still isnt working.

[RangerDave]

I played around with it even more today and forgetting about Packet Serial, even the simple serial (like i previously mentioned) is working very erratically. I even brought another processor with me and tried the 1 way serial ports they have as well and i get no different behaviour and that's also trying all available baud rates AND hooked directly up to my computer and saw the same behavior. for example 0x01 goes full forward 0x02 stops it completes 0x03 goes forward at a hair less speed then 01, 0x04 goes slowly backwords, 0x05 slowly forwards 0x06 stops it, 0x07 goes forward at maybe 3/4 speed, 0x08 goes backwords, 0x40 goes what appears to be full backwords and so on. Also note that no matter what i put in the second motor absolutely never moves via serial command. Anything i've tried over 0x80 does nothing.

So my thought is that i cant even talk accurately to these controllers in simple serial mode so i bet its not even sending what i want for the packet serial. If you have any other suggestions to get these things working properly then let me know, otherwise i'll have to try another rs232 motor controller for this project.

[Basicmicro Support]

1. The Roboclaw is NOT RS232. RS232(direct connection from your PC) produces +-12v signals. The Roboclaw can not read that and it could damage the Roboclaw. Please confirm you are using TTL(0 to 5v) signalling.

2. We've never used the microcontroller you are using so we cant be of much help with it.

3. Simple serial has no error correction so if there is a communications problem it will ack very weird.

Based on your description of what you sent via simple serial your communications are completely wrong/garbage. Can you produce an oscilloscope trace of a single command you are sending with timings? Also what baudrate are you using in simple serial?