|
Charles and Douglas present an ActiveX control which enables real-time computer control of external devices and sensors of various kinds in automated control applications. The control is written in C++, while the control system is built using the Lego Dacta Control Lab.
February 01, 1998
URL:http://www.drdobbs.com/embedded-systems/an-activex-control-for-real-time-compute/184410492
Charles holds a B.S. from Miami University. Douglas is a professor of systems analysis at Miami University in Oxford, Ohio. They can be contacted at charlie.huddleston@ usa.net and [email protected], respectively.
In this article, we present an ActiveX control, written in C++, which allows real-time computer control of external devices and various sensors in automated control applications. The ActiveX control (available electronically; see "Resource Center," page 3) hides the details of the communication protocol, allowing you to concentrate on the requirements of the specific application. The control can be embedded into any ActiveX container, such as Visual Basic or Internet Explorer, providing flexibility in your choice of programming environment. The control also illustrates the use of serial I/O, multithreading, and timers within an ActiveX control. To illustrate the control, we'll provide an application that uses the control with Visual Basic and JavaScript in a web page. Surprisingly, the motors, lamps, sound elements, and sensors are part of the Lego Dacta Control Lab, a sophisticated set of Legos and devices that can be controlled from a PC or Macintosh.
In addition to the familiar building sets seen on toy shelves, Lego Dacta provides building sets for a range of machines used in science and technology education. At the low end are the Lego technic sets; at the high end is the Lego Dacta Control Lab, which enables construction of computer-controlled machines. Among the type of control systems you can build with the Control Lab are greenhouses that automatically regulate their temperature using a ventilation system, a vending machine, robotic arms, a PC plotter, and an automobile on a dynamometer (see Figure 1). Sophisticated simulations of real-world systems have also been created, such as an automobile manufacturing production line (http://www.gang.umass.edu/user/shen/lego/index.html) and a variety of robots (http://www.pycckuu.umd.edu/robots/ index.html). The Fischertechnik Corp. produces a product similar to the Legos that have also been used in teaching environments (http://www.cs.utah.edu/~cs451/).
In addition to the usual set of Lego blocks, the Control Lab includes pieces from the technic sets for building machines (gears, pneumatics, pulleys, and so on) and computer-controllable devices -- lamps, motors, sound elements, touch sensors, temperature sensors, light sensors, and angle sensors. The devices are connected to a controller, which in turn interfaces with a serial port on a personal computer to permit software control of the devices. The controller is capable of controlling eight input and eight output devices. The PC and the controller communicate via a protocol developed by Lego.
The Lego devices (motors, sensors, and the like) can be combined to build sophisticated machines, such as the automobile on a dynamometer (Figure 1) or the simulated manufacturing line. Software, written on a PC or Macintosh, controls the interaction of the Lego devices.
Lego ships the Control Lab with a unique version of the Logo programming language for writing the control software for a Lego system. Although satisfactory for illustrating programming concepts, more sophisticated users may wish to use other programming languages for control purposes. (For more information on Logo, see "Lego/Logo and Electronic Bricks: Creating a Scienceland for Children," by Fred Martin and Mitchel Resnick, Advanced Educational Technologies for Mathematics and Science, edited by David L. Ferguson, Springer-Verlag, 1993.)
We initially selected the Control Lab for use as a teaching environment for introductory object-oriented programming classes at Miami University. Students could write software objects corresponding to the real Lego devices, then combine these objects to control a system built with Legos.
Although object-oriented programming is well suited for creating software objects that correspond to the Lego devices, considerable programming is required to support the Lego controller's communication protocol. The protocol operates over the serial port of a PC, requiring the software to send messages to the Lego controller to turn devices on or off, control speeds, and receive messages from the controller indicating changes in the status of sensors. A further complication of the protocol is the requirement that "alive" messages must be sent to the controller at established intervals.
To illustrate the concepts of object-oriented programming, we did not want students to become bogged down in the details of the communication protocol. As a first attempt at hiding the details of the protocol, we developed a class library that supported the transmission of messages between the PC and the controller, and handling the alive messages. The usefulness of the resulting software is limited insofar:
Given these shortcomings, we decided to create a software component that would allow programmers to control the Lego system, but would also completely encapsulate the serial communication routines and allow the use of a variety of host programming languages.
We decided to use Microsoft's ActiveX component model for this project because it would allow users to control the Legos from various language environments, including Visual Basic, VBScript, JavaScript in Internet Explorer, C++, or any other ActiveX-capable language.
The Lego controller in Figure 1 is the interface between the PC's serial port and the Lego devices. The controller has eight output ports (labeled A through H) and eight input ports (labeled 1 through 8) for connecting Lego devices to the system.
There are three kinds of devices that can be connected to the eight output ports -- a motor, lamp, and sound device. Commands can be sent to these devices by writing a two-byte command to the Lego controller via the serial port. The first byte is a binary command code (see Table 1). The second byte specifies to which output port the command applies. If the least significant bit is 1, then the command applies to port A, if the most significant bit is 1, then it applies to port H, and so on. Table 1 shows the commands available for the output ports and the effects they have on each kind of output device.
There are four kinds of devices that can be connected to the input ports -- an on/off switch, thermometer, angle sensor, and light sensor. Input from the eight input ports comes in the form of 19-byte frames constantly being sent several times per second from the controller into the serial port. Table 2 shows the contents of each frame.
The sum of the values of the 19 bytes must add up to 0xFF; otherwise, an error has occurred in communication. The interpretation of the two-byte status code corresponding to a port in each frame depends upon the kind of device connected to the port. It is impossible to know, from the input, exactly what kind of device is attached to a certain port. Thus, the software must process the data from each port for each kind of input device. The interpretation of the two-byte status codes for each device is:
To start communication with the Lego controller, the software must send the string p\0###Do you byte, when I knock?$$$, then wait until it receives the reply string ###Just a bit off the block!$$$.
To maintain the connection with the controller, whenever commands are not being sent, the software must send the value 0x02 every two seconds.
The Lego ActiveX control is implemented using two threads of execution. Multiple threads were used so that processing of method calls and reading from the serial port could be performed concurrently.
The primary thread executes the control's standard message-handling program loop. It receives messages from the host language and executes the appropriate handler functions. From this thread, all write operations to the Lego controller are performed. This thread also establishes a timer function called by the operating system every two seconds to write the "alive" message to the controller.
The primary thread starts the second thread when the connection is made with the controller. It is used to read the frames of information from the controller and dispatch messages to the primary thread when the states of the Lego devices change. It should be noted that, because of the way ActiveX controls interface with their containers, it is not possible for this second thread to fire events to the host language directly (see "FIREEV.EXE Fires Events from a Second Thread," Knowledgebase Article ID: Q157437, Microsoft Corp. 1997). Instead, the secondary thread must send a message to the primary thread, which can then fire a Windows event in the host program.
Figure 2 illustrates the design of the control and its relationship to the host language.
The following methods were implemented in the control and can be called from a host language.
The control has one property that can be accessed and changed by a host language: A string named SerialPort. SerialPort's value specifies the COM port (1 or 2) to which the Lego controller is connected. This value is stored in the Windows 95/NT system registry.
Events are fired by the control to the host language (Figure 3 shows the availability of the events using Visual Basic 4.0) when a change in the value is received from an input port. The following events are generated by the Lego control.
We developed the control using Microsoft Visual C++ 4.0. The OLE Control Wizard was used to generate the skeleton control and ClassWizard was then used to add the methods, properties, and events. We then added code to make the control multithreaded and the timer function necessary to send "alive" messages.
Figure 4 shows an application written in Visual Basic 4.0 that demonstrates all the features of the Lego ActiveX control. The procedures in Listing One are used when buttons on the form are pressed to call methods of the Lego control.
Listing Two is an HTML document with the embedded Lego ActiveX Control and JavaScript automation. This application turns on a motor whenever a button is pressed, and uses an angle sensor to determine the speed of the motor. Users select which ports the devices are connected to by filling in HTML form fields. ActiveX controls can easily be inserted into HTML documents using Microsoft ActiveX Control Pad.
COM and ActiveX provide an easy way to create modular programs in which the details of a complex task are hidden from application programmers. This is a powerful ability and will lead to more software comprised of components combined in specific ways to accomplish certain tasks. In the case of the Lego project, programmers using the control need not know how to open a serial port, create threads for reading, or send "alive" messages every two seconds. In fact, they don't even need to know that those things are going on behind the scenes. Instead, all they need to worry about is their specific application's requirements.
Much of the Lego serial protocol is based on research by Andrew Carol ([email protected]). This project builds upon work completed at Miami University in 1996 by a group comprised of Brian Franke, Shelly Kerschner, Julie Lawrence, Afshin Nasirian, and Charlie Huddleston. This group wrote the object-oriented framework and skeleton program that would allow programmers to write programs that interface with the Lego Controller.
DDJ
Private Sub StartButton_Click() Call Lego1.StartLegos
End Sub
Private Sub StopButton_Click()
Call Lego1.StopLegos
End Sub
Private Sub OnButton_Click()
Call Lego1.TurnOn(port)
End Sub
Private Sub OffButton_Click()
Call Lego1.TurnOff(port)
End Sub
Private Sub DirectionButton_Click()
Dim d As Boolean
If Direction = 1 Then d = True Else d = False
Call Lego1.SetDirection(port, d)
End Sub
Private Sub ReverseButton_Click()
Call Lego1.Reverse(port)
End Sub
Private Sub PowerButton_Click()
Call Lego1.SetPower(port, Power)
End Sub
The following procedures handle events fired by the Lego Control:
Private Sub Lego1_OnPress(ByVal port As Integer)
Press(port).Value = 1
End Sub
Private Sub Lego1_OnRelease(ByVal port As Integer)
Press(port).Value = 0
End Sub
Private Sub Lego1_OnTemperatureChange(ByVal port As Integer, ByVal
temperature As Double)
Temp(port) = temperature
End Sub
Private Sub Lego1_OnAngleChange(ByVal port As Integer,
ByVal angle As Integer)
AngleBox(port) = angle
End Sub
<HEAD><TITLE>HTML JavaScript Example</TITLE></HEAD><BODY>
<SCRIPT LANGUAGE="JavaScript" FOR="Lego1" EVENT="OnPress(port)">
<!--
if(port==Document.Form1.SwitchPort.value)
{
Lego1.TurnOn(Document.Form1.MotorPort.value)
}
-->
</SCRIPT>
<SCRIPT LANGUAGE="JavaScript" FOR="Lego1" EVENT="OnRelease(port)">
<!--
if(port==Document.Form1.SwitchPort.value)
{
Lego1.TurnOff(Document.Form1.MotorPort.value)
}
-->
</SCRIPT>
<SCRIPT LANGUAGE="JavaScript" FOR="Lego1" EVENT="OnAngleChange(port, angle)">
<!--
if(port==Document.Form1.AnglePort.value)
{
Lego1.SetPower(Document.Form1.MotorPort.value, (angle+2)/2)
}
-->
</SCRIPT>
<OBJECT ID="Lego1" WIDTH=49 HEIGHT=51
CLASSID="CLSID:93B2A113-8FF2-11D0-8606-00A0246926AB"
CODEBASE="Lego.ocx">
<PARAM NAME="_Version" VALUE="65536">
<PARAM NAME="_ExtentX" VALUE="1291">
<PARAM NAME="_ExtentY" VALUE="1323">
<PARAM NAME="_StockProps" VALUE="0">
</OBJECT>
<FORM NAME="Form1">
<INPUT LANGUAGE="JavaScript" TYPE=BUTTON VALUE="Start" ONCLICK="Lego1.StartLegos()"
NAME="StartButton">
<INPUT LANGUAGE="JavaScript" TYPE=BUTTON VALUE="Stop" ONCLICK="Lego1.StopLegos()"
NAME="StopButton"><BR>
Motor Port: <INPUT VALUE="1" SIZE=1 NAME="MotorPort" MAXLENGTH="1"><BR>
Angle Sensor Port: <INPUT VALUE="7" SIZE=1 NAME="AnglePort" MAXLENGTH="1"><BR>
Switch Port: <INPUT VALUE="4" SIZE=1 NAME="SwitchPort" MAXLENGTH="1">
</FORM>
</BODY></HTML>