vca/index.mdwn

   1 [[!meta title="libVCA (OrtCAN Virtual/Versatile CAN API library)"]]
   2
   3 The library providing common API for CAN/CANopen bus protocol.
   4 It can be used with [[LinCAN|lincan]] and [SocketCAN](http://developer.berlios.de/projects/socketcan/)
   5 Linux drivers. The CANopen part can be used as base for
   6 implementation of CANopen devices as well as CANopen
   7 master/monitor nodes.
   8
   9 ## VCA CANopen Functionality
  10
  11 ### Standard EDS and VCA Hardware Connection Configuration HDS Files
  12
  13 The most comprehensive OCERA RT CAN/CANopen components documentation
  14 is part of WP7.4 deliverable. But it is quite dated and not fully
  15 complete, same for some code features. The basic CAN part and river
  16 has been in production use and is tested and documented in separate file.
  17 Because OCERA project code base is not maintained as whole for
  18 some time, we are in process of separation of the parts which
  19 have been maintained and has potential for future.
  20
  21 As for OCERA CANopen stuff, it has been designed as highly dynamic
  22 with possibility to mimic different hardware devices and to develop
  23 complete CANopen master to build dictionary proxies to multiple
  24 devices for multiple higher level clients. The base infrastructure
  25 is laid out, we use canblaster to access devices dictionaries
  26 from Java based CANmonitor and to analyze CAN traffic from Qt based tool.
  27
  28 On the device side, the capability to mimic device dictionary according
  29 to EDS file is implemented. The HDS is additional description,
  30 which allows to load shared libraries (DLLs) and map object dictionary
  31 objects into generic CANopen device binary. This way it is possible
  32 add new I/O capability without need to rebuild base binary.
  33 The HDS file maps object dictionary index and subindex to named
  34 data I/O descriptor DINFOs which are exported by shared library
  35 object. You can find example of implementation of such module
  36 in the file
  37
  38     ortcan-top/app/candev/nascanhw/nascanhw.c
  39
  40 The "nascanhw.so" implements two integer I/O variables (DINFOs)
  41 "input01" and "output01" which are connected together to copy
  42 "input01" to "output01" variable. The copy action is then notified
  43 back into "canslave" generic code. This allow to even map these object
  44 into PDOs and request to sent PDO on its values changes. The "hardware"
  45 provided variables are mapped into object dictionary by device
  46 (Hardware Description File) HDS. The "nascan.hds" is simple example,
  47 which interconnects the first digital outputs group with with
  48 the first digital inputs group for DS401 profile device.
  49
  50     6000:01 /nascanhw/input01 6200:01 /nascanhw/output01
  51
  52 You can test most of build components by script
  53
  54     ./test-can-in-konsole
  55
  56 The script  test native build of LinCAN in the KDE konsole window.
  57 This script uses command DCOP scripting capabilities of konsole
  58 and if it is started from already running console, scripting has
  59 to be enabled.
  60
  61 Parameter "--script" is required when konsole has been started.
  62
  63     konsole --script
  64
  65 You can run individual commands by hand as well.
  66
  67 As for whole OrtCAN CANopen implementation, I believe still,
  68 that it is right way to go to have something generic with possibility
  69 to integrate into SCICOS or Matlab-Simulink models. There is potential,
  70 but we have not found project to fund some faster progress
  71 in the attempt. Basic CANopen infrastructure works but mapping
  72 is updated only when device is switched from and back to CANopen
  73 OPERATIONAL state.
  74
  75 The full implementation of all PDO time triggered transfers modes
  76 is missing.
  77
  78 On the other hand for simple applications, [CANfestival](http://sourceforge.net/projects/canfestival/)
  79 is probably faster and simpler implementation.
  80 There are some examples of its use in other project of our department
  81 <http://dce.felk.cvut.cz/waszniowski/>.
  82 On the other hand, if application is expected to be runtime configurable,
  83 then OrtCAN approach is better suited for such use. CANfestival is not
  84 prepared nor intended to allow dynamic dictionary operations.
  85
  86 ## Time Triggerred CANopen PDO Messages
  87
  88 The VCA code places infrastructure there, but not all features
  89 are finished. It is waiting to some spare time, project funding,
  90 students diploma thesis work or contributors.
  91
  92 The PDO can be sent as response to the source value change notification
  93 over event connectors. This is tested, works and is probably most
  94 complicated mode if should be done without polling.
  95 The SYNC driven and time driven modes needs to be implemented.
  96 The function _pdo_hub_event() should be divided into part processed
  97 at variable change notification, which only marks fields requiring
  98 update and PDO should be moved on list of Tx PDOs which require
  99 more processing. The second part should do real update and sending.
 100 Then PDO processor should take PDO from the list, update it and send
 101 it to the CAN bus. SYNC response would mean only connecting
 102 of SYNC filer and new rx_hub on PDO processor through
 103 vcaNet_msg_rec_connect(). SYNC processing would mean only marking PDO
 104 as requiring to be sent. Each PDO should contain timer field and then
 105 periodic mode could be implemented as marking PDO to be sent
 106 in timer call-back.
 107
 108 The function vcaPDOProcessor_processMsg() is alternative to use
 109 of the full vcaNet_msg_rec_connect() infrastructure.
 110 So yes, above mentioned functionality of marking
 111 SYNC triggered PDOs for Tx could be added there.
 112 The key is to refactor _pdo_hub_event() function and addition
 113 of list for PDOs with pending requests.