NO NO NO NO NO NO NO NO NO NO NO NO!

This is like embarking on a journey armed with unclear directions, no map or compass, and a vague idea of your destination.

We don't suggest you go down this road, since death and pestilence will be your traveling companions.

There are a few hidden components that most systems will need. For example, for this ATE there is no mention of the display and how it should look. A phone call confirms that the customer would like to see the test status and unit details on a screen.

We can also have a look at the hardware design to swipe a few ready-made components. For example, there is a digital multimeter (DMM) for taking the measurements, a Switching System for making the connections, and a PSU (power supply unit) for providing power. Now you can try to disregard repeats and obvious components that are outside the system.

So, let's go through our list and collate what we have identified into a smaller set of nouns, deleting those that we don't need:

From our table we can see that some nouns have been discarded, but others have been replaced with (we think) a more meaningful description—Display.

Customer test specification and test specification are obviously referring to the same thing, so drop customer test specification because the system will not care who owns the specs.

There's also an argument that test position and active test position are similar enough to be ignored. Active could be an attribute of test position perhaps.

All right, our next job is to group the nouns under a heading.

We have grouped each of our nouns under a heading that collectively describes it. This should be our starting point for the highest level components. More than one design can solve a problem, and you could have dissected the nouns differently and still come up with a decent design. For our example though, we have decided that our table headings now represent the main components in our system.

Putting it all together we will have a display that is populated by readings taken from the test system component. This test system will consist of a hardware component that will model all the states of the hardware. The hardware component will be responsible for talking to the serial communications, the DMM, and the visual inspection system. The results will be stored by a data component and printed by the report component. The component interaction diagram will look like Figure 9.2.

Figure 9.2. Widgetometer top-level component interaction diagram.

Now at the top level we can define the actions for each component.

In LabVIEW, building a prototype is not necessarily expensive, and if you use patterns you can use the prototype as the basis for your main program. The idea of a prototype is to emulate the look and feel of how you envision the program working. Therefore, the User Interface should be functional to the extent that buttons can be pressed and data displayed. There shouldn't be any connections to the hardware at this stage. You shouldn't spend much more than one to two days putting the prototype together.

Another small bit of advice given to us by an ISO9000 auditor is “always feed them something,” by this we mean deliberately leave something out or leave an obvious gap. In the auditor's case it was a ploy used by those being audited to distract. In our case we can use it to generate customer involvement, or to get customer “buy in” and start the conversion. We have found that people begin to accept the design more readily if they feel that they have contributed to it in some way. We should try to animate each step in the program—remember it is a demonstrator for the customer.

From the requirements document it was established that there would be five test positions. This was the limit of what could be displayed completely on the screen, without having to resort to summary screens. A Strict Type Def. cluster was created that held all the data for each unit under test. Copies of this cluster were distributed around the screen and titled Position 1–Position 5. Using a Strict Type Def. cluster will allow you to make changes to all of the clusters at the same time. The central area was allocated for instructions and test details and is just a plain string. Finally, the [Exit] button was left as is and [Button2] was renamed [Start Test].

Before we go on to actually emulating the running of the test, let's look at what basic actions we require from the User Interface.

User Interface Basic Actions

Following are the User Interface Actions that came with the pattern:

Button 1 is the [Exit] button for our User Interface and the action should be updated to reflect this. Button 2 is the Start/Stop Test Button and, as well as renaming the button, we need further action to change the button text. Button 3 needs the visible-invisible actions.

We need to list new actions for the position clusters—these will be update, enable, disable, visible, and invisible. We should leave the UnderRange, OverRange, Get Display, and Clear Queue actions alone since they are always used.

The new User Interface Actions will need to be put into the Display Command.ctl and the Display Setting.ctl. Just open, edit, and save each control.

Create a Strict Type Def. enumerated control that models the test position, and its values should be:

Save it as Test Position.ctl and use it everywhere.

