An interface fault results in an error that, as the name implies, occurs in the API layer between the system under development or in test, and the system simulation behind it. These types of faults might manifest as communications errors, such as corrupt data or no response. In other words, an interface fault occurs in between the instrumentation software and the simulated system. In the real system, errors in the interface might arise as a result of broken wires, corroded connections, a defective electronic component, or spurious noise.

Simulating interface faults typically involves things like disabling a communications channel or injecting random data into a channel. You can also simulate a fault in a piece of bus interface hardware (e.g., a plug-in I/O card), although this falls into that gray area I alluded to earlier and may be better dealt with as a system fault.

Figure 10-2 shows a diagram of an interface simulation with basic fault injection capabilities. Notice that the TxD (transmit) output from the instrumentation software to the instrument simulator doesn’t have a disable capability. This isn’t an oversight. If the instrument employs a command-response type of control interface, disabling the TxD link between it and the instrumentation software doesn’t really accomplish much. The instrument (or simulated instrument) should just sit and wait for a command, and it won’t have any way to detect whether the link is broken or not.

Figure 10-2. Interface fault injection

The path from the instrument to the instrumentation software is another matter. In this case, the instrumentation software should be able to detect when it has not received a response from the instrument and react in a predefined manner.

A reasonable question to ask at this point would be: why not just simulate the disabled communications in the instrument simulator, instead of using an interface simulation? The reason is that the instrument, or control system, may interact with some other component in the system that the instrumentation software can sense even if the primary link to the instrument is disabled. In other words, clever instrumentation software can sometimes get verification from another source (e.g., sensing a power state change) indicating that a correct command action has occurred, and thereby determine that the interface is the probable cause of the problem.

Figure 10-2 also indicates that both the TxD and RxD (receive) channels have noise injection capabilities. In the context of a communications channel that handles streams of ASCII characters, this could involve the injection of random characters to simulate line noise. Anyone who has ever had to use a modem to communicate with a remote computer system has mostly likely seen examples of line noise when the modem connects to or disconnects from the remote host.

Instrumentation software that is able to deal with corrupted data will most likely have the ability to retry an operation, or at least issue a query to determine whether a command was accepted correctly. It is also possible to determine where the noise occurred by examining the response from the instrument. If the instrument complains that it received an invalid command, the noise occurred on the TxD channel from the instrumentation software. If the response from the instrument is garbage, the noise is most likely in the RxD channel to the instrumentation software.

A system fault is something that arises from within the external system, or perhaps one of its subsystems (depending on the complexity of the system). The ability to simulate various system faults increases the value of the simulation, allowing you to exercise and verify the fault response of the instrumentation software while interfaced with the simulation.

A system fault can be any number of things, but in a simulator it usually comes down to a value in a table or the return code from a function. In other words, if the simulator would normally return an expected value in response to a particular input, simulating a fault is simply a matter of including some logic to return an invalid value or an error indication instead.

One approach is to directly inject the fault at the return point of a function or method in the simulation, as shown in Figure 10-3.

Figure 10-3. System-level fault injection

Assuming that ret_val in Figure 10-3 holds the nominal value that the function or method would normally return, setting simerr to True will result in the error return value (err_val) being passed back to the caller instead. The error value could be set via an accessor method, loaded from a fault table, or even entered manually from a user interface of some sort.

Another approach is to establish a fault condition using a module global variable or an object variable, as shown in Figure 10-4.

Figure 10-4. Simulator fault injection using object variables

In Figure 10-4, the class definition for SimObject has been designed to specifically expose key variables used by the methods in the class. In a simplistic scenario these would be read-only variables, set once at object instantiation and not modified by the class methods. It is possible to implement a lockout capability to prevent methods from modifying shared object variables, but that usually entails a level of complexity that’s not always necessary.

