[[!meta title="libVCA (OrtCAN Virtual/Versatile CAN API library)"]]

The library providing common API for CAN/CANopen bus protocol.
It can be used with [[LinCAN|lincan]] and [SocketCAN](http://developer.berlios.de/projects/socketcan/)
Linux drivers. The CANopen part can be used as base for
implementation of CANopen devices as well as CANopen
master/monitor nodes.

## 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 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
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 on its 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. For simple applications, CANfestival is probably
faster way to go.

You can find some examples even in other project of our department <http://dce.felk.cvut.cz/waszniowski/> On the other hand,
if you want something runtime configurable, then work with
OrtCAN sources worth to be considered. CANfestival is not
prepared nor intended to allow dynamic dictionary operations.