libVCA (OrtCAN Virtual/Versatile CAN API library)

The library providing common API for CAN/CANopen bus protocol. It can be used with LinCAN and SocketCAN Linux drivers. The CANopen part can be used as base for implementation of CANopen devices as well as CANopen master/monitor nodes.

VCA Library Quick Build Instructions

The build from GIT repository is recomended. The next commands are used to obtain sources

git clone git://git.code.sf.net/p/ortcan/ortcan-top
cd ortcan/
git submodule update --init
make default-config

The build components selection and configuration is controlled by "config.omk" file which overrides "config.omk-default". The default sources configuration builds VCA support for LinCAN and LinCAN driver is build as well. The option for building library sources relinkable into shared objects (DLLs) is required for example modules building on x86_64 and PowerPC targets

echo 'CFLAGS+=-fpic' >>config.omk

Next configuration options should be specified in "config.omk" file to build VCA library with SocketCAN support only

CONFIG_OC_LINCAN=n
CONFIG_OC_ULUTKERN=n
CONFIG_OC_CANVCA_IFC=socketcan

The VCA library can be build even with runtime selectable CAN bus access support. This is enabled by option "multi" and list of interfaces which are compiled into library

CONFIG_OC_CANVCA_IFC=multi
CONFIG_OC_CANVCA_IFC_lincan=y
CONFIG_OC_CANVCA_IFC_socketcan=y

The whole tree of sources includes generic CANopen slave device implementation ("canslave" executable) which mimics standard CANopen nodes implemented by dedicated hardware. The OD (CANopen Object Dictionary) is specified at program startup by specifying which standard EDS file should be parsed to build index and subindex structures of OD. The build is controlled by next "config.omk" option

CONFIG_OC_CANDEV=y

The "canslave" executable can be used not only to provide OD behavior for CAN bus remote access but can be used without need of recompilation to connect OD data with real or simulated hardware data sources. The connection is realized by specifying interconnection between OD index and subindex entries and named data access information structures (DINFO) provided by loadable modules. Example of simple example of such module which provides two mutually interconnected data items is provided in "app/candev/nascanhw/nascanhw.c" source file which is build into "libnascanhw.so" module. The build of that example module is controlled by next "config.omk" line

CONFIG_OC_CANSLAVE_NASCANHW=y

The actual build of the libVCA is specified GNU make program invocation

make

The result binaries are found in "_compiled/bin" after successfull build. More information about possible make targets provided by underlaying OMK make system can be found on its home page.

VCA CANopen Functionality

Standard EDS and VCA Hardware Connection Configuration HDS Files

The most comprehensive OCERA RT CAN/CANopen components documentation is part of WP7.4 Communication Components V2 deliverable. But it is quite dated and not fully complete, same for some code features. The basic CAN part and river has been in production use and is tested and documented in separate file. Because OCERA project code base is not maintained as whole for some time, we are in process of separation of the parts which have been maintained and has potential for future.

As for OCERA CANopen stuff, it has been designed as highly dynamic with possibility to mimic different hardware devices and to develop complete CANopen master to build dictionary proxies to multiple devices for multiple higher level clients. The base infrastructure is laid out, we use canblaster to access devices dictionaries from Java based CANmonitor and to analyze CAN traffic from Qt based tool.

On the device side, the capability to mimic device dictionary according to EDS file is implemented. The HDS is additional description, which allows to load shared libraries (DLLs) and map object dictionary objects into generic CANopen device binary. This way it is possible to add new I/O capability without need to rebuild base binary. The HDS file maps object dictionary index and subindex to named data I/O descriptor DINFOs which are exported by shared library object. You can find example of implementation of such module in the file

ortcan-top/app/candev/nascanhw/nascanhw.c

The "nascanhw.so" implements two integer I/O variables (DINFOs) "input01" and "output01" which are connected together to copy "input01" to "output01" variable. The copy action is then notified back into "canslave" generic code. This allow to even map these object into PDOs and request to sent PDO when the mapped object values changes. The "hardware" provided variables are mapped into object dictionary by device (Hardware Description File) HDS. The "nascan.hds" is simple example, which interconnects the first digital outputs group with with the first digital inputs group for DS401 profile device.

6000:01 /nascanhw/input01
6200:01 /nascanhw/output01

You can test most of build components by script

./test-can-in-konsole

The script test native build of LinCAN in the KDE konsole window. This script uses command DCOP scripting capabilities of konsole and if it is started from already running console, scripting has to be enabled.

Parameter "--script" is required when konsole has been started.

konsole --script

You can run individual commands by hand as well.

As for whole OrtCAN CANopen implementation, I believe still, that it is right way to go to have something generic with possibility to integrate into SCICOS or Matlab-Simulink models. There is potential, but we have not found project to fund some faster progress in the attempt. Basic CANopen infrastructure works but mapping is updated only when device is switched from and back to CANopen OPERATIONAL state.

The full implementation of all PDO time triggered transfers modes is missing.

On the other hand for simple applications, CANfestival is probably faster and simpler implementation. There are some examples of its use together with Matlab and Real-Time Workshop in other projects lead by Libor Waszniowski. But that approach has limited support for runtime configurable applications and for such cases the OrtCAN approach is better suited. CANfestival is not prepared nor intended to allow dynamic dictionary operations.

Time Triggerred CANopen PDO Messages

The VCA code places infrastructure there, but not all features are finished. It is waiting to some spare time, project funding, students diploma thesis work or contributors.

The PDO can be sent as response to the source value change notification over event connectors. This is tested, works and is probably most complicated mode if that should be done without polling. The SYNC driven and time driven modes needs to be implemented. The function _pdo_hub_event() should be divided into part processed at variable change notification, which only marks fields requiring update and PDO should be moved on list of Tx PDOs which require more processing. The second part should do real update and sending. Then PDO processor should take PDO from the list, update it and send it to the CAN bus. SYNC response would mean only connecting of SYNC filer and new rx_hub on PDO processor through vcaNet_msg_rec_connect(). SYNC processing would mean only marking PDO as requiring to be sent. Each PDO should contain timer field and then periodic mode could be implemented as marking PDO to be sent in timer call-back.

The function vcaPDOProcessor_processMsg() is alternative to use of the full vcaNet_msg_rec_connect() infrastructure. So yes, above mentioned functionality of marking SYNC triggered PDOs for Tx could be added there. The key is to refactor _pdo_hub_event() function and addition of list for PDOs with pending requests.