CRC Issues in Serial Packet Mode

General discussion of using Roboclaw motor controllers
bsorel
Posts: 18
Joined: Sat Jan 16, 2016 11:02 am
Not reading Encoder

Post by bsorel »

I've posted earlier about my using a PIC to control the RoboClaw 2x7 and man, nothing is coming easily! Sorry to post so often but it appears I've exhausted all my troubleshooting options. Anyways, in my application I have a 10K pot on a linear actuator. I've used a 15k resistor to bring the voltage down to 2V. I've used the ION Motion program to manually control the actuator and have watched the encoder count up and down. No problems there. I've checked my own uart because I've not been able to read anything from the RoboClaw. My UART is fine, checked it with a small program I wrote. I'll send the code where I issue a request to check the position of an encoder. I first send address then the command. I then attempt to read back the four bytes of encoder data but i receive nothing. Not garbage just nothing. I've attempted placing small delay between my read and write commands but that did not improve the situation. I'll attach the code but could someone call me tomorrow? I'm up against it here. Thanks, in advance. Yes i know it was overkill printing each byte but i wanted to be sure it wasn't a bit shift issue.

Code: Select all

           SPI_Ethernet_24j600_doPacket() ;  // process incoming Ethernet packets
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "OK:4", 4);
           uart1_write(address);
           uart1_write(M1_Position);
           //delay_ms(1);
           M1_byte3 = uart1_read();
           M1_byte2 = uart1_read();
           M1_byte1 = uart1_read();
           M1_byte0 = uart1_read();
           encoder1 = (M1_byte3 << 24) | (M1_byte2 << 16) | (M1_byte1 << 8) | M1_byte0;
           uart1_write(address);
           uart1_write(M2_Position);
           //delay_ms(1);
           M2_byte3 = uart1_read();
           M2_byte2 = uart1_read();
           M2_byte1 = uart1_read();
           M2_byte0 = uart1_read();
           encoder2 = (M2_byte3 << 24) | (M2_byte2 << 16) | (M2_byte1 << 8) | M2_byte0;
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Encoder1", 8);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, encoder1, 4);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Byte3", 5);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, M1_byte3, 1);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Byte2", 5);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, M1_byte2, 1);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Byte1", 5);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, M1_byte1, 1);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Byte0", 5);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, M1_byte0, 1);
           //SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Encoder2", 8);
           //SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, encoder2, 4);
           receive = 0;
          }
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: CRC Issues in Serial Packet Mode

Post by Basicmicro Support »

Please do not start a new topic for the same problem.

Just to be sure, you are using a TTL(5v or 3.3v) serial connection to the Roboclaw? I know you are using a PIC so I was assuming you were but I figured I better make sure.

So basically what you have now is a simple read back command that doesnt seem to be reading anything back. What baudrate are you setting the uart to(we cant tell since the program is incomplete). If you are having problems communicating the first thing I suggest is to lower the baudrate. Actually the first thing I suggest is making sure you have the latest firmwrae installed on the roboclaw but I think you already did that.

When you were accidently in Simple Serial mode the Roboclaw motors would run when you sent data to it. This shows that the Roboclaw was able to read data from your PIC. When in simple serial even garbage data(incorrect baudrate and/or random values) would cause the motors to do something most of the time but it does atleast let you know te roboclaw receives data.

With the code you have provided we cant really know what is going on. It isnt a complete program and even if I had a PICmicro to work with I couldnt use it with the code as provided. In the future please include the complete program code your are testing, preferable simplified to the bare minimum required for the test you are conducting.

From the start we made some assumptions we probably shouldnt have. Please describe how you have everything wired up to the roboclaw. How you have everything powered as well. Since the original problem was asking about the CRC calculation I never really asked the basic questions.
bsorel
Posts: 18
Joined: Sat Jan 16, 2016 11:02 am
Re: CRC Issues in Serial Packet Mode

Post by bsorel »

