I'm trying to use this to communicate
- with my focci board (
https://github.com/uhi22/foccci)
- running the ccs32clara firmware (
https://github.com/uhi22/ccs32clara)
- using a Lawicel CANUSB adapter (
https://www.canusb.com/products/canusb/)
- on Fedora Linux 38
This is not going exactly swimmingly.
I first tried this type of configuration when running oic:
Code: Select all
interface = slcan
channel = /dev/ttyUSB0
bitrate = 500000
One problem is that in this mode, the CANUSB adapter does not ACK any messages on the bus unless someone has the device open. As a result, the target board ends up flooding the bus with re-send attempts right until the point where oic opens the device, after which the CANUSB adapter starts to respond to ACKs, and right when oic closes the device, the adapter appears to stop responding to ACKs again. To be exact, I don't have a CAN analyzer that would prove me it's the ack bit, but the behavior exactly matches that which in my experience results from the missing ACK bit.
Anyway, given this gotcha, I still could attempt using oic. Here is the result:
Code: Select all
$ oic scan
Scanning for devices. Please wait...
No nodes found
$ oic -n 22 serialno
Transfer aborted by client with code 0x05040000
SDO communication error: No SDO response received
$ oic -n 22 listparams
Transfer aborted by client with code 0x05040000
Traceback (most recent call last):
File "/home/celeron55/programs/openinverter_can_tool/openinverter-can-tool/venv/lib/python3.11/site-packages/canopen/sdo/client.py", line 65, in read_response
response = self.responses.get(
^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/queue.py", line 179, in get
raise Empty
_queue.Empty
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/celeron55/programs/openinverter_can_tool/openinverter-can-tool/venv/bin/oic", line 8, in <module>
sys.exit(cli())
...
... (long traceback cut out)
...
File "/home/celeron55/programs/openinverter_can_tool/openinverter-can-tool/venv/lib/python3.11/site-packages/canopen/sdo/client.py", line 68, in read_response
raise SdoCommunicationError("No SDO response received")
canopen.sdo.exceptions.SdoCommunicationError: No SDO response received
Ok. Well, it's clearly not working. We have another method to try, though: We can use slcand to turn this into a socketcan interface. Let's try:
Code: Select all
$ sudo slcand -F -o -c -f -s6 /dev/ttyUSB0 can0 # Speed 6 = 500kbpsps
We'll leave that running on the foreground.
We can immediately see on the scope that CANUSB starts to respond to ACKs as the target board stops flooding the bus.
Now, the interface still needs to be brought up first.
And then we'll configure python-can to use socketcan:
Code: Select all
interface = socketcan
channel = can0
bitrate = 500000
Now it'll surely work, right? Right? There's nothing we can do but try to call oic again:
Code: Select all
]$ oic scan
Scanning for devices. Please wait...
CAN error: Failed to transmit: No buffer space available [Error Code 105]
Oh no! What does this even mean?
Then the rest of it:
Code: Select all
$ oic -n 22 serialno
Transfer aborted by client with code 0x05040000
SDO communication error: No SDO response received
$ oic -n 22 listparams
Transfer aborted by client with code 0x05040000
Traceback (most recent call last):
File "/home/celeron55/programs/openinverter_can_tool/openinverter-can-tool/venv/lib/python3.11/site-packages/canopen/sdo/client.py", line 65, in read_response
response = self.responses.get(
^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.11/queue.py", line 179, in get
raise Empty
_queue.Empty
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/celeron55/programs/openinverter_can_tool/openinverter-can-tool/venv/bin/oic", line 8, in <module>
sys.exit(cli())
^^^^^
...
... (long traceback cut out)
...
File "/home/celeron55/programs/openinverter_can_tool/openinverter-can-tool/venv/lib/python3.11/site-packages/canopen/sdo/client.py", line 68, in read_response
raise SdoCommunicationError("No SDO response received")
canopen.sdo.exceptions.SdoCommunicationError: No SDO response received
No luck at all.
Looking on the scope, the target board appears to be sending stuff with a bit length of about 2us which matches the 500kbaud we are setting.
Disconnecting the target board from the bus lets us notice the CANUSB adapter is also sending frames with a 2us bit length, which matches. We can also see the bus is being flooded by retransmitted frames from the PC side, as nobody is ACKing them now.
Now in this socketcan mode, I can also use
to look at the data sent by the target board. There doesn't seem to be any obvious problem with the data.
So, it looks like the basic CAN communication is working (I haven't for example swapped H and L, and the bitrate is correct), yet oic fails to get any useful results.
One problem is, I don't know what this protocol is supposed to look like when it's working, so I can't determine any problems at the frame level. The board is very talkative, and I don't know whether this protocol is supposed to be hidden within the same frame ids, or whether new frame ids should pop up. I have attached the
"candump -tz can0" output of running the previously listed three oic commands. The vast majority of the data is not related to oic, though.
Anyone got any ideas?