If you’re experienced with unit testing techniques, you might be thinking that all this sounds rather familiar, and you would be correct (we also discussed this in Chapter 8). In unit testing, a primary objective is to exercise all possible paths of execution to achieve complete statement coverage. If the unit under test has paths that can be executed only when an error occurs, the unit test environment must be able to set variables or coerce inputs to stimulate the appropriate error responses. A simulation that has fault injection capabilities does much the same thing, although for a somewhat different reason.

As a test environment, a simulator can be used to create fault scenarios that would otherwise be difficult (or even near impossible) to replicate with real hardware, at least not without the possibility of risking some serious (and expensive) physical damage. Simulation with fault injection allows you to observe the behavior of the control or data acquisition system you are building to see how it will respond to various error conditions and, if you have been following some requirements that define error responses, to determine whether it meets those requirements.

Although the DevSim API may look daunting, it’s mainly just a collection of accessor methods to set simulation parameters and return the current values. In its basic form, it doesn’t actually simulate any particular external device or system. That functionality is added by you, in the form of user-definable functions or additional software to meet project-specific needs.

Rather than list it all here (it’s almost 1,000 lines of code), I’m going to describe its internal structure, list the various methods available, show some highlights, and discuss how the simulator is used. You should have the source listing handy for reference, if possible.

Internally, DevSim is the most complex thing we’ve seen so far, but keep in mind that it’s mostly just data routing. Figure 10-6 is an IC data-sheet-style logic diagram for DevSim.

Data is buffered as it moves though DevSim, and each activity is synchronized so as to occur in a lock-step fashion. DevSim is also multithreaded: four threads handle cyclic functions (waveform generation), another four manage file input, and a ninth thread handles the simulator’s primary sequencing in a main loop.

Figure 10-6. DevSim internal logic

The DevSim class’s __init__() method presets the internal parameters to default values, and then calls the internal method __run() as its final action. The code for __run() follows:

#-----------------------------------------------------------------
# Simulator launch
#-----------------------------------------------------------------
def __run(self):
    """ Simulator start.

        Instantiates the main loop thread, sets up the cyclic and
        file I/O threads, and then waits for the start flag to go
        True. When the start flag becomes True the main loop
        thread is started.
    """
    # input thread object lists
    cycThread  = [None, None, None, None]
    fileThread = [None, None, None, None]

    simloop  = threading.Thread(target=self.__simLoop)

    # create the cyclic and file input handling threads,
    # four of each
    for inch in range(0,4):
        cycThread[inch]  = 
            threading.Thread(target=self.__cyclic, args=[inch])
        fileThread[inch] = 
            threading.Thread(target=self.__fileData, args=[inch])

        # start the cyclic and file I/O threads just created
        cycThread[inch].start()
        fileThread[inch].start()

    # wait for start signal then start the main thread
    wait_start = True
    while wait_start:
        if self.startSim == True:
            wait_start = False
        else:
            time.sleep(0.1)     # wait 100 ms
    simloop.start()             # start it up

First, the primary thread, simloop(), is created. Next, the eight input threads are instantiated in a pair of lists. As each thread is created, it is subsequently started. The __run() method then waits for a start signal, and finally starts the simloop() main thread.

The simulator is designed to start running when a Boolean variable (startSim) is set to True. You can set the various parameters before enabling the simulator, or they can be set “on the fly” while it is running. The simulation is stopped by setting the value of the Boolean object variable stopSim to True.

The four cyclic threads and the four file input threads each load data into a buffer when an “event” occurs. In the case of DevSim, an event is simply a flag variable that is set and reset to control activity; it is not a true event in the sense of a low-level message such as one would find in a GUI. Figure 10-7 shows how the threads are used to obtain input data and place it into buffers for eventual routing to the outputs. Notice that the __cyclic() threads can each select from one of five possible inputs: DC (constant value), sine wave, pulse (square wave), ramp, and sawtooth. The cyclic data is updated at a rate set by the parameter accessor setCyclicRate(), and each cyclic input may have a unique rate value. The cyclic inputs are very useful for generating a fixed DC-like value or periodic waveforms that the instrumentation software connected to the simulator can read and process.