The UI queue component will have the Test Position.ctl as both input and output, and it will also pass it as part of the message queue. The adjustments to the UI queue component are relatively straightforward.

The result should be something like Figure 9.4.

Figure 9.4. UI queue component panel and connector.

The cluster constants seen in the diagram in Figure 9.5 are instances of the Strict Type Def Queue Items.ctl, and any changes to it are reflected in changes to the diagram.

Figure 9.5. UI queue component diagram.

Figure 9.6 shows the UI controller component that acts as a wrapper for the UI queue component. Once again we'll need to add the Test Position.ctl as both input and output and wire them to the connector. If you open up the diagram, you'll notice that the source has changed to reflect the new values for the instances of Display Setting.ctl and Display Command.ctl. Spooky!

Figure 9.6. UI controller component panel and connector.

The Test Position.ctl will need wiring into and out of the case structure and connecting to the UI queue component where required. In this case it is only required as an output from the Get Display>>More Items?=True case. See Figure 9.7 for the wiring diagrams.

Figure 9.7. UI controller component diagrams.

Now we need to add the new cases to correspond to the elements in Display Command.ctl. This is a simple matter of selecting a suitable case and right-clicking and selecting Duplicate Case from the pop-up menu as shown in Figure 9.8.

Figure 9.8. Duplicating a case.

The new case will automatically take on the name of the next element in Display Command.ctl, which in this case is “Enable Position.” This case needs to be aware of the test position, so it will need Test Position wiring into the UI queue component. See Figure 9.9 for wiring of additional cases.

Figure 9.9. Additional cases for UI controller.

Finally, we need to make each action work! Look at the Control Display While Loop on the Widgetometer Test System block diagram in Figure 9.10. Right-click on the case structure and select Add Case for Every Value. Now you have a set of pigeonholes awaiting their actions. All of these actions are simple attribute settings, except for Update Position, and we'll tackle that later.

Figure 9.10. Control Display While Loop.

Here's the code for the Control Display While Loop as shown in Figure 9.10.

Figure 9.11 shows examples of the cases filled out. You will need a case for every action.

Figure 9.11. Control Display cases.

Now if you load a Test Stub VI called UI Display Stub.vi, and run the Widgetometer User Interface, you will be able to test the changes that have been made. The UI Display Stub.vi simply places messages on the message queue, and these are actioned by the User Interface. Now we are ready to give the prototype some life.

On starting, the program will settle into its first state: Test Not Started. When the start button is pressed, the Enter Data state is activated. After successfully entering data, the Testing state is started and the sequence of tests are run through. When the tests are done, the Tests Complete state is entered and any posttest actions finished.

A flexible approach is to produce a simple component that drives the program executive states. Figure 9.12 demonstrates how.

Figure 9.12. Program Executive State Controller.

This component stores the required program executive state locally, by the “Set Test State” command, and returns it once on a “Get Test State” command. All we need to do now is have a loop checking the Test State and acting when it changes, and we have ourselves a nice, flexible program executive. We'll add the loop to the Widgetometer User Interface VI and put in some functionality, or the “Enter Data State.” A simple Enter Data dialog box was created, and if you notice the Monitor Control Buttons loop on the diagram in Figure 9.13, you'll be able to see that when button 2 [Start Stop Test] is pressed, the Test State is set to Enter Data. When the Program Executive loop next iterates, it will retrieve that state and action it.

Figure 9.13. Program Executive Enter Data State.

Inside the Enter Data dialog will be the code that decides what step to go to when the dialog exits. If it exits on a Cancel the next state should be to return to Test Not Started. If the dialog exits successfully then the next state would be Testing. In a similar fashion to decoupling the User Interface actions from the front panel, we've now decoupled the Program Executive actions. We now have the freedom to control the way the Test Sequence runs from nearly anywhere in the software hierarchy.

Looking closer at the hardware pattern, we've already defined the top-level commands for the component, so now we'll go deeper. Each hardware action is a combination of Control, Drive, and Read. There may be no need for all of them, but at least one will be required. For instance, a simple thermometer would only have the Read component, whereas a scanning thermometer would have a combination of Control and Read.

