search

hmartiro / project-thesis

xJüs, the hexapodal robot with a passive-backbone to improve behavior over harsh terrain.
4 stars 2 forks source link

Optimize CAN Functions #86

Closed PayneTrain closed 11 years ago

PayneTrain commented 11 years ago

Investigate how to create CAN "Shortcuts" to optimize the VCS functions involved particularly with adding PVT points

Timeframe: Start this weekend (3/30)

PayneTrain commented 11 years ago

Issue opened with Maxon to clarify some questions.

PayneTrain commented 11 years ago

Not looking good:

Hello,

For a University project, my team has been using the C++ API included with the EPOS2 24/2 controller. Our project involves a network of 6 controllers connected via CAN to a master node that then connects to a PC via USB.

There are some functions in the C++ code (starting with "VCS_") that we use a lot and we wondered if there is a way to optimize their transmission on the CAN network. I've read through the "EPOS2_Communication_Guide_En.pdf" and it looks like there is a way to "pre-define" functions to make their transmission over CAN faster. Could you give me more details about this, if this is possible?

Thanks,

Chris Historie Kontakt Datum Aktivität Beschreibung

Ineichen, Adrian INA

03.04.2013 02:12 Close Status changed from '2. Approval in progress' to '4. Closed'

Ineichen, Adrian INA

03.04.2013 01:47 Log Solution You are right. SDO communication protocol is supported by the C++ API.

USB The bit rate of 1MBit/s is a theoretical value. The min. time for send and receive one frame is >2ms. This calculates a bit rate of <500kbit/s. With the USB communication protocol only one object value can be read or write. The 63 bytes long frame (USB) is send to the first node (master node / usb-to-can gateway). Then the frame is splitted into 8 bytes long frames (CANopen).

CANopen The frame size is limited of 8 bytes (SDO and PDO). The speed is depends on various factors (cable length, bus traffic). The PDO communication protocol is faster than USB communication (max. 1MBit/s) and there are other advantages:

Note:

Ineichen, Adrian INA

03.04.2013 01:05 Update Status Status changed from '1. Open' to '2. Approval in progress'

Payne, Chris

03.04.2013 00:21 Reopen Thanks for your response.

So the current system we are using is a USB cable connected to a master node. This master node is then connected to the other 6 nodes via CAN using I believe the SDO protocol (SDO is the protocol that the C++ API supports, correct?). The application note says this can deliver 1 MBit/s and use a segment size up to 63 bytes.

What would be the speed reachable using the CAN card and PDO method?

Ineichen, Adrian INA

02.04.2013 01:51 Close Status changed from '2. Approval in progress' to '4. Closed'

Ineichen, Adrian INA

02.04.2013 01:48 Log Solution Dear Chris For a faster transmission use the CANopen PDO communication. For this kind of communication do you need a CANopen card (and usually use a real-time operating system for full functionality). This communication protocol has to be implemented itself. The PDO communication is not supported by the C++ API from maxon.

Note: The bottleneck is the Windows operating system and/or the ‘USB to CANopen Gateway’ from the device EPOS2 (see document EPOS2 Application Note: chapter 11. USB or RS232 to CAN Gateway).

Best regards

mmc support team Adrian Ineichen

hmartiro commented 11 years ago

I made some progress in trying to optimize the C code, but it's unclear yet if it's made things faster. I'll continue Saturday.

On Thu, Apr 4, 2013 at 2:53 PM, PayneTrain notifications@github.com wrote:

Not looking good:

Hello,

For a University project, my team has been using the C++ API included with the EPOS2 24/2 controller. Our project involves a network of 6 controllers connected via CAN to a master node that then connects to a PC via USB.

There are some functions in the C++ code (starting with "VCS_") that we use a lot and we wondered if there is a way to optimize their transmission on the CAN network. I've read through the "EPOS2_Communication_Guide_En.pdf" and it looks like there is a way to "pre-define" functions to make their transmission over CAN faster. Could you give me more details about this, if this is possible?

Thanks,

Chris Historie Kontakt Datum Aktivität Beschreibung

Ineichen, Adrian INA