Figure 10-7. Cyclic and file input threads

Using threads for the cyclic inputs allows them to run at different rates than the simulator’s main thread, and this in turns allows them to create waveform data at specific frequencies. If they weren’t implemented as threads they would generate changes in the simulated waveforms at the main loop rate of the simulator, which wouldn’t be suitable for a lot of situations. Allowing the cyclic data generators to run asynchronously is an example of timing decoupling. The buffers are necessary to capture the asynchronous data as it is generated.

The __fileData() threads are used to obtain data values from a file and pass them through to the instrument software under test. This feature allows you to replay a set of input data over and over again. It is useful when evaluating the instrumentation software under test against a known set of input values, to observe its behavior.

The main loop thread, shown next, is where all the data is collected and routed to the output buffers:

def __simLoop(self):
    """ Simulator main loop.

        The main loop continuously checks for input data (either
        from an external caller or from a cyclic source) for each
        input channel. If data is available it starts the
        processing chain that will ultimately result in the data
        appearing in the output buffers.

        The main loop runs forever as a thread. All externally
        supplied data is buffered, and all output data is buffered.
        When running in cyclic mode the output buffers will be
        overwritten with new data as it becomes available.
    """
    while self.stopSim != True:
        # scan through all four input channels, get available data
        for ichan in range(0, 4):
            if self.in_src[ichan] == DS.EXT_IN:
                indata = self.inbuffer[ichan]
            else:
                indata = __getCycData(ichan)

            # if a user-supplied function is defined, then apply
            # it to the data
            self.databuffer[ichan] = self.__doUserFunc(ichan, indata)

        # fetch file data (if configured to do so)
        self.__getFileData(ichan)

        # step through each output channel, move data as nesc
        for ochan in range(0,4):
            if (self.out_src[ochan] >= DS.INCHAN1) and 
               (self.out_src[ochan] <= DS.INCHAN4):
                outdata = self.databuffer[ochan]
            else:
                outdata = self.filebuffer[ochan]

            randdata = self.__getRandom()

            oscaled = self.__scaleData(outdata, self.outscale[ochan])
            rscaled = self.__scaleData(randdata, self.randscale[ochan])

            self.outbuffer[ochan] = oscaled + rscaled
            self.outavail[ochan] = True

        time.sleep(self.simtime)

Reading through the code for the __simloop() method is equivalent to following the data flow through Figure 10-6 from left to right. The first step is to get either externally supplied data (via the sendData() method, described in the following section), or from one of the cyclic data sources. Next the data is passed to a user-defined function, if one exists. It is then written to a buffer (databuffer).

If the data input is a file, the data is read from the file and stored in another buffer. Note that although a method is called, this doesn’t mean that anything will actually happen. An input method might be quiescent and therefore skipped internally, depending on how the simulator is configured.

Once the input data is in one of the two input buffers, it is read out and passed to the output. Along the way random data is obtained (for noise simulation), and the data is optionally scaled before it is summed with scaled random data. Finally, the data ends up in the output buffers for each channel.

The DevSim class contains 26 public methods and 15 internal methods. Most of the public methods are devoted to setting or retrieving internal parameter values. The public methods are described in the following lists.

Parameter accessor methods:

Simulator control and I/O methods:

Input/output methods:

For all its apparent complexity, the simulator really boils down to just two main methods: readData() and sendData(). Everything else just sets the stage for what will occur between the inputs and the outputs.

The following example code demonstrates the data flow from an input to an output in the simulator. It doesn’t use the optional user function, nor does it apply scaling or noise to the data:

#! /bin/python
# TestDevSim1.py
#
# Echos data written into the simulator back to the output.
#
# Source code from the book "Real World Instrumentation with Python"
# By J. M. Hughes, published by O'Reilly.

