 |
 The CamileTG software platform is an innovative process development tool that gives researchers a competitive edge in the research environment. The software allows multiple applications to be executed simultaneously while providing precise control and data acquisition. The state-of-the-art software allows the researcher to rapidly understand and develop new processes as well as safely run experiments unattended.
The CamileTG software is an open platform. The software itself knows nothing about the objects it can display and execute. Objects are added to the software by DLL libraries, referred to as drivers. Drivers can be registered with CamileTG in any combination to provide or remove whatever capabilities are appropriate. Because the drivers are self-contained DLLs, it is possible to update objects by simply distributing a new DLL file. Below is a list of the objects currently available to CamileTG.
When the CamileTG software compWhen the CamileTG software compiles an application into run mode, the drivers provide the snippets of process control code that represent their objects on the workareas. The CamileTG software arranges the snippets into the correct order and compiles the code files into DLLs. The CamileTG runtime engine then loads the DLLs and begins executing the code to begin controlling the process. Each workarea compiles to its own DLL, thereby allowing individual workareas to enter and exit run mode independently. Once a workarea is compiled, it will only be compiled again if modified. CamileTG Architecture The CamileTG software was developed over a two year period starting in 1996. Jim Shaffer was the lead architect. He was charged with designing the underlying interfaces and state machines that would allow drivers of any form or function to participate in the CamileTG workspace. Jim also served as lead developer, implementing the process control and hardware object drivers, and some display object drivers including the Chart, Text and Wire drivers. The software is written entirely in C++ using VS6.0 and MFC. Object oriented design principles were used to ensure base classes handled all common tasks, allowing the developer to focus on unique capabilities in the inherited classes. For example, displays object do not participate in the compilation process so they do not override the default compilation support provided in the base classes. All objects created by the user live in a central database. This includes everything placed on a workarea, as well as things that are not on workareas such as workareas themselves, scripts and log files. Each driver registers with the database the different objects it implements. Objects appear to the rest of CamileTG as essentially a list of properties. The property values for each object live only in the central database. Drivers are responsible for the behavior of their objects, such as to create a new object, paint an object, compile an object, transition an object into and out of run mode and provided a dialog through which users can modify property value. When the driver registers its objects with the central database, it assigns privileges to each property. The privileges determine who can change the property?s value, and under what conditions it can be changed. Some properties are read-only meaning only the driver has privileges to update the value. Some properties are read-write meaning the value can be changed from anywhere. Some properties are read-only when the application is running. Events are triggered whenever property values are changed, allowing the driver as well as the rest of CamileTG to monitor value changes of any property for any object. Drivers always use the property values in the database, never keeping local copies of the data for themselves. Since all properties values are visible in a central database, accessing those values is universally the same for all objects regardless of form or function. This is at the core of CamileTG?s power and flexibility. Anything the user can do manually to an object can be done automatically by other objects and scripts. The database itself is not an actual database. It?s an in-memory property repository with O(1) lookup and O(log n) searching. Speed is critical when propagating property value changes to ensure runtime operations are not impeded. Applications can be setup to run within the CamileTG platform at frequencies up to 10Hz. Typically applications execute at 1HZ. Because workareas are compiled and executed as separate entities, each workarea can operate at its own frequency. The frequency of a workarea determines how often the continuous control objects are evaluated, and sequential controls objects are stepped. Applications are run in their own address space, and each workarea within its own thread. Property value changes made by the executing application are fed back to the central database through a circular queue rendered in a memory mapped file. All runtime operations are protected by synchronization classes from unintended pre-emptive interruption. CamileTG applications are expected to run weeks or months at a time. To ensure consistent performance of the application over such long time periods, memory allocations are done so as to minimize heap fragmentation. Temporary heaps are used when fragmentation is unavoidable. CamileTG?s driver model isolates actual hardware devices from the hardware objects that represent them on the workareas. A secondary driver model exists for hardware devices that the hardware objects use to read and write data from the devices. There are over 16 hardware drivers available for CamileTG, providing support for over 50 individual hardware devices. CamileTG Sample Application Screen Captures
CamileTG Sample Source Code CamileTG Statistics
|
 |
|||||||||||||||||||||
 |
|||||||||||||||||||||||
 View Portfolio |
|||||
 |
|||||
 |
