SMC 18v25 No Response via TTL Serial

Hello Again,
I’m facing two SMC 18v25’s that do not respond to serial TTL commands. They respond just fine via USB and the SMC Control Center and the Serial Utility. I’m not getting any errors and the baud has been manually set on the boards. This entire setup is an upgrade to my RC Power Wheels Project.

Setup:
After previously losing power to a 24v23 board (SMC 24v23 No Power (Vin or USB)) I decided to wire up my old 18v25 (from a year ago) and new 18v25. I used an Arduino Mega R3 and connected a board to each UART pin. All grounds were tied together (Batteries, Arduino, 2 SMCs, and a Jrk12v12).

  • (3) 6v SLA batteries wired in series power the two SMC 18v25’s, each connected to a stock 12v Power Wheels motor
  • 1 12v SLA battery powers the Jrk12v12 and Concentric 12v Linear Actuator
  • +5v is leeched from the +5v pin on the Jrk and ran through the +V on a modified USB cable to power the Arduino. (This setup has always been used to help with motor noise on the serial lines)
  • Jrk12v12 RX connected to Arduino TX1
  • (2) SMC18v25 RX connected to Arduino TX2 and TX3 respectively

Problem:
In my original project, I used an Arduino Uno R3, 1 SMC 18v25 driving two motors in parallel (master), and 1 Jrk12v12 (slave). In my upgrade I’m using an Arduino Mega R3 and a second SMC to power the two motors independently. I also I modified my original code and only changed the Serial.begin lines to reflect the new Mega serial connections (Serial1, Serial2, and Serial3. The default Serial pins 0 and 1 were reserved for an Xbee radio.)

I was able to steer the linear actuator just fine, but the exitSafeStart commands wouldn’t work on the SMCs.

After troubleshooting the code, I only added the absolute minimum:

// Test Mega serial to Pololu boards
void setup()
{
	Serial1.begin(9600);	// Jrk12v12
	Serial2.begin(9600);	// SMC Left Motor
	Serial3.begin(9600);	// SMC Right Motor
  
	//Move steering to clear stopped state
    Serial1.write(170);
    Serial1.write(03);
    Serial1.write(0x40 + (1500 & 0x1F));
    Serial1.write((1500 >> 5) & 0x7F);
    delay(1500);
	    
	/*SMC Exit safe start Compact*/
	Serial2.write(131);	// Left motor
	Serial3.write(131);	// Right motor
}

void loop()
{

}

The error LED for the Jrk was cleared but I saw no change on the two SMCs. In Control Center, however, everything worked normally and there were no errors posted in the Serial section.

Afterwards I tested the Jrk on every Mega port and all worked except Serial3. I made a loopback test for the Mega and found that Serial3 wasn’t transmitting anything.

Lastly, I moved the code to an Uno and breadboarded each SMC one at a time. Only connecting GND and TX to the SMC GND and RX and running exit safe start in loop, I got no response from the controllers.

I’ve also observed that the original year-old SMC 18v25 draws 55.5mA when connected to Vin and the new SMC draws 11.7mA. Neither board report higher than normal temps nor feel hot to the touch.

I’m in the process of creating a new Instructable and these boards are at the center of the entire project. Any help is greatly appreciated. Thanks!

Hello.

I am sorry you are having problems with your Simple Motor Controllers. It looks like you are trying to send the “Exit Safe-Start” command to the controllers, but you are not actually sending a command to set the motor speed, so I would not expect the motors to move. What response were you expecting to get from the controllers? Could you post pictures of your setup? Could you also post your settings file from the Simple Motor Control Center?

- Jeremy

nfinitone,

I am in exactly the same boat as you (were?) with two SMC18v25 controllers that I purchased a week ago. I build robots for a living and over this past week I’ve chewed through far too many hours testing & retesting the TTL serial interfaces and I finally threw in the towel. I’d love to use these controllers - as they meet almost 100% of the spec requirements that we have for a new prototype.