03.04.2013 02:12 Close Status changed from '2. Approval in progress' to '4. Closed'

Ineichen, Adrian INA

03.04.2013 01:47 Log Solution You are right. SDO communication protocol is supported by the C++ API.

USB The bit rate of 1MBit/s is a theoretical value. The min. time for send and receive one frame is >2ms. This calculates a bit rate of <500kbit/s. With the USB communication protocol only one object value can be read or write. The 63 bytes long frame (USB) is send to the first node (master node / usb-to-can gateway). Then the frame is splitted into 8 bytes long frames (CANopen).

CANopen The frame size is limited of 8 bytes (SDO and PDO). The speed is depends on various factors (cable length, bus traffic). The PDO communication protocol is faster than USB communication (max. 1MBit/s) and there are other advantages:

  • asynchronous/synchronous transmission
  • more than one object value in one frame possible

Note:

  • Most objects from the EPOS device are 4 bytes or smaller
  • Please study the chapter 6 in the document ‘EPOS2 Communication Guide’

Ineichen, Adrian INA

03.04.2013 01:05 Update Status Status changed from '1. Open' to '2. Approval in progress'

Payne, Chris

03.04.2013 00:21 Reopen Thanks for your response.

So the current system we are using is a USB cable connected to a master node. This master node is then connected to the other 6 nodes via CAN using I believe the SDO protocol (SDO is the protocol that the C++ API supports, correct?). The application note says this can deliver 1 MBit/s and use a segment size up to 63 bytes.

What would be the speed reachable using the CAN card and PDO method?

Ineichen, Adrian INA

02.04.2013 01:51 Close Status changed from '2. Approval in progress' to '4. Closed'

Ineichen, Adrian INA

02.04.2013 01:48 Log Solution Dear Chris For a faster transmission use the CANopen PDO communication. For this kind of communication do you need a CANopen card (and usually use a real-time operating system for full functionality). This communication protocol has to be implemented itself. The PDO communication is not supported by the C++ API from maxon.

Note: The bottleneck is the Windows operating system and/or the ‘USB to CANopen Gateway’ from the device EPOS2 (see document EPOS2 Application Note: chapter 11. USB or RS232 to CAN Gateway).

Best regards

mmc support team Adrian Ineichen

— Reply to this email directly or view it on GitHubhttps://github.com/hmartiro/project-thesis/issues/86#issuecomment-15916352 .

hmartiro commented 11 years ago

Creating an array function in the C code has no noticeable benefit, so best to get rid of it. The short USB cable also hasn't helped.

Right now, we're still running on 100 millisecond loop and having a chunk size of at least 5. The high chunk size makes things more complicated than they need to be, and a dt of 100 is just too high. Open to any ideas of how to make things faster.

hmartiro commented 11 years ago

Had to step it up even further to 120 ms and chunkSize of 7 due to sproadic underflows. Really would like to eliminate the need for chunking.

hmartiro commented 11 years ago

Did a full replacement of the Python-C interface. ctypes is now replaced by SWIG. Here's how it works:

Our C++ functions are in the files xjus_API.cpp and xjus_API.hpp. We now also have a simple interface file xjus_API.i which is used by SWIG to construct xjus_API_wrap.cxx, a large C++ file that uses the Python-C API to convert Python arguments to C and back. Then, the library _xjus_API.so is constructed from the three C++ files (not called libxjus anymore). SWIG also creates a python file xjus_API.py, which defines wrappers for all of the functions in the library _xjus_API.so on the Python side. In xjus.py, our main script, we simply do import xjus_API as xjus. The usage is the exact same as it was with ctypes.

The SWIG command to create xjus_API_wrap.cxx and xjus_API.py from the interface file is swig -c++ -python xjus_API.i. I added this to my Eclipse as a pre-build step, so it's automatically done every time I edit a file and build.

The result is that any time difference between the Python and C is eliminated. The code now has exact timing printouts for various stages. Chunking no longer helps because of this, so I got rid of that. However, the full loop still takes about 90-95 ms, so I'm hoping to optimize on the hardware side to reduce dt.

PayneTrain commented 11 years ago

Not happening any further