(no commit message)

[ortcan-www.git] / vca / index.mdwn

diff --git a/vca/index.mdwn b/vca/index.mdwn
index eaef1c4b564d689e8d5df25a98417801a3694815..fde94cffb425c92436983f3d95d752af611ffee1 100644 (file)
--- a/vca/index.mdwn
+++ b/vca/index.mdwn
@@ -11,7 +11,7 @@ master/monitor nodes.
 The build from GIT repository is recomended. The next commands are used to obtain
 sources
 
-    git clone git://ortcan.git.sourceforge.net/gitroot/ortcan/ortcan
+    git clone git://git.code.sf.net/p/ortcan/ortcan-top
     cd ortcan/
     git submodule update --init
     make default-config
@@ -64,7 +64,7 @@ module is controlled by next "config.omk" line
 
     CONFIG_OC_CANSLAVE_NASCANHW=y
 
-The actual build of the libVCA is specified GNu make program
+The actual build of the libVCA is specified GNU make program
 invocation
 
     make
@@ -78,9 +78,10 @@ by underlaying [OMK make system][omk] can be found on its [home page][omk].
 ### 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.
+is part of [WP7.4 Communication Components V2 deliverable][oceraD74].
+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.
@@ -96,7 +97,7 @@ 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.
+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
@@ -108,13 +109,14 @@ 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
+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
+    6000:01 /nascanhw/input01
+    6200:01 /nascanhw/output01
 
 You can test most of build components by script
 
@@ -144,10 +146,10 @@ is missing.
 
 On the other hand for simple applications, [CANfestival](http://sourceforge.net/projects/canfestival/)
 is probably faster and simpler implementation.
-There are some examples of its use in other project of our department
-<http://dce.felk.cvut.cz/waszniowski/>.
-On the other hand, if application is expected to be runtime configurable,
-then OrtCAN approach is better suited for such use. CANfestival is not
+There are some examples of its use together with Matlab and Real-Time Workshop
+in other [projects][hil_ydc] 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 
@@ -158,7 +160,7 @@ 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 should be done without polling.
+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
@@ -181,3 +183,5 @@ of list for PDOs with pending requests.
 
 [omk]:http://rtime.felk.cvut.cz/omk/
 [socketcan]:http://developer.berlios.de/projects/socketcan/
+[oceraD74]:http://www.ocera.org/download/documents/deliverables/ms4-month24.html
+[hil_ydc]:http://support.dce.felk.cvut.cz/pub/xwasznio/HIL_YDC/HIL_YDC.htm