Welcome!

Welcome to Satlover forums, full of great people, ideas and excitement.

Please register if you would like to take part. link..

Register Now

Alert: Don't Use Hotmail Email Accounts for registration

Collapse

Before Access to all Forums and Trial accounts you must need to activate your account Email address

J/CoMM 0.1.1

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • versign
    Member
    • Mar 2010
    • 51

    J/CoMM 0.1.1

    J/CoMM description
    J/CoMM is an OS-independent RS232 remote control.

    J/CoMM server is a middleware between RS232 controllable hardware devices (like VCR's, data projectors, cameras etc.) and a graphical user interface.

    Typically you will install J/CoMM server on a central workstation with multiple RS232 interfaces and with multiple hardware devices connected.

    J/CoMM server provides a web interface which allows you to base your GUI on HTML and, more important, to run different instances of that GUI on serveral client computers at the same time. Though internet enabled, J/CoMM is also suitable for running on a single workstation.

    J/CoMM supports the development of HTML based GUI's by providing

    * a Java applet which establishes the communication between the GUI website(s) and the server and
    * a library of Javascripts which contains DHTML classes like buttons, displays, players as well as keyboard and network support.

    You will find a couple of device drivers packaged with J/CoMM. But J/CoMM also includes a device driver API which allows you to easily create custom drivers.

    Requirements:

    · Linux, SUN OS/Solaris or Windows
    · JRE 1.3+
    · Comm API or similar
    · A web browser to display the HTML GUI (Netscape 6+, Explorer 5+)
    · Java Browser Plugin 1.3+
    · Linux, SUN OS/Solaris or Windows
    · JRE 1.3+
    · Comm API or similar
    · A web server to host the HTML GUI



    J/CoMM server is a stand-alone Java application with no user interface at all. Typically you will start J/CoMM from the terminal:

    java [-cp classpaths] de.tudresden.ias.jcomm.net.JCommServer cfgFile

    The only way of communicating with J/CoMM server is through a RMI connection. After starting J/CoMM server, the only possible "user interaction" (other than a network connection) is terminating the application with the key combination Ctrl + C.

    The only way of configuring J/CoMM server is through a configuration file whose name has to be passed through the command line (cfgFile). This configuration file defines which devices shall be mounted during server startup. Mounting a device means to load an appropriate hardware driver and to bind the device to a unique identifier and to a serial port.

    Here is an example of a complete J/CoMM configuration file:

    ## ------------------------------------------------------------------
    ## J/Comm Configuration

    ## Device ID ---- Driver --------------------------------------- Port

    SONY_EVID31_01 de.tudresden.ias.jcomm.drivers.JCommSonyEviD31 COM1
    EIKI_LCVM1_01 de.tudresden.ias.jcomm.drivers.JCommEikiLcvm1 COM2

    ## EOF --------------------------------------------------------------

    Any text from a '#' charcter to the end of the line is ignored. White spaces are not signifcant. Each hardware device is defined by exactly one line. Such a line contains exactly three white space separated items:

    1. A unique identifier for the device
    2. The fully qualified class name of the device driver
    3. The (OS dependent) name of the port the device is connected with

    Custom hardware drives need not to be packaged with the J/CoMM applications. All drivers will be loaded dynamically. The only important thing is that the class path to your custom drivers is correctly set so that java can load the driver's class files.

    J/Comm server communicates through an RMI interface with the outside world. When starting, it binds to the URL MachineIP/JCommServer:1099. The RMI interface - as defined in de.tudresden.ias.jcomm.net.JCommServerItf - consists of two important communication methods:

    * String InvokeDevice(String sDevice, String sCmd, String sParam)
    * String GetDeviceState(String sDevice)

    The first one is used to synchroneously invoke a function of the hardware device or to write or read data (such as settings) to/from the device. The second one is used to asynchroneously determine the state of the hardware device.

    What exactly "state" means is defined by the device driver - usually drivers return few important information like power state, error state etc. The major difference between the two methods is that InvokeDevice blocks until the hardware responded (or timed out) while GetDeviceState immediately returns the last known state of the device (which is frequently updated by the driver - don't care!).

    J/CoMM uses unique identifier strings to address hardware devices - that's the sDevice argument to both interface methods. These device identifiers are user defined. An identifier is assigned to a particular device while mounting ot during server startup.

    Each device driver defines a number of commands (argument sCmd of InvokeDevice) which allow to access the different functions and settings of a device. Parameters for a command (e.g. data values to be transferred to a device) are handed through the argument sParam of InvokeDevice.

    The number and format of these parameters is defined by the device driver. However, as a convention, all parameters shall be formatted as plain strings, multiple parameters shall be separated by tab stops (ASCII code 0x09). Both communiation methods return the result of the operations in form of a string. Like the sParam argument, the meaning of these strings depends solely on the device driver while the same general formatting conventions apply.

    J/CoMM comes with a ready-to-go client side counterpart to the J/CoMM server. That is a Java applet to be embedded into the HTML GUI. This applet establishes and maintains the network connection to J/CoMM server.

    The communication between applet and the dynamic HTML GUI is realized through the "live wire" (or "active scripting") capability of modern web browsers. In short hand - you can simple invoke methods of the J/CoMM applet from your Javascript. The applet then routes the call to the J/CoMM server through RMI, the server communicates with the hardware device - it's as simple as that.




    _http://linux.softpedia.com/progDownload/J-slash-CoMM-Download-595.html
Working...