MindSensors SD540C Issues

Let me introduce myself, I am the Programming Mentor for FRC Team 2903. One of our other mentors saw the MindSensor SD540C motor controllers and thought they would be an improvement over the Talon SRX CAN motor controllers we used last year, in regards to wiring and electronics layout.

I can agree with him on that portion. The rest of it, well read on.

The configuration tool downloaded never finds any of the motor controllers on our can bus and it crashes when we attempt to refresh. I discovered a command line utility located on the roboRIO in /usr/local/bin called clcp_sd540c, but soon discovered that, while it could see the controllers on the CAN bus, I didn’t have enough information on how to program them. I looked around for documentation, but without finding any, I used a disassembler and reverse engineered the program to figure out the command line format:

clcp_sd540c scan
clcp_sd540c id <id> <new_id>

are the most important commands, although I also used the name command to rename the devices. Now that id’s of the controllers had been modified so that I could have all 8 of them on the CAN bus, I was able to load some simple teleop code to drive with a joystick.

This is where the fun begins. The Talon SRX CAN motor controllers had very good support in the WPI library and could hook into the robot drive subsystem and we could simply use ArcadeDrive or TankDrive after creating the robotdrive object with the 4 motor controllers. Even after updating last year’s robot with the current software, the Talons continued to work wonderfully.

The SD540C controllers, not so much. We had to configure them from the command line, and because the provided class has not been well integrated with WPILIB, we had create our own arcade and tank drive methods in order to even drive the robot. During our testing of the implemented drive methods, we ran into several problems with the controllers:

  1. The voltage ramp up is not 0 by default as the documentation says. I am not sure what it was, but it was not 0. And even after setting it to 0, the controllers do not immediately apply the power to the motors. Setting the voltage ramp-up to 0 improved the situation from the default setting though. We did not measure the voltage output, and, if needed we can provide that data.

  2. Setting the Stop mode to brake rather than the default coast, does not always stop the motors immediately, sometimes they continue to run for a second or two.

  3. The motors whine furiously like they are not getting enough voltage. When they are at full power it’s fine. I can provide a video which I believe has sound if desired. The electronics mentor seemed to think it was something to do with possibly underpowering the motors, but he didn’t do any voltage testing. I can provide that if needed.

  4. Frequently when starting, the motors run at a very high rate for a second or two, or until we press the drive control joystick. We haven’t debugged that one too far yet.

  5. SetInverse(true), does not reverse the direction of the motor controller. I noticed that MindSensors provided a Firmware update to fix that for the SD540 and SD540B controllers, I wonder if a firmware update is available for the SD540C and if it is available for download for manual installation with the command line utility described above.

Needless to say, we are quite disappointed at this point in the season, with only 2 weeks left in build season. We are already preparing to move back to the Talons as we know they suited our needs and will figure out another way to clean up their wiring.

If anyone has any experience with these controllers and can provide us with some possible investigation paths, we’ll likely start the move to the Talons on Friday. The whining we can live with, but the ramp up speed, when we asked for 0 ramp-up is the biggest issue. The second one is the not stopping when power is removed from the controllers. Having SetInverse() not working, is an annoyance, but we work around it by sending the negative motor power to the controllers on that side of the robot.

I realize that we are missing some voltage information, but that can be easily gotten.

Thanks for reading!

What’s so bad about wiring the Talons?

Thank you for your reply.

I didn’t say the Talons were hard to wire, just that the SD540C controllers were more conducive to cleaner wire management. :slight_smile: Since we are likely moving back to the Talons, the way we managed the wiring for the SD540C will also work quite well for the Talons.

What made them better for wire management? I’m thinking I might be more interested in CAN if wire management got even easier.

I assume it’s because nothing’s permanently wired to the SD540 motor controllers. You can feel free to make CAN and power wires as short as you want without fear of having to blow $90 on a new motor controller.

Also, to answer OP’s question, this may just be the reality of the motor controllers. SD540(B) controllers were found not to be very reliable, and were outclassed by the SPARK in every way. Based on other people’s teardowns of the original SD540, I assume this motor controller is using very cheap construction methods and components, leading to these failures.

Exactly.

Thank you for this information, this is the first real information we’ve received. Do you have links to these teardowns that I can share with the electronics team? (I will also search, but if you have them at hand…)

Here it is: Amazon.com

These things could certainly have improved though.

Based on our experience, I am not so sure about the improvement. These are brand new this year, so, the kinks may not have been fully worked out yet.

We had the same issue with the configuration tool not finding any of the mind sensors (nor did they appear in the standard NI web console). We were able to locate and run

clcp_sd540c scan

and found the controllers. Unfortunately

clcp_sd540c id

did not work to change the ID and returned an unrecognized command error.

You guys seem to have gotten a bit further with the controllers. Any advice on what to do from here would be greatly appreciated.

So, here is what we found in our testing. First we connected each SD540C directly to the roborio without any other CAN device on the bus. We were able to then use clcp_sd540c id to set a new id on each SD540C. We also took the time to rename each one with clcp_sd540c name “new_name”

Once we did this with each one, we then started building the CAN bus back up, by first connecting the PWM into the bus, followed by each SD540C, one at a time, verifying with clcp_sd540c scan that we could see each of the controllers as we add them.

We were able get all 8 controllers on the CAN bus with the scan command finding them all.

Then…

then we attached the PDP. As soon as we attached the PDP, the scan errors began again, nor could we display controller id’s using the id command. We then removed the PDP, and things started working again. We then added the PDP back with the same errors occurring. We check the connector on the PDP, and the same problems occurred no matter which CAN connector on the PDP we used. It also didn’t matter that the PDP was terminated or not terminated.