from    DevSim  import  DevSim
import  SimLib.RetCodes as RC
import  DevSimDefs as DS

def testDevSim1():
    simIO = DevSim.DevSim()

    # set up the simulated device
    simIO.setInputSrc(DS.INCHAN1, DS.EXT_IN)
    simIO.setOutputSrc(DS.OUTCHAN1, DS.INCHAN1)

    loopcount = 0
    while loopcount < 10:
        simIO.sendData(DS.INCHAN1, (5.0 + loopcount))
        print simIO.readData(DS.OUTCHAN1)
        loopcount += 1

    simIO.stopSim = True    # set the stop flag

Referring to the code and to Figure 10-6, the first points of interest are the setInputSrc() and setOutputSrc() statements. In both method calls, the first parameter identifies the input or output channel to use and the second parameter specifies where the data will come from. The first call states that the data for input channel 1 will be obtained from the channel 1 external input, which occurs when the sendData() method is called. In other words, it controls the “Input Channel Source Select” (the small two-input trapezoid symbol in Figure 10-6). The second method call (setOutputSrc()) determines where the data that will appear on output channel 1 will be obtained. In this case, the selection parameter governs the behavior of the eight-input source selector, and it specifies input channel 1. Note that input channel 1 could mean either a direct input from an external source, or one of the internal cyclic data sources. If we follow the data path in Figure 10-6 we see that it goes through the user function block in the input side, and then through a scaling block and a summing junction for random data (noise) on the output side. This example does not use any of those features, so it’s effectively a straight connection between the input and the output.

The second example uses a data file as the input to the simulator:

#! /bin/python
# TestDevSim2.py
#
# Reads data from an input file and passes the data to the output. A
# data file containing 10 values in ASCII form must exist in the
# current directory.
#
# Source code from the book "Real World Instrumentation with Python"
# By J. M. Hughes, published by O'Reilly.

from    DevSim  import  DevSim
import  SimLib.RetCodes as RC
import  DevSimDefs as DS

def testDevSim2():
    simIO = DevSim.DevSim()

    # define the source file to use
    rc = simIO.setDataFile(DS.SRCFILE1, None, "indata1.dat")
    if rc != RC.NO_ERR:
        print "Error opening input data file"
    else:
        # set up the simulated device
        simIO.setOutputSrc(DS.OUTCHAN1, DS.SRCFILE1)

        loopcount = 0
        while loopcount < 10:
            # read and print data from file
            print simIO.readData(DS.OUTCHAN1)
            loopcount += 1

    simIO.stopSim = True

The call to the method setDataFile() defines the data file that will be associated with the index SRCFILE1. Note that setDataFile() also opens the file, and will return an error value of OPEN_ERR if the open fails. In this simple example we’re not checking the value of the error code, except to determine whether it’s anything other than NO_ERR. The call to setOutputSrc() associates OUTCHAN1 with the data file. Whenever the readData() method is called, the file is accessed and a single entry is read. The data is then passed through the eight-input source selector (see Figure 10-6) to the output scaling and random data summing stages, and finally appears on the output. Calling readData() is, in effect, a trigger event for the internal data file read operation.

Since there is no scaling and no random data “noise” applied to the values from the input file, this is basically just a way to open and read a data file. However, it’s also a useful building block for creating a more complex simulation setup, as shown in Figure 10-8. Here, DevSim is used to read data from an input file, process the data by applying a user-defined function and scaling, and then drive some test code with the resulting stimulus. This is just one way that DevSim can be leveraged to provide enhanced test and simulation functionality.

Figure 10-8. DevSim usage example

DevSim incorporates the ability to insert a simple user-defined function into the input data stream just after the input source selector. A user-defined function is a string containing a valid Python statement. It is processed internally using Python’s built-in eval() method, and two predefined variables, x0 and x1, are provided. x0 is the current input data value, and x1 is the last current data value (a 1/z unit delay). You can actually do quite a bit with just these two variables. The result of the statement evaluation becomes the output to the eight-channel source selector. If the function string is empty, it is ignored.