1. I am using a TTL 5V serial connection to the RoboClaw.
2. I can send serial packet commands to the RoboClaw with a precalculated CRC no problems there. Motors turn, stop all that good stuff.
3. I cannot read from the RoboClaw using serial packet commands.
4. I am running at a baud rate 57600. I have tested out using serial watcher and my transmits are perfect.
5. My firmware is version 4.1.16
6. I have included the bared down version of my program. It probably won't compile but substituting the UDP commands for UART would resolve the problems probably. If you require this version i could work on that.
7. I have a 12V power supply connected to the robo Claw. Jumper across LB-MB. Motor wires into M1A M1B. Serial connections from the PIC TX to S1, RX to S2. Encoder is powered from the 5V supply on the RoboClaw, with a series 15K resistor. The wiper is connected to the board edge of EN1.
8. Here is the simplified code.

Code: Select all


#include  "__EthEnc24j600.h"
#include <toInt.h>
#include <stdint.h>

#define NULL 0
#define putConstString  SPI_Ethernet_24j600_putConstString
#define putString  SPI_Ethernet_24j600_putString


/*unsigned integer types*/
typedef uint8_t u8;/**< used for unsigned 8bit */
typedef uint16_t u16;/**< used for unsigned 16bit */
typedef uint32_t u32;/**< used for unsigned 32bit */


/*signed integer types*/
typedef int8_t s8;/**< used for signed 8bit */
typedef int16_t s16;/**< used for signed 16bit */
typedef int32_t s32;/**< used for signed 32bit */

/***********************************
 * RAM variables
 */