Here's the implementation for this project and a reminder of the actions for this component.

Hardware Actions

It transpires that the power is switched on to all the units at the start of the test and removed at the conclusion of testing. This means that two extra hardware actions are required to apply and remove power to the units.

So, here are highlights from the source code.

Action	Description
UnderRange	Throws or passes error
Initialize System	Sets up all the hardware components
Switch STDs In	Connects the standard units to the selected test position
Reset Switches	Clear connections
Read Unit Status	Read the selected unit's Status from the serial port
Read Unit Serial Number	Read the selected unit's Serial Number from the serial port
Read Unit Part Number	Read the selected unit's Part Number from the serial port
Read Unit Software Version	Read the selected unit's Software Version from the serial port
Read Chan1 Reading	Read the selected unit's reading for channel 1 from the serial port
Read Chan2 Reading	Read the selected unit's reading for channel 2 from the serial port
Get Chan1 An Out	Measure the selected unit's channel 1 analog output
Get Chan2 An Out	Measure the selected unit's channel 2 analog output
Get Chan1 Display Reading	Get the display reading for channel 1
Get Chan2 Display Reading	Get the display reading for channel 2
Power On	Apply power supply to units under test
Power Off	Remove power supply from units under test
OverRange	As UnderRange

Looking at Figure 9.14 you can see that Test Position is a Strict Type Def. enumerated type that has already been defined for the prototype and is used throughout the software. Hardware Actions is a new Strict Type Def. enumerated type that has all the actions that were defined earlier.

Figure 9.14. Hardware component front panel.

Hardware Actions has been set to “required” as a precondition, and a standard wiring pattern has been defined, as shown in Figure 9.15 and 9.16. All components will follow this pattern where possible.

Figure 9.15. Widgetometer hardware icon.

Figure 9.16. Standard wiring pattern.

The block diagram looks like that shown in Figures 9.17. The first time through the hardware is initialized.

Figure 9.17. Hardware component block diagram.

The UI screen control is sent a message describing each action that has been taken by the hardware component. The hardware action is then implemented. The actions that talk to the serial ports are all pretty repetitive and involve sending the message and the unit position for that message to the read component. This will then do all the communicating and return a string or numeric value. The measure action is a bit more involved; it requires a bit of switching to select the unit under test.

Clearly demonstrated here is the self-documenting nature of LCOD—you can see exactly what each component is being asked to do.

Programming the Get Chan2 An Out action was simply a matter of duplicating the Get Chan1 An Out case and changing the command to the control component as shown in Figure 9.18. The Power On and Power Off commands use the drive component and simply set the power supply volts to 24 or 0 as shown in Figure 9.19.

Figure 9.18. Get Chan 1,2 An Out.

Figure 9.19. Power On/Off.

The hierarchy in Figure 9.20 shows the Control>>Drive>>Read pattern. Below the generic Switch, DMM, and PSU components would be the manufacturers or your own drivers. For continuity we tend to rewrite them as components as well.

Figure 9.20. Widgetometer Control Drive Read pattern.

Control Actions

It is envisioned that the measurement and signal lines are switched from the units under test to the computer and measurement equipment.

Action	Description
UnderRange	Throws or passes error
Init Control System	This initializes the control hardware, getting and setting identifiers and setting initial conditions
Reset Switches	Set all switches open
Switch Standards In	Switches the standards into the chosen position
Switch DMM to Chan1	Switches the DMM to channel 1 of the chosen position
Switch DMM to Chan2	Switches the DMM to channel 2 of the chosen position
OverRange	As UnderRange

Here's the implementation.

So regarding Figure 9.21 we will define Control Commands as a Strict Type Def. enumerated type and use Test Position as in the hardware component.

Figure 9.21. Control component front panel.

