Overview

The values of CIMPLICITY points can be used in a variety of ways by a script. You can use scripts that act on point values to define reactions to changing conditions in your process.

Points are manipulated by the PointSet statement and PointGet function or the point object. In general, PointSet and PointGet are useful if you require the value of the point or wish to set the point. The point object extends your capabilities by allowing you to receive point values as they change, access array points, provide more information about the point's configuration; and improve performance when repeatedly setting a point.

Security

The CIMPLICITY extensions to Basic provide the same security which all your CIMPLICITY applications use; Set Point Security, Set Point Privilege, Download Password and Set Point Audit trail. Consult the CIMPLICITY documentation for a detailed description of these features.

In order to discuss security, first we will need to understand when security is imposed on your access to points. There are two categories of processes running on your CIMPLICITY Server; User Applications and Resident Processes.

User Applications are applications run by the user, that usually provide a user interface. Examples of such programs are CimView, CimEdit, Alarm Viewer and Program Editor. In order for the application to access a point on the local CIMPLICITY project or a remote CIMPLICITY project, a user login is required. The CIMPLICITY privileges defined for your User ID define your capabilities.

Resident Processes are processes that are started as part of your CIMPLICITY project. Examples of resident processes are the Database Logger, Point Manager and scripts automatically run by the Basic Control Engine. Since a resident process is a trusted part of your system, a resident process is not required to obtain a login in order to access points in their project. If the resident process wishes to access a point on a remote system, a remote project must be configured to supply the resident process with the User ID and Password with which to log in to the remote system.

Performance

The CIMPLICITY extensions to Basic provide a high performance mechanism to interact with your Point Database. However, there are several considerations to keep in mind when designing your application to obtain the highest performance possible.

First, is the Set Point Audit Trail. For each CIMPLICITY role, you may configure whether or not the user will generate an audit trail for each setpoint. The audit trail is composed of a $DOWNLOAD event containing information on who set the point. This information is sent to your event log and can provide a detailed audit trail of who and what was set. However, the audit trail imposes significant overhead (20 times slower), since the record is logged to the database for each setpoint. This is particularly noticeable when running setpoints in a loop in the Program Editor. However, when the script is run from the Basic Control Engine, a $DOWNLOAD event will not be generated since a resident process is trusted. If you do not require an audit trail is it recommended that you disable it through role configuration (this is the default).

Second, is the difference between a PointSet statement and using the Point Object. With a Point Object, you create the object once and initialize its point information once (data type, elements, etc.). Subsequent operations on the Point are very fast, since the point characteristics are contained in the object. Conversely, PointSet and PointRead must fetch the point information on each execution (in benchmark testing this is 2 times slower.)

Consider the following example :

' Example One

sub slow_set()

    for I = 0 to 100

       PointSet "MY_POINT", I

    next I

end sub

' Example two

sub fast_set

   Dim MyPoint as new Point

   MyPoint.Id = "MY_POINT"

   for I = 0 to 100

      MyPoint.SetValue = I

   next I

end sub

The subroutine fast_set ramps the point ten times faster than the slow_set routine. While the second example at first may appear more complex, you will find that the object interface provides much more flexibility. As a rule, use PointGet and PointSet when you need to read or set the point's value once within your script.

Polling

CIMPLICITY provides a high performance Point Interface. As a result, improperly written applications can degrade the overall performance of a system. One common issue is polling a point to wait for it to change. Consider the following example.

Incorrect Code

Poll:

  If PointGet("POLL_POINT") = 0 then

     Sleep 100

     Goto poll

  Endif

The sleep statement causes a 100ms delay between polls. However many extra polls are still being performed.

Correct and Most Efficient Code

Dim p as new point

p.Id = "POLL_POINT"

p.Onchange

Poll:

  Wait_for

     p.GetNext

     if p.Value=0 then goto wait for

In this example, the script requests the value of the point as it changes. When the point changes, the GetNext statement returns. When the point is not changing the script is waiting and using no system resources.

Error Handling

Basic provides a flexible error handling capability with the On Error command. The CIMPLICITY extensions to Basic are designed to use the built in error handling capability. When an error occurs while executing your CIMPLICITY command, a Basic Run Time error is generated. There are many ways you can implement error handling. Among these are :

No error handling. When an error occurs, the script's execution halts and the error is reported (in the Program Editor, this is via a Message Box, and in the control engine by logging an error message to the status log).

Error Handler. When an error occurs, the script's execution moves to the defined error handler. Within the error handler, the user can report the error or try to recover.

In line error checking. When an error occurs, the script's execution continues on the next program statement. The user can check the err variable to determine if an error occurred.

In the fast_set example above a run time error could be generated on the setting of the ID or the setting of the value. Since the routine provides no error handling, when an error occurs, the routine exits and returns to the calling routine. If no error handler is found as the program returns up the call stack, a default error handler reports the run-time error. If you run the script from the Program Editor, a dialog box opens, and if it is run from the Basic Control Engine, a Status Log message is created.

Consider the two examples below:

Sub inline_errorcheck()

   ' When an error occurs continue execution at the next statement

   on error resume next

   PointSet "BAD_POINT", 10

   ' Did an error occur?

   If err <> 0 then

      ' clear the error

      err = 0

      exit sub

   End if

   PointSet "BAD_POINT1", 10

   if err <> 0 then

       err = 0

       exit sub

   end if

end sub

sub outline_errorcheck()

   ' When an error occurs goto the error handler

   on error goto error_handler

   PointSet "BAD_POINT", 10

   PointSet "BAD_POINT1", 10

   exit sub

error_handler:

   MsgBox "Error"

   exit sub

end sub

You can choose how to handle or not handle error conditions.

CIMPLICITY Extensions to Basic