For example, the statement x0 * 2 will multiply the input data by 2; it’s a simple scaling function. However, the statement (x0/(x0**2))+x1 is rather more interesting. It is an exponential expression, and given a linear series of input values (say, 0 to 10) it will generate an output that will produce a graph like the one shown in Figure 10-9.

The main restrictions on what you can do with a user-defined function are as follows:

Even with these restrictions there is quite a lot that can be accomplished with user-defined functions, including the simulation of physical characteristics such as inertial lag or a simple digital filter.

The following example shows how a user-defined function is used:

#! /bin/python
# TestDevSim3.py
#
# Demonstrates the use of a user-defined function string.
#
# Source code from the book "Real World Instrumentation with Python"
# By J. M. Hughes, published by O'Reilly.

from    DevSim  import  DevSim
import  SimLib.RetCodes as RC
import  DevSimDefs as DS

def testDevSim3():
    simIO = SimDev.SimDev()

    # set up the simulated device
    simIO.setInputSrc(SimDev.INCHAN1, SimDev.EXT_IN)
    simIO.setOutputSrc(SimDev.OUTCHAN1, SimDev.INCHAN1)
    simIO.setFunction(SimDev.INCHAN1, "x0 * 2")

    loopcount = 0
    while loopcount < 10:
        # send data to simulator
        simIO.sendData(SimDev.INCHAN1, loopcount)

        # acquire data input from simulator with function applied
        rc, simdata = simIO.readData(SimDev.OUTCHAN1)
        if rc != RC.NO_ERR:
            print "SimDev returned: %d on read" % rc
            break

        print "%d %f" % (loopcount, simdata)

        loopcount += 1
    # loop back for more

    simIO.stopSim = True

This example is just the 2x scaling function mentioned earlier.

Figure 10-9. Plot of (x0/(x0**2))+x1

The cyclic functions of the simulator provide a convenient source of predictable cyclic data. You have complete control over the wave shape and the timing, so you can, for example, set up a simulation using the pulse mode to evaluate the response of a control algorithm. The other cyclic functions might be used to simulate the velocity feedback from a mechanism, to simulate temperature change over time, or as a source of data to check limit sensing.

Because the cyclic functions have the ability to run in an asynchronous mode, you need to make sure that you don’t end up with a situation where the cyclic data is aliased because the data read rate is too slow, as shown in Figure 10-10. In this case, either the sample rate needs to be increased or the cyclic rate needs to be decreased so that the sample data read rate is no less than four times the cyclic rate.

Figure 10-10. Aliased cyclic data readout

Lastly, there is the random data injection that occurs just before the output. The relative range, or level, of both the data and the random “noise” are controllable. This allows you to set the balance between the two. Note that the random data is summed into the data stream, not simply injected. It won’t allow for the simulation of discrete transient events, but it does simulate modulation noise, such as might be found in a noisy voltage source (or a corroded connector).

This simulation models a hypothetical device called the Simple Power Controller (SPC). It doesn’t have some of the bells and whistles found on real units, such as password protection, controller unit ID assignment, and so on, mainly because these features aren’t really necessary to control power. It does, however, simulate the inclusion of electronic circuit breakers (ECBs) for each AC channel. These are similar to the power control devices found in aerospace applications. They protect each channel from an over-current condition and can be reset remotely if necessary.

A diagram of the hypothetical SPC controller is shown in Figure 10-11. As you can see, it’s rather simple electrically (most devices like this are, actually). The “smarts” of the unit are contained entirely within its microcontroller.

In Figure 10-11, the blocks labeled SSR are solid state relays, and the microcontroller could be any suitable device. Notice that the diagram does not show any front-panel controls, because the simulator won’t be concerned with them. The objective of the simulator is to emulate the functionality of the microcontroller in terms of the remote control interface. You are, of course, welcome to add a nice GUI if you wish (we’ll discuss user interfaces in Chapter 13).