As we go to lower levels of abstraction we can see the commands becoming more oriented to the hardware. This is demonstrated by the states in Figures 9.22 and 9.23 that are now less identifiable as part of a test system and more specific to switching systems.

Figure 9.22. Control Component Initialize State.

Figure 9.23. Control component switching commands.

Drive Actions

Drive is used for signal injection, PSU setting, and similar actions. For this project there is a requirement to switch on the power supply to the Widgetometer.

Action	Description
UnderRange	Throws or passes error
Init Drive System	This initializes the drive hardware
Set PSU Volts	Sets the power supply volts current
Get PSU Volts	Returns the power supply volts
Get PSU Current	Returns the power supply
Clear PSU	Sets the power supply to a safe level, 0 Vdc
OverRange	As UnderRange

The front panel, as shown in Figure 9.24, is a command Strict Type Def. enumerated type, with just the voltages in and results out.

Figure 9.24. Drive component front panel.

The rest of the states are the same, as shown in Figure 9.25, with corresponding messages to the PSU component.

Figure 9.25. Initialize drive component.

Read Actions

There will be a multimeter for analog input measurement. There will also be the commands to talk to the serial port. Finally, we'll put the visual inspection stuff in here as well.

Action	Description
UnderRange	Throws or passes error
Initialize Meas System	This initializes the measurement hardware
Read Unit Status	Read the selected unit's Status from the serial port
Read Unit Serial Number	Read the selected unit's Serial Number from the serial port
Read Unit Part Number	Read the selected unit's Part Number from the serial port
Read Unit Software Version	Read the selected unit's Software Version from the serial port
Read Chan1 Reading	Read the selected unit's channel 1 reading from the serial port
Read Chan2 Reading	Read the selected unit's channel 2 reading from the serial port
Get Chan1 Display Reading	Get the display reading for channel 1
Get Chan2 Display Reading	Get the display reading for channel 2
Measure Analog Out	Returns the dc volts from the DMM
OverRange	As UnderRange

Let's quickly look at some of the implementation of these actions.

Figure 9.26 shows the Read component front panel, where once again we use the ubiquitous Test Position Strict Type Def. enumerated type, and as before we define a new Read Commands Strict Type Def. enumerated type with the commands defined earlier.

Figure 9.26. Read component front panel.

Nothing too tricky about this. The read component merely calls the visual, serial, or DMM components and returns their responses as shown in Figures 9.27 and 9.28.

Figure 9.27. Visual component call.

Figure 9.28. DMM and serial component calls.

The only other action of note is the Initialize command, which is shown in Figure 9.29.

Figure 9.29. Read Initialize action.

Finally, you need a test executive, so that is discussed next.

The array of hardware actions drives the For Loop for each active test position. In reality, the results would go to a file or a database. The more observant reader will have looked at Figure 9.30 and noticed that the array “Tests” is an array of constants. Correct! Although they are dynamic Strict Type Defs., they are indeed constants and would be better placed in a file.

Figure 9.30. Widgetometer test executive.

If you see a constant String or Number anywhere in your code, pull it out into a configuration file. We use a pattern for this that takes advantage of the flexibility of enumerated types.

Make a copy of the Prototype Software Directory on your hard drive and rename it Widgetometer Software Directory. Now you need to copy the configuration directories over to where the program resides. So copy the following directories to your Widgetometer Software Directory:

If this has been done correctly, you will find that the following message will be displayed as shown in Figure 9.31.

Figure 9.31. Confirm Folder Replace.

Select [Yes to All].

Rename the directories to suit as shown in Figure 9.32.

Figure 9.32. Rename directories.

Open Widgetometer User Interface.vi and find any lost VIs. Widgetometer User Interface loses Widgetometer Enter Data.vi and 2 button dialog.vi. Then select File>>Save With Options>>changed VIs from the menu and save everything.

Without closing Widgetometer User Interface.vi, open Config ini.vi and as before find any lost VIs or Controls. This is usually just Datamanager.ctl. Once again select File>>Save With Options>>changed VIs from the menu.

