CAN tutorial


Since this was team 348’s first year doing CAN, we decided to document it. (in part because I’m a senior and won’t be around all the time next year) I Right now, it’s currently a draft, but I figured by the time I’m happy with it, it will be too late. Right now, it’s just the basics. I plan on adding examples of taking advantage of closed loop control and other features of jaguars.

Hopefully you find it helpful! And please leave any suggestions to clarify or improve it.


I also wrote I a document on CAN, but it was from a hardware point of view. It is mostly on the wiring aspect of CAN.

care to compare notes?

edit- I read it. your method for making the serial adapter is different. my methods were using a rj-12 to db9 adpter and reusing old db9 serial cables. not that your method is wrong, it is just different.

good luck on the document…

Thanks, your’s looks really good too! Now, I feel like I should add better pictures.

Thanks for the information on CAN. I had no idea what CAN was and looked all through the documentation without really getting a handle on the very basics.

I might suggest that you start your paper with a sentence or two on what CAN is and what it stands for. Maybe a link here:

I think my team is going to stick with PWM this season. I’ve already started wiring that way and I have some familiarity with it. Maybe after the season we can reconfigure for CAN to get some experience with the added functionality.

Your work will certainly help with that. Thanks!

Thanks for the feedback. I added another paragraph in the “overview of CAN” section.

I’ve also started an example of using the encoders to read speed through the CAN network. I have to verify wiring colors monday, but other than that, it should be good to go.

I’m just getting into using CAN and I had some recent revelations which may end up in a white paper somewhere, but I just wanted to post here in case anyone else can benefit/comment.

Using CAN bus in LabVIEW

Our 2011 Robot has a hybrid Swerve drive (6 wheel frame, two center wheels are swerve, 4 outer wheels are omni’s), and a manipulator arm with two motorized joints.

This is my first attempt to use CAN with our robot, and I did it for several reasons.

  1. We wanted to have limit switches for the manipulator motions, and CAN provides a software-independent method to protect the motion from end collisions.

  2. We wanted to use pots on the rotating joints and have a master/slave controller for the arm, so CAN would let us use the built-in closed loop position control provided by the Jaguar motor controllers.

  3. We’ve not had great success with closed loop drive controls to date, so if we try it again it would ne nice for it to be built in to the controllers.

The available tutorials for hooking up the Serial-CAN bus are really good. So we got the actual bus up pretty quickly using a home-made cable and the CAN utility provide by TI. Here we learned about the various control modes and what to expect when reading and writing control data.

However, once we started actually programming (in LabVIEW) things got fuzzier. Larry’s tutorial here: was a big help, but Larry was only using it for drive control.

Where I started running into problems was putting the JAG’s into Position Control using a POT.

I had verified this action using the TI Jag tool, but the LabVIEW code wasn’t acting the same.


  1. The Jag tool did position control based on pot voltage, and provided feedback in terms of voltage, so, I was expecting the same from LabVIEW. But the LabVIEW VI’s seemed to use something else. Through much doc searching and experimentation, I discovered that LV is converting position command and position feedback values to the 0.0 to 1.0 range. This makes sense in hindsight, but since pot vales seemed to work, but not properly, it was cause for several close collisions. The inference is that the “real world” units for “position” are “Rotations”, and that a pot measures 1 complete rotation. We all know that’s not true, but it’s probably close enough.

  2. The motor enable and disable VIs don’t seem to work the way I expect them to… We wanted to be able to turn off the control of the arm if no motion was required. The code had an enable/disable switch that would issues Enable/Disable commands. We would repeatedly issue a disable command to an arm motor and it would still continue to run in a weird slow-motion way. Since we are setting the control mode to Position Control (POT) and the is sending a “Volt Disable” message to the Jag, I’m wondering if it is truly disabling the motor, since there is ALSO a more appropriate “Position Disable” command.

Anyway… more info at it comes available.



Feel free to try using the “position disable” command, and see if it makes a difference. I was under the impression all the “disable” commands function identically. The main purpose of the “enable” and “disable” is to prevent the Jaguar from making wild movements while you are configuring.

In my experience, the BDC-COMM and the LabVIEW implementation treat the position the same; in rotations. I’ve tested Position Mode with encoders in both LabVIEW and the BDC-COMM, but I’ve only tested with potentiometers in BDC-COMM.

If you want to control using voltage, you can set your “pot turns” configuration to 3. The Jaguar uses a 3v regulator for the potentiometer.

Now that I’ve got things working, I’ll try the enable/disable again.
Regardless of the original intent for "enable/disable? it seemed the most logical way for me to “stop” the motor from following the slave controller. Changing the mode back to voltage and then setting voltage to zero seemed long winded.

Now that I think back… it’s possible that the BDC-COMM WAS running 0-1, but the on-screen text just made me think it was volts… perceptions…

Setting pot turns to 3 is a clever trick. I wasn’t sure how that value effected the controller. I thought that the gear reduction should also come into play there… but not really…

That parameter could have a paragraph of explanation somewhere so it’s more obvious how it effects things… The Rotations connection just wasn’t obvious to me & I’ve been around the block a few times (or is it arround the bend?)


Thanks for the great tutorial! Our team has tried for 2 years to get it working, but with the lack of any good documentation, we were unsuccessful. We’ve been doing only part of what has been said in these tutorials. The extra information must be the missing link. I do have one small question. When we first started using CAN, the person in charge of our electronics said that a 120 ohm resistor worked just as well as the 100 ohm resistor, and bought A LOT of 120 ohm resistors, and NO 100 ohm resistors. So since we’re stuck with these, I was wondering if they would still work, or if we should just go buy some 100 ohm resistors. Again, thanks for the great info!

