In addition to the other replies fielded here, I thought I would try to help. I've used CAN bus a lot, even professionally. I'm no programmer (I'm an electrical engineer), so take the bit arithmetic with a grain of salt.
User gilshultz is correct when he said that when you measure across CAN HI and CAN LO you need 60 Ohms. Either you need to add a jumper between the two jumper pins on the CAN board, or if you've already done that, find where on the motor you need to do that. If you have two CAN converter boards, I would start by getting them to talk to each other (either on separate processors or on the same one- you can even use the same SPI bus as the converters have built in buffers. This will give you a good idea of what you need to do (especially on the hardware level) to get CAN working. Remember that each CAN converter board needs a jumper (one on either side of the CAN bus)! Once CAN is working, it's great, but getting it working I've found is a pain in the butt.
After you have communication between two boards down, you need to look at coding. I'm not going to lie, you chose a very hard motor to start off with. The CAN protocol for it is hard and you're probably going to fail a lot, but that's okay! That's how you learn.
First, I assume you're using Cory J. Fowler's CAN library (it's a very good library). You can download it on GitHub if you don't already have it. The datasheet doesn't explicitly say what the baud rate is, but I'd guess 1Mbps since on page 22 that's the first example they give. Don't worry about the TQ (time quanta) as the library takes care of that for you. Since I saw you have a 16MHz crystal, your initialization code would look like this:
if(CAN.begin(MCP_ANY, CAN_1000KBPS, MCP_16MHZ) == CAN_OK)
Serial.println("CAN bus initialized");
else
Serial.println("CAN bus initialization failed");
CAN.setMode(MCP_NORMAL);
I should add that I took this code from a project I'm working on with an ESP32S3, not an Arduino, so the Arduino format might be slightly different, but it should be fundamentally the same.
Now, for the hard stuff. The motor uses extended CAN ID's, but it uses the data link layer to split that extended ID into its two separate parts. The normal CAN ID is 11 bits, and the extended is 29 bits. The extended CAN ID just adds another section in the ID part of the CAN message that is 18 bits long.
Typically, you wouldn't care about this, as on the application layer you'd have 29 bits for your ID. However, with this motor, they decided to split it up. The Standard ID (SID) is the ID of the motor. I'd guess it's probably 5 by default since that's what the example uses below where I took this screenshot. The Extended ID (EID) is the Control Word that the motor uses to determine what type of command you're sending it (this is specific to this motor, not all CAN bus communication is this complicated, I promise).
I'll break down their example of sending instructions here in a second. But first, if you have a Windows computer, if you open the calculator app that comes with Windows, and click on the hamburger menu in the upper left, you can change it to a programmer calculator and it'll help you with the bit arithmetic.
This is the example on page 23. The Producer ID is the ID of your Arduino (doesn't really apply here since your Arduino will read all the messages and in normal CAN you can't say who sent the message). But the Consumer ID is the ID of the motor. First, to calculate the SID, they do some bit arithmetic. Putting it in that calculator, 5<<1 is equal to 1010 in binary. ANDing that with 0x003F gets you 1010 (it's there in case your ID is over 6 bits long). That is then OR'd with0x100, which gets you 1 0000 1010 in binary, which is 10A in hexadecimal.
For the EID, 5 left bit shifted by 1 is 1010 in binary. ANDing that with 0x00C0 gets you 0 in binary (not entirely sure why they do this, someone smarter than me could probably explain). Anyways, 0<<8 is also 0. That OR'd with the Control Word (0x95 - given in the example), is 0x95 in hex.
Now, remember how I said that the extended ID just adds 18 extra bits to the standard ID? Well, the next part, where they calculate the CAN ID is doing just that- they shift the standard ID 18 bits, and OR the extended ID in (so that you end up with a 29 bit ID), giving you 0x4280095.
The DLC stands for Data Length Code, or how long the data you're sending is (in bytes). Since they're only sending one byte of data, that's a 1. The Data0 variable is the data you actually want to send.
In code, this is how I would do it (no guarantees this will work, I'm tired and haven't tested this).
#DEFINE MOTOR_CAN_ID 5 //put this at the top of your code, right below the libraries. Change the value to whatever you figure out the CAN ID is.
uint8_t send_can_message(uint16_t CW, uint8_t DLC) {
uint16_t SID = ((MOTOR_CAN_ID << 1) & 0x003F) | 0x0100;
uint32_t EID = (((MOTOR_CAN_ID << 1) & 0x00C0) << 8) | CW;
uint32_t CAN_ID = SID << 18 | EID;
byte sendStat = CAN.sendMsgBuf(CAN_ID, true, DLC, can_data); //sendMsgBuf(CAN ID, extended true/false, data length, can data array). CAN data array can be a single number (like in the case of the example) or multiple numbers in an array.
if(sendStat == CAN_OK)
return 1;
else
return 0;
}
You'd have to figure out what control word to send, and how you want to get the data to that function (might I suggest passing by reference or a global array?). Anyways, this should definitely give you a kick start in the right direction. Feel free to ask me any more questions! Sorry for the long post. But with your newfound knowledge, hopefully you can decipher the datasheet better!