char uart_rd;
u8 crc_msb;
u8 crc_lsb;
u8 address = 0x80;
u8 M1_Forward = 0;//0x00;
u8 M1_Reverse = 1;//0x01;
u8 M2_Forward  = 4;//0x04;
u8 M2_Reverse = 5;//0x05;
u8 drive_M1 = 6;//0x06;
u8 drive_M2 = 7;//0x07;
u8 reverse_quarter = 16;//0x50;
u8 stop = 0;//0x40;
u8 quarter_speed = 32;//0x20;
u8 half_speed = 64;//0x40;
u8 three_quarter_speed = 96;//0x60;
u8 full_speed = 127;//0x7F;
u8 M1_byte3; //high byte
u8 M1_byte2;
u8 M1_byte1;
u8 M1_byte0; //low byte
u8 M2_byte3; //high byte
u8 M2_byte2;
u8 M2_byte1;
u8 M2_byte0; //low byte
u8 M1_Position = 16; // 0x10;
u8 M2_Position = 17; // 0x11;
u32 encoder1;
u32 encoder2;
u8 S3S4S5_Modes = 74;//0x4A;
u8 e_stop_en = 0x02;
u8 e_stop_clr = 0x00;
char receive;
u8 RoboClaw_status;

 
void    main()
{
        //Setup I/O
        ADCON0.b0 = 0; ; // AD converter off
        ADCON1 = 0xFF;
        CMCON = 7 ; // turn off comparators
        
        //Setup Port A
        PORTA = 0x00;          //Clears Registers
        TRISA = 0x01;          // set PORTA RA0 as input all the rest as outputs

        
        //Setup Port D
        PORTD = 0;
        TRISD = 0;                    // set PORTD as output
        
        //Setup Port E
        PORTE = 0;
        TRISE = 0;                    // set PORTD as output
        
        //Setup Comms
        UART1_Init(57600);            // Initialise USART communication
        Delay_ms(400);                // Allow time delay to stabilize
        
        //Setup Timers

        T0CON = 0xC7;                 // Timer On, 8bit, external clock, low to high, prescaler assigned, 1:256 ratio
        TMR0IE_bit = 1;                   // Timer Disabled
        PEIE_bit = 1;
        delay_ms(200);
        /*
         * CS bit on RC1
         * my MAC & IP address
         * full duplex
        */

        SPI1_Init();       // Initializes SPI Registers on the MCU
        delay_ms(200);
        SPI_Ethernet_24j600_Init(myMacAddr, myIpAddr, SPI_Ethernet_24j600_AUTO_NEGOTIATION) ;  // Intialize serial ethernet controller
        asm CLRWDT;

        while(1)
         {
          SPI_Ethernet_24j600_doPacket() ;  // process incoming Ethernet packets
          asm CLRWDT;   //Clears watchdog timer

          if(receive == 1)  //Half Speed Command Up
           {
            getRequestUDP[0] = 0;
            SPI_Ethernet_24j600_doPacket() ;  // process incoming Ethernet packets
            SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "ok:1", 4);
            uart1_write(address);
            uart1_write(m1_forward);
            uart1_write(half_speed);
            uart1_write(0x73);
            uart1_write(0x9E);
            delay_ms(10);
            //RoboClaw_status = uart1_read();
            //SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, roboclaw_status, 1);
            RoboClaw_status = 0;
            uart1_write(address);
            uart1_write(M2_forward);
            uart1_write(half_speed);
            uart1_write(0xBF);
            uart1_write(0x5A);
            delay_ms(10);
            //RoboClaw_status = uart1_read();
            //SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, roboclaw_status, 1);
            RoboClaw_status = 0;
            receive = 0;

            SPI_Ethernet_24j600_doPacket() ;  // process incoming Ethernet packets
           }
           
          if(receive == 2)  //Half Speed Command Down
           {
            getRequestUDP[0] = 0;
            SPI_Ethernet_24j600_doPacket() ;  // process incoming Ethernet packets
            SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "ok:2", 4);
            uart1_write(address);
            uart1_write(M1_Reverse);
            uart1_write(half_speed);
            uart1_write(0x40);
            uart1_write(0xAF);
            delay_ms(10);
            //RoboClaw_status = uart1_read();
            //SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, roboclaw_status, 1);
            RoboClaw_status = 0;
            uart1_write(address);
            uart1_write(M2_reverse);
            uart1_write(half_speed);
            uart1_write(0x8C);
            uart1_write(0x6B);
            delay_ms(10);
            //RoboClaw_status = uart1_read();
            //SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, roboclaw_status, 1);
            RoboClaw_status = 0;
            receive = 0;
           }
          
          SPI_Ethernet_24j600_doPacket() ;  // process incoming Ethernet packets

          if(receive == 3)  //Motor Stop
           {
            SPI_Ethernet_24j600_doPacket() ;  // process incoming Ethernet packets
            SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "ok:3", 4);
            uart1_write(address);
            uart1_write(M1_Forward);
            uart1_write(stop);
            uart1_write(0x3B);
            uart1_write(0x5A);
            delay_ms(10);
            RoboClaw_status = 0;
            uart1_write(address);
            uart1_write(M2_Forward);
            uart1_write(stop);
            uart1_write(0xF7);
            uart1_write(0x9E);
            delay_ms(10);
            RoboClaw_status = 0;
            receive = 0;
           }
          
          SPI_Ethernet_24j600_doPacket() ;  // process incoming Ethernet packets

          if(receive == 4)  //Encoder Read
          {
           getRequestUDP[0] = 0;
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "OK:4", 4);
           uart1_write(address);
           uart1_write(M1_Position);
           //delay_ms(1);
           M1_byte3 = uart1_read();
           M1_byte2 = uart1_read();
           M1_byte1 = uart1_read();
           M1_byte0 = uart1_read();
           encoder1 = (M1_byte3 << 24) | (M1_byte2 << 16) | (M1_byte1 << 8) | M1_byte0;
           uart1_write(address);
           uart1_write(M2_Position);
           //delay_ms(1);
           M2_byte3 = uart1_read();
           M2_byte2 = uart1_read();
           M2_byte1 = uart1_read();
           M2_byte0 = uart1_read();
           encoder2 = (M2_byte3 << 24) | (M2_byte2 << 16) | (M2_byte1 << 8) | M2_byte0;
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Encoder1", 8);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, encoder1, 4);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Byte3", 5);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, M1_byte3, 1);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Byte2", 5);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, M1_byte2, 1);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Byte1", 5);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, M1_byte1, 1);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, "Byte0", 5);
           SPI_Ethernet_24j600_sendUDP(destIP, sourcePort, destPort, M1_byte0, 1);
           receive = 0;
          }

        }
}
bsorel
Posts: 18
Joined: Sat Jan 16, 2016 11:02 am
Re: CRC Issues in Serial Packet Mode

Post by bsorel »

Update: I tried lowering the baud rate and still the problem remains. I can sent ttl level commands but don't appear to be receiving any telemetry. Since I know my UART works and the encoders can be read on the USB end of the RoboClaw could there be a problem with the TTL level function of the RoboClaw? S2 I believe is connected to my RX.
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: CRC Issues in Serial Packet Mode

Post by Basicmicro Support »

If you can check the S2 pin on the Roboclaw with a scope we could see if there is a problem with the levels.

