A while ago I developed a tool to make CAN testing easier. If you're interested you can get it from here: https://gist.github.com/nbuchwitz/eee26 ... fb24092573
The usage is pretty simple:
1. Copy the program to both devices
2. Start the script on one device in controller mode: ./can-test.py host
3. Start the script on the other device in dut (device under test) mode: ./can-test.py dut
You can change optional settings like bitrate, termination and device names via parameters (use -h to see all options).
Code Example for ConCAN?
Thank you.
I can see that uses the equivalent of system() calls but from within python. I know that the command line works and am trying to get the standard C libraries to work.
I have finally succeed! https://gist.github.com/Hansen-KK
Cross compiling in Visual Studio logged in to RevPis as root.
I can see that uses the equivalent of system() calls but from within python. I know that the command line works and am trying to get the standard C libraries to work.
I have finally succeed! https://gist.github.com/Hansen-KK
Cross compiling in Visual Studio logged in to RevPis as root.
Ok I'm having trouble seeing these CAN messages on our CANKing monitor.
When the two RevPi's are talking to each other, they can see the messages but the CANKing can't.
When I put the CANKing on our test rig, it can see CAN messages, but the RevPis can't.
A quick look with an oscilloscope showed that the polarities were reversed on the RevPis.
The pinout for the Con CAN is shown as: but in order to get this to work, I have had to reverse CAN_H and CAN_L
When the two RevPi's are talking to each other, they can see the messages but the CANKing can't.
When I put the CANKing on our test rig, it can see CAN messages, but the RevPis can't.
A quick look with an oscilloscope showed that the polarities were reversed on the RevPis.
The pinout for the Con CAN is shown as: but in order to get this to work, I have had to reverse CAN_H and CAN_L
There were a few module where the marking was wrong on the x2 connector (pin 1 is left and not right, see module picture in https://revolutionpi.com/documentation/ ... he-can-bus). But at least the pinout on the left side of the module should show the correct mapping.
Nicolai
Nicolai
Ahhh.. that explains it then. Thank you.
You just can't see the side when it's mounted on a heavily populated DIN rail! I was unlucky enough to get two with the printing error.
You just can't see the side when it's mounted on a heavily populated DIN rail! I was unlucky enough to get two with the printing error.
Probably two modules from the same batch, yes. I will make a note with our docs team, that we mention this somehow in the documentation.