WARNING: With the current Makefile implementation, the first time you
make all after a clean in ws/src, the make fails and you have to do make
all a second time.
This is because some targets are not built in the proper order.
This will be fixed with ACS 3.1 oficial release.

To be completed.

This module contains an example of integration between ACS and VLT
software developed step by step during the ACS/VLT course in Garching
in February 2004.
Each step increments the previous one and is kept as much as possible
separate so that can be read independently, focusing only on the
specific purpose of the tutorial.

We develop a Mount Component and we try to put inside functionality
and to use it.

Example:

====> IDL

Mount       - a Mount interface with ACS Baci properties

MountAsync  - adds asynchronous methods

MountNotify - publishes data on a Notification Channel

====> Clients:

- acsVltMountSimple:     a minimal python client connecting to  MOUNT2_LOOP
- acsVltMountCallback :  a python client using callbacks connecting to
- Abeans gui.
  The ws/src/VisualACSApplication contains a NetBeans project for a
  GUI implemented with ABeans interfacing tothe MOUNT Components.
  You can run it with the following command from the ws/src/directory:
   
  > acsStartJava VisualACSApplication.VisualACSApplication

====> Running the examples and test

- Build the module in ws/src

- VLT CCS Environments:
  - The directory 
      ws/test/ENVIRONMENTS
    contains a VLT Environment called walma to be used.
    Start it using tat or copy it in $ACSDATA/ENVIRONMENTS and start it
    with the following commands:
    > cd $ACSDATA/ENVIRONMENTS/walma/dbl
    > make db
    > cd ..
    > vccEnvInit -e walma -t QSEMU
    > vccEnvInit -e walma -t QSEMU
  
  - Make sure that the RTAPENV environment variable is set to "walma"
  - You can use the ccseiDb tool to check what the database of the
    environment containes.
    Essentially is contains a standard TIF database branch used for
    testing.

- ACS configuration database
  Make sure that ACS_CDB point to the test configuration database
  in ws/test.
  For example issue in each shell the command:
   > export ACS_CDB=<module_path>/ws/test

- Start ACS Services and Manager ACS using for example the ACS Command
  Center 

- Start the "VLT Container"
  In order to run Components that can talk both to other ACS
  components and to VLT processes you need to use a specially
  customized container implementation that initializes the VLT CCS
  message system and access to the CCS Environment.
  The ACS/VLT components will run in this container, named
  "mountContainer" in the CDB:

  > acsVltContainer mountContainer

- Start the VLT evhDummy simulator
  Some ACS components will try to send commands to a VLT server called
       "tifCA"
  This server is simulated using an evhDummy process, whose
  configuration file is in the test directory:
 
  > evhDummy -n tifCA <modpath>/ws/test/testEvhDummy 

- Now you can use the Object Explorer to activate the components and
  play with them.
  Here are some examples of what you can do with the dcurrent
  implementation:

  -  Using MOUNT2_01
     - As you can see in the CDB it:
       - Implements  MOUNT idl interface
       - Uses the acsVltMountImpl C++ implementation
     - You can do a get_sync for the properties
          acsAz and actEl
       These properties read the value from the VLT database
       attributes:
       
       :Appl_data:TCS:tif:data.azRef and altRef

       using the DevIODBRead implementation
     - You can change these values ni the VLT database 
       using the ccseiDb or dbRead/Write utilities.

  - Using MOUNT2_LOOP
     - As you can see in the CDB it:
       - Implements  MOUNT idl interface
       - Uses the acsVltMountLoopImpl C++ implementation
     - This Component controls the position using a control loop
       At each tic, it check is the commanded position is different
       from the actual position (read from the VLT database).
       If not it currently does two things:
       - Tries to write the position in the VLT databade using the
         devio.
         Since dbWrite is not implemented in the example, nothing
         happens.
       - Tries to sent the PRALAZ command to TifCA.
         On the real VLT Control Model this would work.
         Using the evhDummy nothing happens.
       So you have to implement these missing functionality or
       you can simply use ccseiDb or dbWrite to write the expected
       values in the VLT database.
   - Using MOUNT_NOTIFY
     - As you can see in the CDB it:
       - Implements  MOUNT_NOTIFY idl interface
       - Uses the acsVltMountNotifyImpl C++ implementation
       whenever an objfix command is received, the values are
       published on the notification channel.
       The implementation includes also a consumer thar receives
       the very same notification it has just sent.
       You can also start the acsVltMountConsumer python script to
       receive the same events.
     - There are a couple of examples of usage of the Notificaiton
       Channel:
       - Python:
         - ws/src/acsVltMountSupplier.py
         - ws/src/acsVltMountConsumer.py    
         implement a python example
       - Java
         - /ws/src/alma/ACSVLT_MOUNT/Mount/MountSupplier.java 
         - /ws/src/alma/ACSVLT_MOUNT/Mount/MountConsumer.java 
         implement a java exmaple

======> Exercices

- Implement also a DevIODBWrite for RW properties.
- Modify MOUNT so that the OBJFIX command sets the value of actAz and
  acsEl properties 
- Implement a better evhDummy for tifCA that also writes the database.
- Implement an automatic modular test based on tat.