Also you can add a pullup to the S2 pin(to 5v) to see if the level is too low for the PIC. The Roboclaw is a 3.3v device with 5v tolerant pins so its output level is only about 3v which may not be high enough(though PICs should handle the 3.3v signaling just fine).

You may also want to check if the Multi-Unit mode is enabled on the Roboclaw. If it is then the S2 pin only outputs low values or floating values(eg requires the external pullup).
bsorel
Posts: 18
Joined: Sat Jan 16, 2016 11:02 am
Re: CRC Issues in Serial Packet Mode

Post by bsorel »

Could I please get in touch with someone for phone support??? I'm really in a time crunch here and i need some resolution. And no I can't call the 1-800 number from Canada. I'm happy to give you mine though. I will answer these questions again:

No it is not in mult-unit mode.

I pulled up S2 to 5V on my board. This has caused everything to stop working. If I power up my board (that has the pic) before the roboclaw it goes into e-stop fault or all three lights on. If i power up the roboclaw first then my board no error lights but no functionality either. Now i cannot send commands either. The roboclaw looks like its drawing less current than before about 60mA but i wasn't really paying attention to it earlier. So the TTL seems to be completely gone.

There is nothing on the scope on the S2 lines other than 5V. Even when being flooded with commands for telemetry. There is something wrong with this board. Please contact me.

Edit: I can control the Roboclaw through the Ion Motion program through using the PWM commands. Encoder reads as well so the problem appears to be contained to the TTL Serial Packets.
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: CRC Issues in Serial Packet Mode

Post by Basicmicro Support »

The non-800 number, for international callers is: (714)442-8689

The Robocl pins are 5v tolerant so adding the 5v pullup should not have caused any problems. Where did you get the 5v from for the pullup and what was the value of the resistor you used?

I sense you are getting upset. That will only make this harder.

1. Remove the pullup and check S2 again. It should be at approx 3v when idle(and set to Packet Serial mode).
2. When idle, the roboclaw pulls between 30ma and 60ma.
3. If RC and/or analog modes work then at least TTL inputs(sending commands to the Roboclaw S1 pin) must work. They use the same physical pin of the microprocessor. If the TTL input was no longer working then neither would RC or analog inputs on that pin(eg S1).
4. There maybe something wrong with the S2 pins output capability. Thats why I wanted you to check the S2 pin with a scope. From your reply I assume you only checked the S2 pin with a scope after adding the pullup resistor. If the resistor value is too small you will not see anything except 5v, so make sure you are using atleast a 2.2k resistor(10k would be prefered).
bsorel
Posts: 18
Joined: Sat Jan 16, 2016 11:02 am
Re: CRC Issues in Serial Packet Mode

Post by bsorel »

I was a little frustrated last night. Everything that could go wrong seemed to. For that, I apologize. There may have been some user error due to working too late last night. Today, the TTL TX is working no problems. I measured the S2 pin with and without the pull up. Without it S2 is approximately 2.5V and with pull-up about 3.3V. I have used a 10K resistor pulled up to 5V on my board. Grounds are common between the two. I have captured the pulses on the S2 pin so it looks like the RoboClaw is sending the information but my board is for whatever reason not interpreting the results properly. Running at 57600, the pulses appear to be about 20uS in length at 3.3V. I have not tried using the pull up at lower speeds so I will try that next.
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: CRC Issues in Serial Packet Mode

Post by Basicmicro Support »

At 57600 the single bit pulses should be 17.36us. So by eyeball on a scope 20us isnt unreasnable. If you can get a more accurate measure that would be good but the S1 and S2 pins are running on uart so the bitrate for receiving and sending are the same and since it is receiving its probably sending atleast close enough.

Let me know what happens with the lower baud rates(go all the way to 9600 if you have to).
bsorel
Posts: 18
Joined: Sat Jan 16, 2016 11:02 am
Re: CRC Issues in Serial Packet Mode

Post by bsorel »

I've tried running at 9600 with the 10K pull up resistor and no go on the receiving end. The pull-up still only brings it up to 3.3V which may not be enough for a 5V Pic to read although it's I/O min high is 2V. Can't seem to find any data about the UART. There is a fair amount of noise visible (1V pk-pk) when motors are running but doesn't seem to affect TX. I'm going to build a level shift circuit for the RX line. See if that does it.

Post Reply