Camera Object Events Introduction

CCDSoft's scripting model is now even more powerful with the introduction of Camera Object Events.

What is an Event?

From the scripting stand point, an event marks a point in an internal (usually complex) process. For example, during CCDSoft's Take Image process, the Before Download event (cdBeforeDownload) occurs immediately before an image is downloaded from the camera and just after the camera has finished exposing the CCD detector. CCDSoft's event model allows your source code to be called (or notified) when a specific event occurs.

Why Use Events?

Events give the software developer the ability to "surgically" splice into CCDSoft's camera kernel at discrete, opportune and well-defined instances to extend, enhance or alter CCDSoft's default behavior. There's no need to "reinvent the wheel" when you can insert your own code (or logic) into CCDSoft’s well established camera control methods.

Here is a sample script that illustrates how to respond to the cdGuideError Event.

'The second argument to CreateObject registers event callbacks

Set Camera = WScript.CreateObject("CCDSoft.Camera", "EVENT_")

'Connect to the camera

Camera.Connect

'Begin Autoguiding

Camera.Autoguide

'This is the event call back

Sub EVENT_CameraEvent(EventId, lWhichCCD, lpszValue, lParam1, lParam2)

if (EventId = cdGuideError) then

MonitorGuideError()

End if

'Respond to other events here...

End Sub

Camera Event Plug Ins

Events are typically fired and accessible while an application is controlled through an external script.  However, through CCDSoft's Camera Event Plug Ins, responses to events can become permanent features to CCDSoft.

A Camera Event Plug In is source code (written by any software developer) that is called by CCDSoft for whatever event the Camera Event Plug In has requested. For example, there is now a "guide error event" that is fired whenever CCDSoft is autoguiding and a guide error exists. Programmers can then take actions in response to the event, perhaps instruct CCDSoft to ignore the guide error  because it has been determined programmatically that the guide error is due to a cosmic ray hit or even make the guide correction in the event itself. With just a few lines of code, third-party developers can be at the core of CCDSoft's autoguiding routine and they can choose how to respond.

Camera Event Plug Ins allow developers to efficiently, easily and permanently (if desired) extend and enhance CCDSoft's core functionality. This functionality when implemented as a Camera Event Plug In becomes part of CCDSoft's core camera functionality whether CCDSoft is being used interactively (point and click) or when CCDSoft is being driven through automation (like an external Visual Basic Script, Orchestrate, etc.).

Don't Call Us, We'll Call You

Without events, it is impossible to reliably synchronize two separate processes.  Others have attempted to emulate events through client polling.

For example, if your script wants to monitor the guide error that is being computed by a external autoguiding process, the script must continuously poll the state of a variable in the autoguiding process. The two processes (script and the autoguiding process) are not synchronized. Therefore, if the autoguiding process updates the guide error at a rate higher than the what the script can monitor, then the script will miss valuable data. That is, via polling, there is no rigorous, closed loop way to monitor the guide error.

Polling Deficiencies

• Polling is open loop.

• Polling is limited to the frequency (rate) of the polling process, if the rate is insufficiently frequent, a script may not be able to determine when the event occurs, or, more egregiously, miss the event entirely.

• Polling can be inefficient and waste CPU cycles.

Events, on the other hand, are by nature synchronized. In the above example, using events rather than polling, the script is notified immediately when an event occurs. There is no uncertainty about if or when the event takes place.