We are booting the system without anything connected
Connect a can remote (data is on the transceiver output), but the emx shows nothing
We reset the emx can bus and the we get correct data.
Test 2
We are booting the system without anything connected
We do a emx can bus reset (we don’t connect any remote yet)
We get continuously bus off errors
We connect the remote and the bus of error is gone and the remote works ok
Removing the remote in both test will result in continues bus of errors again.
Another strange thing i notice. I have got a break point on the data received event. When i don’t use the while loop the event is not fired. If i use the while loop to poll is recognizes the remote through that loop, but then the data received event works again also! So as soon as i have received some data through the polling while loop the event will work also…
Edit : I need to correct myself, even if i haven’t attached the data received event and i remove a remote then we get continuous bus off errors.
use a single 120 ohm resistor at each end of your CAN bus and remove everything else.
make sure you have a proper ground between boards. People often think that because CAN is called a two wire bus that the ground is not needed but it very much is required.
Buy a CAN interface for your PC that shows you the CAN data on the bus as well as the error counts. This is critical for any CAN project and should be the first piece of equipment you buy.
My guess is that you have a physical layer issue and not a software one
Good luck,
Steve
thank you for your reply, but most of the thing you mention we already did (see my previous posts). As for the physical issue, we use CAN a lot in other projects, so we have got quite some experience with it. The way it is designed now works in other devices. We have got a pc can tester and a yokogama scope that can decode and visualize the CAN data. Both show the data correctly on the the bus. The scope is measuring the data directly on the pins of the emx module. And there are no error in the data AND the micro framework is able to read the data. Just not in the way GHI intended it to do. We read the data now in a continues while loop. That works for now. But it is not supposed to work like that. The issue for us is that we can’t use the Datareceived event because it somehow isn’t stable, so we switched back to the loop because the product is already used on multiple locations now.
But that doesn’t mean that i wouldn’t like to use that datareceived event in the future
sorry, I was not paying enough attention. I have just started with the spider board and the CAN routines and it appears to be working properly for me so I guess I assumed the physical layer.
Although not related to your issue, I did notice the transmit routine only sends three messages (the internal transmit buffer size) and drops the rest if you use the PostMessages command as is. If you send singles in a loop there is enough delay to allow them to all go out so there is some status flag checking that needs to be done in that regard, but, like I said, not related to your issue I assume.
If it were me I would use the Register command to create a CAN controller memory dump and use it to check the differences between working and not working.
Has there been any movement on this issue? I seem to be having the same problem. When I switched from using the events to just a loop on its own thread as suggested things seem to work fine. Interestingly I also suspect the underlying hardware is receiving messages fine as eventually I get the CAN.ErrorReceivedEvent firing with CAN.Error.RXOver when DataReceivedEvent is not firing.
This is the code that makes it work for me, only replacing the event subscriber (commented out) with the thread gets it to work consistantly:
//sign up for can events
//Bus.DataReceivedEvent += new CANDataReceivedEventHandler(Bus_DataReceivedEvent);
new Thread(new ThreadStart(() =>
{
while (true)
{
Bus_DataReceivedEvent(Bus, null);
Thread.Sleep(0);
}
})).Start();