Unlike the DevSim simulator with its API, the SPC simulator uses a serial interface. It’s a simple 9,800-baud N-8-1–type interface that is implemented using the pySerial library, which we will examine in detail in Chapter 11. For now we can assume that pySerial provides all the necessary functionality to open a serial port, set the serial port parameters, and read and write data.

There’s a catch to using a simulator that employs a serial interface, and that is interfacing with it. One way is to use two computers with a null-modem cable between them (as shown in Chapter 7), but a second computer is not always a viable option, and some machines don’t even have a serial port available (such as notebook and netbook PCs).

The solution is to use what are called “virtual ports” to create a link between two applications that utilize a serial interface. One such utility for the Windows environment is Vyacheslav Frolov’s com0com package. You can download it from http://com0com.sourceforge.net.

Figure 10-11. AC simulator block diagram

com0com works by creating a pair of virtual serial ports configured as a null-modem connection. You can assign standard names to the ports when they are created in order to accommodate applications that can only deal with names like COM1, COM2, COM3, and so on, and from an application’s perspective these ports will behave exactly like real physical interface ports. You can set the baud rate, query the status, and in general do just about anything that can be done with a normal serial port. Figure 10-12 shows how instrumentation software can communicate with a serial interface–type simulator using two virtual serial ports.

Linux users can instead use tty0tty, which is available from http://tty0tty.sourceforge.net. It’s rather minimal, and the documentation is somewhat thin, but the user-level version worked just fine for me on Ubuntu 10.04 after compilation.

Figure 10-12. Using com0com

There are basically two ways to interact with the SPC simulation: directly via a terminal emulator, or by way of instrumentation software. If you just want to manually exercise the simulator, you will need some way to send commands and view the responses. The tool of choice here is a terminal emulator. It doesn’t really matter what terminal emulator you use, so long as you can configure it to use the virtual serial ports that com0com (or tty0tty) creates.

On Windows 2000 and XP systems you can use the venerable Hyperterm or you may wish to check out Tera Term (which we’ll look at shortly), and on Linux the minicom emulator is available. If you are using Windows Vista or Windows 7, you will need to look around for a terminal emulator, but there are many available. When using a terminal emulator and virtual serial ports the setup will be basically the same as that shown in Figure 10-12, but with “Instrument Software” replaced by “Terminal Emulator.”

SPC utilizes 10 simple commands to control outputs, check status, and set configuration parameters. All commands are three characters in length, with no exceptions, and all commands take at least one parameter. The commands are listed in Table 10-2.

Here are a few general notes on the SPC commands:

Now, let’s take a closer look at the commands:

The SPC is a simple command-response-type device. It will never initiate communications with the host system. This means that it can be effectively simulated using a simple command recognizer. Also, since the SPC is a discrete state-based simulator, it needs a set of data to define the state of each of the power control channels. How and when a channel transitions from one mode to another is determined by the commands described in the previous section. Figure 10-13 shows the internal data that the SPC simulator needs in order to model a physical system.

Figure 10-13. SPC internal data

The sequence control data objects apply to all channels, and each channel has three attributes: power state (1 or 0), ECB state (1 or 0), and a current limit for the channel’s ECB.

