We haven’t used that CAN analyzer, but it would be nice if you can get it working and not pay out for the Kvaser. We use the kvaser you linked, as well as the Peak PCAN-USB Adapter (my personal preference).
A few things you can check:
Is the CAN adaptor adding a terminating resistor? Make sure it is not, as the bus should already be properly terminated.
If you are connecting it over USB to your laptop or computer, make sure the CAN drivers are properly installed and the CAN interface is properly setup. I see the product you purchased has documentation on that for Windows & Linux.
Let us know how it goes, as @TravisT may have thoughts as well.
Hey @kylecoble and @TravisT,
We have used this product and are currently using it on a different project as well, so the device works fine. The drivers are also setup correctly since it works for the other project.
We use ‘candump’ to verify the device is working.
The issue is that we don’t even reach the stage of connecting and reading data.
As soon as we power connect the CAN device to a USB port, the dashboard immediately throws that error. As this point we are not even sending or receiving data, we have just powered the devices. It’s like as soon the CAN devices is powered on the entire CAN network goes down.
Less worried about our system, that seems to work and recovers when the CAN tools is removed. So when I asked about do you see CAN messages and configuration I am speaking from the point of view of the device you are connecting and appears to be bringing down the CAN bus. I need to understand what that device is seeing and trying to do.
My suggestion is to connect the CAN tool to you laptop, make sure it is setup (share your configuration of the CAN tool), before you connect it to the bus on the Amiga. Not all CAN tools are created equal and depending on how they are built or setup could power up in a bad state (not passive) or the wrong configuration. You need to make sure that is in a good state first then hook up to the bus so we can further debug.
Right now I have no information on how the CAN tool is configured, and since we do not support that tool so all my debugging is through you.
The wiring looks correct, but CAN requires a ground reference. It does not always matter but your laptop does not have the same ground as the Amiga which can easily cause issues. Please hook up the ground wire and see if this resolves your issue, otherwise the PIN can appear floating. In automotive you can get away with not hooking up ground, but that is only when everything is chassis referenced or fully isolated.
So when I connect the CAN device, at that point the device is doing nothing. It is neither sending or receiving data. It is just in an idle state (which can be seen further verified by the non-blinking RX & TX LED).
I tried this:
Connect the CAN to laptop
Run our script which sends commands over CAN to drive the robot forward at 0.1 m/s.
Verified that the TX lights are blinking on the device.
Connect it to the Amiga and power on the Amiga.
In the above steps ground was also connected. I have also messaged you the scripts we used for testing.
Am I missing something or is there something else I should try as well?
It will be easier to debug if we understand the Amiga is doing what it is supposed to, and based on what I have seen something you introduce is causing the issues. So far physically it looks fine, so we have to assume that the devices either because of the default state or because configuration is causing issues. Even if it is unlikely the device can appear to do nothing, but it could be loading down the bus signals, or attempting to ACK other devices.
I understand that when you try to run the script with the CAN tool not connected to the Amiga it will do little to nothing, but what it does do is force it into a known state before you then connect it to the bus. This removes the variables of the default state of the CAN tool. Again we do not use or support this tool so I cannot assume the default power on state.
Once it is powered and idle then try connecting it to the Amiga. Again this removes the variables of the default state. If it is still causing issues then we look at how you configure the device.
You are again not including configuration information on the CAN tool, not all CAN interfaces are the configured the same, and mismatches will cause communication issues. Luckily another one of your post shows the script you are using, which is not setup correctly for the Amiga. The Amiga CAN bitrate is 250K and not 500K, which could also potentially cause issues.
It is typically less problematic to debug CAN by listening and not sending. Once you know you can see messages on the bus it is safer to send.
You also mention “0.1 m/s”. Can you confirm what you mean by “m/s”. Is that “messages/second”? Or did you mean milliseconds (ms)? If you can confirm the delta in milliseconds between sends we can also determine if this is an issue as well.