Why does CAN BUS data update on Serial Monitor but not the Network?

Hi, I'm looking for for some advice please. I've set up a CAN BUS using Arduino Uno and MCP2515 can bus driver. I simply want to send LED status on /off through the network via button switch.

When I switch the led on and off via the switch, the serial monitor is showing the correct ledState but the oscilloscope is showing no change in the data field in the message being transmitted over the network.

When I print the serial monitor the canMsg data I can also see the change in the LedState here but not on the scope.

Appreciate any pointers form anybody who might know why the serial monitor is showing the correct ledSatus but the MCP2515 doesn't?

Thanks

without seeing your code we can only guess....

my guess that you are your set the MCP2515 to LOOPBACK mode in your code but who knows....

HI Karma,

I've included the code below. I'm using the interrupt pin 3 to debounce the switch. Pin 2 is being used to MCP2515 int.

included code:#include <can.h>
#include <mcp2515.h>
#include <CANMessage.h>
#include <SPI.h>

// constants won't change. They're used here to set pin numbers:
const int buttonPin = 3; // the number of the pushbutton pin
const int ledPin = 9; // the number of the LED pin

// Variables will change:
int ledState = HIGH; // the current state of the output pin
int buttonState; // the current reading from the input pin
int lastButtonState = LOW; // the previous reading from the input pin

struct can_frame canMsg;
MCP2515 mcp2515(10);

// the following variables are unsigned longs because the time, measured in
// milliseconds, will quickly become a bigger number than can be stored in an int.
unsigned long lastDebounceTime = 0; // the last time the output pin was toggled
unsigned long debounceDelay = 50; // the debounce time; increase if the output flickers

void setup() {
pinMode(buttonPin, INPUT);
pinMode(ledPin, OUTPUT);

while (!Serial);
Serial.begin(9600);

SPI.begin(); //Begins SPI communication

mcp2515.reset();
mcp2515.setBitrate(CAN_500KBPS,MCP_8MHZ); //Sets CAN at speed 500KBPS and Clock 8MHz
mcp2515.setNormalMode();

// set initial LED state
digitalWrite(ledPin, ledState);
}

void loop() {
// read the state of the switch into a local variable:
int reading = digitalRead(buttonPin);

// check to see if you just pressed the button
// (i.e. the input went from LOW to HIGH), and you've waited long enough
// since the last press to ignore any noise:

// If the switch changed, due to noise or pressing:
if (reading != lastButtonState) {
// reset the debouncing timer
lastDebounceTime = millis();
}

if ((millis() - lastDebounceTime) > debounceDelay) {
// whatever the reading is at, it's been there for longer than the debounce
// delay, so take it as the actual current state:

// if the button state has changed:
if (reading != buttonState) {
buttonState = reading;

// only toggle the LED if the new button state is HIGH
if (buttonState == HIGH) {
ledState = !ledState;
// set the LED:

}
}
}
lastButtonState = reading;
digitalWrite(ledPin, ledState);

//int t = digitalRead (ledPin);

canMsg.can_id = 0x038; //CAN id as 0x036
canMsg.can_dlc = 8; //CAN data length as 8
canMsg.data[0] = 0x00; //
canMsg.data[1] = 0x00; //]
canMsg.data[2] = 0x00;
canMsg.data[3] = 0x00;
canMsg.data[4] = 0x00;
canMsg.data[5] = 0x00;
canMsg.data[6] = 0x00;
canMsg.data[7] = ledState;

mcp2515.sendMessage(&canMsg); //Sends the CAN message

Serial.print ("ledState:");
Serial.print (ledState);
Serial.print ("buttonState:");
Serial.print (buttonState);
Serial.print ("lastDebounceTime:");
Serial.print (lastDebounceTime);
Serial.print ("lastButtonState:");
Serial.print (lastButtonState);
Serial.print ("canMsg:");
Serial.print (canMsg.data[7]);
}

Do you have another MCP2515 at the receiving end that has been set to the same bus speed?
If not then the sender will not receive any ACKS and therefore it will repeatedly send the same message again and again.

Hi Karma,

Thank you - i hadn't even given ACKS a thought. I had only set one node up to test, so presumably without receiver node to ACK the message this is likely to cause the same issue - right?

Cheers