This code works for a while, then it loses its mind and delay no longer delays.
There are 2 arduinos involved, This code above is for the CANBUS sender and the CANBUS reciever is the one with the servo connected.
The receiver has a 9VDC external power supply that is powering the motor and both Arduinos are connected to the same USB hub, As of this moment, it's been running about 13 minutes without issue but it won't be too long before it start flying.
I've got Serial.print statements on both ends, the sender and receiver and when it starts going crazy, it is sending 1000s of messages a minute.
I don't think it is the short CANBUS I have since what I'm sending and what's being receive is printing out correctly.
i tested the code you posted and got the following output.
seems ok
0 F
2249 N
4500 R
6750 N
9000 F
11250 N
13501 R
15751 N
18001 F
20251 N
22502 R
24752 N
27002 F
29252 N
31503 R
33753 N
36003 F
38253 N
40504 R
42754 N
45004 F
47254 N
49505 R
51755 N
54005 F
56255 N
58506 R
60756 N
63006 F
65257 N
67507 R
69757 N
72007 F
74258 N
76508 R
78758 N
81008 F
83259 N
85509 R
87759 N
90009 F
92260 N
94510 R
96760 N
99010 F
101261 N
103511 R
105761 N
108011 F
110262 N
112513 R
114762 N
117013 F
119263 N
I pushed the reset button on the sender and it's working again. Seems to be related to delay() but not sure why. Seems like delay would be ROCK solid. But it appears this is NOT the case. Going to go write my own delay routing using millis() and see what happens.
It's certainly more solid than the code we can not see. Complete code, or minimal example code which compiles and demonstrates the problem is what people who want to help you need to see.
Here is all the code BUT the problem isn't in the SW, the problem is in the Arduino board. I grabbed some cheap boards (I'm in Mexico so availability is limited). I have 2 of these cheap boards, sender and receiver and the receiver is working without a problem. The sender however was not. So, I took the 3rd Arduino (elegoo UNO R3) and the code that was failing (even with my own delay routine) is now working as expected. Looks like I need to order some better Arduinos!
I brought the delay down from 2250 to 250 and it has already run more than 2x as long as the failure case.
Wish I had some idea how to troubleshoot this quicker, these kinds of problems have cost too much time for this simple project!
I initially wrote the loop portion of the sender because of trouble controlling the motors. I added the delay() to have a better chance of figuring out what was going on, just to have delay freak out on me. I wrote millis32() to debug delay() and since it only needed to get past the 70 minutes, it's not broken, just not as robust as it needs to be.
In the end, replacing that one UNO with the Elegoo UNO R3 fixed the problem without changing the code. It did however manage to move the problem to the other UNO board (same maker) that was controlling the motors, where as before it was in the sending vs the rcving side of things. I've order 3 more of the Elegoo boards so I can continue the protoyping which doesn't use delay() at all and does have a finite state machine but that is a completely different beast and not something I would want in the picture while trying to solve problems like this.
Also during all of this troubleshooting there was a switch statement that didn't work for one of the cases and I had to change that to an if/else if/else. So I'm betting they used defective Atmega (or cloned) parts since they ground/washed the numbers off the chips and there was nothing wrong with the code, just the processors.
You seem to be taking a scatter gun approach to this project. If you want to get help then again post this code. We can't debug what we can't see.
You were either mistaken or you believe in magic it is not possible for this to happen.
This sounds like throwing good money after bad. We generally find here that the Elegoo boards are very poor and cause all sorts of problems.
The way you have to work here in order to solve your problem:-
You post code.
Someone makes a suggestion about changing it.
You try the suggestion.
You report back if it works or not, and exactly what it does or doesn't do.
And you post your code again to show the code with the suggested changes, so we can check if you have done the changes correctly.
It is vital that you do this. Yes it is long winded but it is the only way to get something to work when you are trying to get code to work.
So far in this thread we have not touched on your hardware only software. It is entirely possible that there is something wrong about the way you have things wired up, and it is this that is giving you the problem. So can you please post a schematic of your hardware along with a photograph or two showing your circuit.