Next up is the command recognizer, which is very simple:

    def Dispatch(self, instr):
        cmdstrs = instr.split()

        if len(cmdstrs) >= 2:
            if len(cmdstrs[0]) == 3:
                if cmdstrs[0].upper() == "ALL":
                    self.SetAll(cmdstrs)
                elif cmdstrs[0].upper() == "POW":
                    self.SetPower(cmdstrs)
                elif cmdstrs[0].upper() == "SEQ":
                    self.SetSeq(cmdstrs)
                elif cmdstrs[0].upper() == "STM":
                    self.SetSTM(cmdstrs)
                elif cmdstrs[0].upper() == "SOR":
                    self.SetOrder(cmdstrs)
                elif cmdstrs[0].upper() == "SEM":
                    self.SetSEM(cmdstrs)
                elif cmdstrs[0].upper() == "CHK":
                    self.ChkChan(cmdstrs)
                elif cmdstrs[0].upper() == "ECB":
                    self.ChkECB(cmdstrs)
                elif cmdstrs[0].upper() == "LIM":
                    self.SetLimit(cmdstrs)
                elif cmdstrs[0].upper() == "RST":
                    self.RstChan(cmdstrs)
                else:
                    SendResp("ER")
            else:
                SendResp("ER")
        else:
            SendResp("ER")

After a command is received, the method Dispatch() is called. The incoming string from the host system is split into a list, which should contain two or more elements. The first element should be the command keyword. The number of parameters after the keyword will vary depending on the command, but no command has zero parameters.

When the command is decoded, one of 10 utility methods is called to write data into the internal data table, get data from the table, and invoke the channel control to perform the commanded action (if it’s not just a status query). Notice that there is a command utility method for each command.

Figure 10-14 shows the message sequence chart (MSC) for a typical command-response interaction with the SPC simulator.

Figure 10-14. SPC command-response MSC

There are two possible return paths from the SPC command processor back to the host (the terminal emulator or instrumentation software), depending on the command. Some commands provide an immediate response and do not wait for the channel control logic to complete an activity. Other commands will wait and then return an indication of success or failure.

The SPC simulator uses a configuration file, also known as an “INI” file, to hold various configuration parameters that are read in at startup. Here is what spc.ini might look like:

[SPC]
SPORT=COM4
SBAUD=9600
SDATA=8
SPAR=N
SSTOP=1
ECB1=2.5
ECB2=2.5
ECB3=5.0
SOR=[3,2,1,4,5,8,7,8,6]
STM=2.0
SEM=0

The values from the INI file will be loaded into the internal data table, but they may be overwritten with new values using the SPC commands. Parameters not defined in the INI file will assume their default values.

When the SPC simulator is started, it will first attempt to open the serial port defined in the INI file. If successful, it will start its primary loop and wait for incoming commands. When the SPC receives a carriage return (CR) and nothing else, it will return the prompt character (>). Here’s an example session that enables power channel 1:

> CHK 0
[0, 0, 0, 0, 0, 0, 0, 0]
> POW 1, 1
1
> CHK 0
[1, 0, 0, 0, 0, 0, 0, 0]

To use the SPC simulator with instrument software, the first step is to get the SPC’s attention. Something like the following code snippet should suffice (we’ll assume that a serial port is already open and referenced by the sport object):

gotprompt = False
last_time = time.time()
MAXWAIT = 5.0

