Point (subject)

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. 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
  End If
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.