Were you able to get a final resolution on the unresponsive TTL serial comms? I’m also using Arduino Uno R3’s as the microcontroller board and every Uno board we have works with various serial devices and pass functionality tests. I’ve not been able to get these Pololu motor controllers to respond to serial commands - but USB development works great on these controllers as does the SMCCenter. For instance, we tested these on one of our larger robots, but only via two separate USB ports. Btw, our goal is to daisy-chain them together - but along with inability to use the the TTL serial interface, we’ve also not been successful with daisy-chaining, which Pololu has made to be a very simple process (and the unique IDs allow us to chain and scale them for larger projects).

Bottom line, I’d prefer to start sourcing and using these controllers and, because our cases are so similar, I’m extremely interested to find out if/how you were able to resolve this issue.

Thanks,

Jeff

p.s. Quick note to Pololu, while testing the controllers via USB/Serial (using the Pololu, Compact and ASCII protocols), we noticed that the ASCII protocol specifically requires a CRLF combination to successfully exit safe-start.

In addition to the previous post I made, this afternoon I decided to use the PWM (RC) pins since I don’t want to use USB/Serial as the main interface to the controllers.

When I plug an RC receiver, or Arduino configured for generating PWM pulses, in the SMCCenter CH1 doesn’t show and updating values/pulses and when I used CH2 it continually shows the width of the pulses that I’m generating for neutral/fwd/reverse.

Two questions to Pololu support:

  1. Would all of these adverse results that I’ve experience with the controllers be the result of a blown AND gate? (no serial/TTL comms, no diasy chaining).
  2. Would it be possible to switch RC CH2 to control throttle?
  3. Is there a way to bench-test these (or run a diagnostic tool/test hardness) to quickly determine if the issues are on our end (if we damaged these controllers within minutes of receiving them) or if there are other reasons why we’ve continuously experienced failures when using interfaces other than USB/Serial?

Thanks,

Jeff

Hello, Jeff.

I am sorry you are also having problems with your Simple Motor Controller. You should not need to use “CRLF” to exit safe-start. Also, it is not possible to switch the throttle input to RC channel 2.

There is an AND gate on the board used for combining signals when daisy-chaining, however, it being damaged should not affect the RC channel 1 input. Why do you suspect the AND gate is damaged? Is there visible damage on the board?

Unfortunately, there is not a way to bench-test the SMC quickly to determine its state. We test every unit before it ships, so it was probably working at some point. Could you tell me more about your setup? What was involved with testing the TTL serial interface? Could you post your SMC settings file and the Arduino code you used to test the serial interface? Could you also post pictures of your setup and close-ups of both sides of both boards?

- Jeremy

Thanks for the reply Jeremy. We’re a bit pressed for time so I’m simply going to order two more boards and swap them out. If the replacements work out well, we’ll commit them to our . Later this evening I’ll send some code samples, configs and images for what works (USB/Serial) and what doesn’t work (TTL/Serial & RC).

The reason I was asking about the AND gate was because I saw an earlier support reference to the AND gate (in the forums) and it is also mentioned in the documentation - re: Daisy-chaining & why these controllers don’t require an external AND gate. If there’s no correlation then feel free to disregard that question.

We’ll have to wait until this evening because our robots are under heavy testing (we’re currently using the USB interface for motor control). Once testing has wrapped up for the day I’ll send the following:

  • configs (SMC settings file) for both controllers
  • Arduino code that we’re using to connect to the controllers.
  • pics of the soldering and connectivity to the boards (will be a little difficult, but for this purpose, we’ll make it happen tonight)

Btw, we routinely use Arduinos or other micro controllers to speak to assorted serial devices across various protocols, speeds, configs, voltages, etc. Since we’ve been studying the documentation and comparing vendor solutions before placing our initial order, we expected to “speak” to these controllers over serial connections (or PWM) without much delay. Hopefully this comes down to an oversight on our part.

Thanks again and I’m anxiously looking forward to solving this problem.

Jeff