while True:
    sport.write("
")
    instr = sport.read(2)
    if instr=="> ":
        gotprompt = True
        break
    if time.time() - last_time > MAXWAIT:
        break
    time.sleep(0.5)

This snippet will send a carriage return character every 500 milliseconds until the SPC responds or five seconds has elapsed, whichever comes first. When the SPC responds with a prompt, it exits the loop, and the system is ready to communicate.

Using the SPC as a framework, you can create a simulator for just about any simple device or instrument with a serial control interface. The SPC simulator also shows how a simulation can be used to evaluate a device or instrument that does not (yet) exist in the real world. There is no substitute for working with a live system, be it real or simulated, to get a feeling for what it can, and cannot, do.

I will assume that Linux users will install gnuplot using a package manager, so I won’t describe the process here. This procedure applies only to Windows users.

If installing the support packages for the first time, perform the setup in the following order:

The gnuplot package for Windows contains the following executable files:

wgnuplot is what you would typically put on the Windows desktop as an icon, and gnuplot is what a Python program would open when creating a pipe.

If you want to be able to use a pipe to send commands to gnuplot running under Windows, you must use the gnuplot version, not wgnuplot. This is because Windows GUI applications (such as wgnuplot) do not accept input from stdin. You can tell Python to use gnuplot when creating the pipe using popen(). Alternatively, you can use pgnuplot to achieve the same results with wgnuplot. On a Linux system this is not an issue (there are no wgnuplot or pgnuplot binaries).

The following example, gptest.py, will launch gnuplot and display a series of plots:

#! /usr/bin/python
# gptest.py

import os
import time

f=os.popen('gnuplot', 'w')

print >> f, 'set title "Simple plot demo" 1, 1 font "arial, 11"'
print >> f, 'set key font "arial, 9"'
print >> f, 'set tics font "arial, 8"'

print >> f, "set yrange[-20:+20]"
print >> f, "set xrange[-10:+10]"
print >> f, 'set xlabel "Input" font "arial,11"'
print >> f, 'set ylabel "Output" font "arial,11"'

for n in range(100):
    # plot sine output with zero line (the 0 term)
    print >> f, 'plot sin(x * %i) * 10, 0' % (n)
    time.sleep(0.1)

f.flush()

# pause before exit
time.sleep(2)

To run this example, just save the code to a file (gptest.py, for example) or load the file from the source code for this book. On a Windows machine, type in the following at a command prompt:

python gptest.py

Under Linux you can just enter the script’s name, assuming that the file is marked as executable and the Python interpreter resides in /usr/bin:

% gptest.py

When it runs, you should see a sine wave that expands and contracts several times. What is actually happening is that gnuplot is regenerating the plot across the x range of −10 to +10 each time the plot command is called. The result appears as an animated image, but in fact it is a series of plots presented in rapid succession. Note that the gnuplot window will close as soon as the script completes and Python terminates.

The following lines from the Method 1 example are possible candidates for inclusion into the gnuplot.ini file, which should be located in the binary directory with the gnuplot executables:

set key font "arial, 9"
set tics font "arial, 8"

Refer to the gnuplot documentation for more about the gnuplot.ini file and its uses.

The second method uses Michael Haggerty’s gnuplot.py package (version 1.8), which is available from http://gnuplot-py.sourceforge.net. You will also need the NumPy package (version 1.4.1), available from http://numpy.scipy.org. For Windows, you should download and install numpy-1.4.1-win32-superpack-python26.exe (just execute the file to start the installation).

To install gnuplot.py, follow these steps:

During the execution of the setup script, you should see many lines of output go by on the screen. If an error is encountered, the setup script will halt; otherwise, you should now be ready to go.

In the directory <python>Libsite-packagesGnuplot run the file demo.py, like so:

python demo.py

<python> is where you installed Python 2.6, and on a Windows system it may be something like C:Python2.6.

If all goes well, you’ll see a plot display. Pressing the Enter key from within the command window will cause a series of graphs to be displayed.

gnuplot.py is somewhat unusual in terms of how it is imported into your application. If you look at demo.py, you’ll see that it is importing Gnuplot and Gnuplot.funcutils. But there is no “Gnuplot.py” in the Gnuplot directory where the package resides. What is happening here is that the package initializer, __init__.py, is imported. It, in turn, imports the rest of the necessary modules. The __init__.py module also contains a top-level docstring with lots of information. If you examine __init__.py you may also notice that it contains the following code at the bottom of the file:

if __name__ == '__main__':
    import demo
    demo.demo()

What this means is that you can type in:

python __init__.py

from the Gnuplot directory, and the demo will execute.

This approach is interesting in that when the gnuplot.py package is imported the __init__.py module will be evaluated immediately, and the necessary imports will be in place and available from that point onward in your application.

To import gnuplot.py into your application, you must at least import the main module:

import Gnuplot

You can import additional modules using dot notation, like so:

import Gnuplot.funcutils