Rename Config ini.vi to Widgetometer Config ini.vi, and update the icon to reflect the new program.

Now we need to open the configuration file when the program starts and load all the configuration data. In Widgetometer User Interface.vi you will find UI Initialize.vi, open it up and put . . .\2 System2 Data Handling1 File Management1 File HandlerFile Handler.vi into it, and put in the file path to the configuration file as shown in Figure 9.33.

Figure 9.33. Add configuration to initialize VI.

Also put in the two data manager VIs. They can be found in . . .\2 System2 Data HandlingConfig Data (or copied from the hierarchy diagram). Pop up on the command input and select “Load All”.

Now drop Widgetometer Config.ini into the case for Button 3 in Widgetometer User Interface.vi diagram (run state), as illustrated in Figure 9.34.

Figure 9.34. Make Config.ini dialog active.

You can optionally change the names of the data manager files and customize the icons to your individual requirements. What you now have is the capability to create, load, and save constants in a reasonably secure location. Defining these constants is as simple as updating an enumerated type control.

Let's do a couple as an example. Let's remove the example parameters and add a new parameter called System Name. We've changed the data manager names to Widgetometer System Config Data Man.vi and Widgetometer System Config Data Man2.vi.

Double-click on the parameter control on Widgetometer System Config Data Man.vi front panel to bring up the control editor (if you haven't got this option set you'll have to open the control in longhand by highlighting the control and selecting customize from the menus). Figure 9.35 shows the resulting screen.

Figure 9.35. Customize parameter.

Remove the example parameters and replace the last one (you won't be able to remove it) with System Name.

To run the new set up you will have to ensure that the directory for the Config.ini file exists (as pointed to in UI Initialize.vi). The ini file will be automatically created when the program is first run.

Now run Widgetometer User Interface.vi and select Button 3 (after it moans about there being no file). The Config.ini dialog should be displayed. You will notice that there is now a key called System Name.

Other constants we could pull out of the code at this stage are:

All you do then is drop the Widgetometer System Config Data Man.vi into the relevant hardware VI and wire it as shown in Figure 9.36.

Figure 9.36. Taking detail out of hardware VI.

Finally, the array of Strict Type Def. enumerated types used to drive the Test Executive should also be generated from the configuration file.

In keeping with the components within components theme we have created an error handling component. This component can be set to a mode where it complains loudly (throws dialogs) or logs errors discretely. In development mode you want it to complain loudly, and in run mode you want it to store the errors in a file. This component is called Error Control.vi and comes with both the User Interface Pattern and the Config.ini pattern.

Information hiding makes the error handling decision-making process a little simpler. Lower-level private components can pass errors up to their peer components. These errors can then be handled by the top-level components. The following diagram, as shown in Figure 9.37, illustrates the process.

Figure 9.37. Widgetometer hardware error handling.

The program executive could also have an error state that handles the errors and warnings in an elegant manner.

The program executive was discussed earlier, but what are the advantages of doing it like this? It is actually quite easy to list the different states of a system. From a hardware perspective, most test systems have very few states. These states are then defined by the hardware component. So using state machines has simplified the definition of the problem.

The program executive is usually just as simple to define. The ones in Figure 9.38 describe a common pattern.

Figure 9.38. Widgetometer program executive.

Another common state machine is the Test Executive. The one used in this system takes advantage of the fact that the hardware component models all the states that the test system has. It takes an array of these states and sticks them into a For Loop, creating a sequence of states that defines the test. For extra flexibility this array of constants should be pulled out of the code and stored in a file.

The state machine structure also helps when changing code. In the Widgetometer case if we wanted to define and add a completely new test, we would simply update the hardware component and add the new hardware actions to the array in the Widgetometer test executive.

What have we reused and how much effort has it saved us?

If you are in a multideveloper environment you will find the following checklists useful for broadcasting the standards expected for a job. They are also quite good as reminders, even if you're working on your own. We like checklists!