I spoke with support at Mind Sensors, and they were able to duplicate my crashes with the configuration app, and I assume that they have since released a new version, but we haven’t checked it. They also had some other suggestions – to verify that there aren’t any other conflicting device ids. We haven’t done that yet.

Here is their response

We tried many different configurations with 10 SD540Cs on the network. Even with this many and 3 CANSplitters, the GUI and clcp commands succeeded when each device had a unique ID. This also worked with or without many resisters at various points on the networks. However, once we introduced one repeated ID in any configuration we experienced erratic behavior.

As you have been savvy enough to access the clcp_sd540c command-line tool yourselves, you can use the blink command to help debug this. With two SD540Cs set to ID 12 (and 8 others with unique IDs), calling clcp_sd540c 12 blink will cause both devices with this ID to blink. This method will work as long as no other commands are called on the duplicate ID. If any other commands have been called, a power-cycle is required to clear the collision.

Thank you for your determination in using out product on your robot. We have added additional detailed error messages to the mindsensors configuration tool and will add a new panel to help resolve CAN ID conflicts.

At this point, so late in the build season, our electronics team replaced the SD540Cs with the TALON SRX controllers we used last year. They worked as soon as we attached them and were all listed in the WEB UI.

A note on the WEB UI, Mind Sensors devices will not appear in that list. And it doesn’t sound like they have any plans to change that. There is a file on the roborio that lists the can devices and I intend on investigating that to see if maybe we can get them to show up.

Feel free to reach out to me with a private message and I will give you my contact at MindSensors for their assistance.

the actual command is, for example,

clcp_sd540c 3 id 30

would change the controller with device id 3 to 30. You can verify that by

clcp_sd540c 30 name

which will either display not on network or the current device name.

John

Hello John,

Thank you very much for the detailed and fast reply. We did find the command to change the IDs but are still getting sporadic responses with the scan command: http://imgur.com/GaCBCOs.

The issues you guys were having sound pretty bad and it doesn’t seem like a new version of the configuration tool exists. Tonight our team leadership will discuss potential solutions but it seems that we too will be switching to Talons from a previous robot.

Thanks a ton for the help. :slight_smile:

That image looks mighty familiar!

Have you tried disconnecting the PDP from the CAN bus. I realize that it has to be connected for competition, but for getting your device ids changed, it might help.

Have you tried to wire the bus:

roborio->pwm(if used)->pdp->sd540c’s

ours was

roborio->pwm->sd540c(1-8)->pdp

We didn’t think to try reversing the sd540c controllers and the pdp.

I just received an update from MindSensors:

Please update the Library software for Java/C++ and firmware of your SD540C.

Things to do:

  1. Update the Java/C++ libraries
    download the file: http://www.mindsensors.com/largefiles/FIRST/mindsensors.zip
    and follow these instructions to install library:

Installing the Library:
Check your home user directory (C:/Users/username) and look for a wpilib folder. The WPILib Eclipse plugins should automatically download and create this folder when you launch Eclipse.

Inside the wpilib folder you should see a folder named “user”. Download the mindsensors FRC library, unzip it, and copy the user folder here to the corresponding folder you found earlier. Your user folder should contain a cpp and java folder. (replace old files with new ones).
Further details here: How to Use SD540C and CANLight with RoboRIO

  1. Update the mindsensors Configuration Tool
    Please download latest version of tool from following url:
    http://www.mindsensors.com/largefiles/FIRST/mindsensorsConfigurationTool.zip
    unzip it in a known location,
    Disconnect the PDP board from CAN network, and
    Run the tool.

How to use this tool: Using the mindsensors Configuration Tool

  1. Update the SD540C Device firmware
    latest version is 1.7 - file name: B_SD540C_V1p7.hex
    Use the ‘Firmware update’ option from the config tool.
    (Ensure to Disconnect the PDP board from CAN network before running this tool.)
    Run the Firmware update for all your SD540C’s.

That’s all.

Interesting that they spelled out:

Disconnect the PDP board from CAN network

I will have to try this after we bag and tag next week.

And one more update from MindSensors.com

We found a collision on the CAN network with PDP and applied a fix.
we will be releasing a software and firmware update today,
that will fix the issues you are seeing.

We found a collision on the CAN network with PDP and applied a fix.
we will be releasing a software and firmware update today,
that will fix the issues you are seeing.

We will be on the look out for this update. Thanks for letting us know.

Update from MindSensors Support:

Please update the Library software for Java/C++ and firmware of your SD540C.

new versions available as follows:
firmware-version: 1.8
library-version: 1.11

Things to do:

  1. Update the Java/C++ libraries
    download the file: http://www.mindsensors.com/largefiles/FIRST/mindsensors.zip
    and follow these instructions to install library:

Installing the Library:
Check your home user directory (C:/Users/username) and look for a wpilib folder. The WPILib Eclipse plugins should automatically download and create this folder when you launch Eclipse.

Inside the wpilib folder you should see a folder named “user”. Download the mindsensors FRC library, unzip it, and copy the user folder here to the corresponding folder you found earlier. Your user folder should contain a cpp and java folder. (replace old files with new ones).
Further details here: How to Use SD540C and CANLight with RoboRIO

  1. Update the mindsensors Configuration Tool
    Please download latest version of tool from following url:
    http://www.mindsensors.com/largefiles/FIRST/mindsensorsConfigurationTool.zip
    unzip it in a known location,
    Disconnect the PDP board from CAN network, and
    Run the tool.

How to use this tool: Using the mindsensors Configuration Tool

  1. Update the SD540C Device firmware
    current version is 1.8 - file name: B_SD540C_V1p8.hex
    Use the ‘Firmware update’ option from the config tool.
    (Ensure to Disconnect the PDP board from CAN network before running this tool.)
    Run the Firmware update for all your SD540C’s.

Good luck!