Yes, the 120 ohm resistors work fine.
Truth be told, the CAN bus will actually operate with NO terminating resistor, but it will be less reliable.

We tried out CAN this year via a Serial to CAN cable to a Black Jag. We had a 6 motor drive train and one motor for the elevator (2 black jags, 5 grey). Our CAN code worked beautifully with the drive train; we had not yet wired up the Jag for the elevator. When we did and started running elevator at the same time, we got lots of lag issues, with safety timeouts and CAN bus errors all over the place, resulting in system watchdogs beyond belief. We had it later confirmed (not sure where) that the Serial CAN bus on the cRio can only handle 6 jags efficiently, so we had it switched out for PWM. Unfortunately, due to <R49> and <R58> we couldn’t have the limit switches on the elevator jag, which was a big sad face for the programmers.

Have other people had issues with more than 6 jags on the Serial bus? Is the 2CAN able to handle it? (I’ve heard it’s bus speed, anyway, is much much faster, at about 800MHz?)

We also had one Jag (grey) that gave nothing but a Vbus fault in BDC-COMM and didn’t accept any image. It worked flawlessly with PWM, so it was probably a firmware issue.

very odd… my team made 9 jaguars on Serial Can work fine. we had those erros at one point but it was a code issue; we used labview and the programmer had put everything in and never used periodic tasks, big mistake. moving it all the control loops (non-robot drive) to invidual while loops in periodic tasks solved the timeout issues.

the odd jaguar might have metal shavings inside… open it up and make sure its clean. I was able to fix 5 ones in the junk box that way… remove the shavings and they come back to life.

If I’m reading this correctly, the firmware must be updated prior to assigning a number? My team is currently experimenting with CAN on one of our off-season robots, and we’ve gotten as far as getting the LED on the black jaguar to be a solid yellow (don’t ask why we’ve waited this long to even get this far!) while connected through 6P6C-DB9 cable to a laptop, and BDC-COMM is saying that it is connected, however, when we attempt to assign a number to the Jaguar (so far, just the black jaguar, and it does have the proper terminator) it gives us the countdown, we press the user button in time, it flashes yellow once, and goes back to solid yellow (meaning that it’s being assigned to ID 1, when we’re trying to do ID 2). So, is our issue that we need to update firmware first, or is it something else?:confused:

Go ahead and update the firmware. You will have to do it eventually anyway. I expect the reboot will reset the address to 1 regardless of the current address. I have not actually tried with any ID but 1 this so I could be wrong.

The procedure is to put the new address in the box. Click the assign button. you see the box counting down & the jag light blinking. Press the user button within the 5 seconds. Sorry for being redundant. Should work. Look at the top of the BCD Comm box for the current board ID NOT the assign box.

You can find directions for BCD-COMM here

Thanks for the speedy response!

The jag light was remaining solid after we pressed the assign button.

Also, although the jag’s LED was solid yellow, there were no board IDs listed in BDC Comm.

Also, we had to force the computer to set the jaguar to Com port 1, otherwise, BDC Comm wouldn’t even acknowledge that there was another Com port present.

The black jag was the only one on the network at the time, and attempting to daisy chain through to a tan jag yielded no communications on the tan jag.

The solid light means the jag has a signal which infers communication. Seems like I was getting this problem earlier, but I didn’t actually have communication. Turned out I had a pin wrong in my RS232 adapter cable.

If the led remains solid after you press the assign button, it is not getting the command for some reason.

Can you down load the Version 92 firmware? Is the temp updating? That would eliminate some possibilities.

Some computer comm questions. Look in system settings is your RS232 port really comm 1? What kind of RS232 port are you using? Do you have another program trying to use the com port. RSlinxs (Allen Bradley & the old Palm software was real bad about that. Do you have a IR port.

I may also suggest reading my whitepaper on serial CAN… the later firmware sections in particular.

there is a link in my signature

Thank you for yet another speedy response!

I can re-check the pins on the RS232 to CAN cable (the next time I’ll be able to do so is on Thursday), this is the only thing I can think of that would be the issue, because it’s not even updating the temperature.

We have not updated the firmware from factory default, I was afraid that the issue was with sporadic communications, not no communications, and that might risk bricking the jag.

Under the system settings, it used to be that a printer port on the laptop (a very old laptop) was assigned to COM1, we disabled that in the system settings, and forced the com port on the jag to 1, under the software of the usb to serial interface that we use.

When we select “connect” in BDC comm, the status LED on the adapter blinks (it’s active), and the software shows it as a “busy” state, all leading me to think that we do have comms, but it must be with wiring. I will also try with another black jag, and see if it’s the jag that’s the issue, I’ll keep you posted

Sounds like what I had with a bad cable. The BCD-Comm program was showing connected but that just seems to mean it is talking the the serial port. I apparently had transmission to the jag because the LED on the jag was solid. I fixed the pins & suddenly everything works.

I believe I have figured out the issue here, and it is totally 100% human error if so. I believe that the issue arose from the fact that I forgot that DB9 female is reverse on its pin numbering from DB9 male… This would explain why it was a solid yellow LED (jag was receiving comms from the computer, because pin 3 is the same on both male and female, and is Tx), but was not appearing on BDC-comm (Rx was not wired in at all, rather, it was the DTR pin) it might also explain why it could not change its number, it must require some sort of handshaking to do so. Again, this is theory, and will not be tested until Thursday, but I’m willing to make a solid bet that that’s the issue here. I’m sorry that I sort of wasted your time.