Ini File Builder

I have been playing around with a bunch of ideas, and they are finally cohering into my new project.

The problem:  We have a set of electrical schematics that define a piece of custom equipment.  The schematics contain crucial information, such as what devices are present (motors, sensors, actuators, etc.), where they are located (address/port/bit), what function they perform (tank empty sensor, door closed sensor, etc.)  Then some poor soul has to go through the schematics item by item and transcribe the information into Ini files that our software can use to know what devices there are and how to address them.  It is a tedious and error-prone process.

My initial thought was that we could automate this process.  Autocad allows you to define devices as blocks with properties.  The drawing can be published to a DWF file format.  Software can read the block manifest out of the DWF package.  This allows us to read the block properties, monitor the mouse position on the diagram, and change the colors (primitively) of devices on the diagram.  We have applied this idea to create an interactive plumbing diagram where you can actuate valves and view readings and and sensor states. 

Upon reflection, I decided the automated method would not work for us.  First of all, the electrical schematics don’t currently use blocks.  I tried to convince our EE that it would be to his benefit to start drawing the diagrams that way, but the idea didn’t fly with him.  Besides which, we would need to burden the EE with entering some device ID information that the software would require, and that is not a fair or realistic approach. 

My current plan is write a software program where a user builds up a software model of the schematics.  The user will enter a list of modules, where each module defines a controller unit that controls motors, heaters, actuators, etc.  The user will enter the type and address of each module.  The software will know enough about each module type that it can come up with a map of device connections for the module.  For instance, perhaps a motor module consists of two motors, two home sensors, two additional sensors, and some feedback readings.  The software will display a block representation of the module and its available connections that looks similar to the drawing on the schematic.  The user will be able to select devices from a list and drag them to the appropriate connections.  The device will come with predefined configuration information.  For example, the user may select the Handler Vertical Motor as a device and drag it to the Motor connection on the module.  From this action, we can generate the information we need for our Ini files that there is a motor at the specified address/port with an associated range of motion, gain, current setting, plus an associated home sensor assigned to a related address/port/bit location.

In creating the software model, there is still some unfortunate replication of effort where we have to redefine in the model what we already have in the schematics.  However, the process will be much faster and much more reliable than what we have today, which is a person typing in the information freehand.  And who knows – perhaps ultimately we will have readable schematics that we can use as a starting point, and we will just use the software model to enter the additional information we need.

Now for the fun part:  Implementation!  The modules (also called boards) will be represented by XML files that define the configuration of the module.  For instance, the two-motor controller module has an address, two motors, sensors, etc.  Then there will be a set of XML files that define all the devices.  As the user adds modules associates device information with the modules, we will generate a set of equipment XML files that contains merged information from the module and devices representations.  From the equipment XML files, we can generate the Ini files that the software needs.  Long term – maybe we will convert the software to work directly from the equipment XML files.  But one step at a time…

The other aspect of this project is that for the first time, I am trying to use Test Driven Development practices.  I am developing in C# on Microsoft Visual Studio 2005, with NUnit as the testing framework.  I was initially afraid that using TDD would complicate the software and slow me down.  Not so!  After one day of trying TDD, I was totally sold on the idea. 

For one thing, NUnit itself is very simple and intuitive to start using.  I installed NUnit, read their “Getting Started” sample – and it was off to the races!

Test Driven Development has some advantages that become apparent almost immediately.  Such as:

  • Instant gratification!  Don’t all we programmers love that?  I don’t have to wait until I have my own framework of code written to run.  I can test each procedure as it is written.
  • Saving the tests.  Often, if I wanted to test some code, I would create a simple test project, get the code working, port the code back to the real project, and delete the test project.  With NUnit, the test is built into the code so, presumably, it is maintained.  And, of course, then you have the HUGE benefit of being able to run the tests when you make changes to make sure everything still works.
  • Cleaner design.  Normally, I would write code in place, and test it with whatever other code was running.  This meant that I would simultaneously be building up the user interface, the business functionality, and the low level IO so that I could get a runnable program.  This made it easy to leak functions from one area into another.  Having the NUnit framework to isolate testing of different areas makes it easier to keep those areas unified.
  • Detach the user interface.  I have a visual, drag and drop Windows Forms interface in mind, but I want to keep that separate.  Maybe someday we will also have some kind of scripted command line interface for autogenerating files.  I’m hoping that, once I get this project working, I will be able to spend some time learning WPF and replace the Windows Forms interface with a WPF version.  I thought that was too much to take on for the initial version.

That’s the plan.  We’ll see how it goes…


Post a Comment

Required fields are marked *

%d bloggers like this: