IDFstepper
IDF to STEP converter
IDFstepper Documentation

The IDFstepper is a simple tool to create 3D STEP models from IDF files, as generated by many PCB design tools. For more information about IDF, see http://www.simplifiedsolutionsinc.com/

Overview

The software is divided into a few main parts:

1. IDF file parser

2. Configuration file parser

3. STEP model generator

4. Main application logic

The IDF file parser is built around boost::spirit::qi and friends and parses IDF data into the appropriate data structures. The parser's core, it's grammar, can be found in IdfGrammar.hpp. This file should never be included from any other place than from the parser, as the heavily templated spirit framework causes huge compilation times. Use IdfStructure.hpp for the IDF data structures and IdfParser.hpp for the parser API.

The config file parser is a simple piece of code to read configuration files for the software. It is based on boost::spirit::qi as well. The program is intended to be very simple to use and therefore does not have a huge number of configuration options. See the sample config idfstepper.conf for a verbose list of all options. Config data is parsed into a list of key/value pairs, with the values being of type boost::variant to have inherent support for values of different data types. Just as with the IDF parser, you should avoid to include ConfigGrammar.hpp, but instead use ConfigType.hpp for the type declarations and ConfigParser.hpp for the parser API.

STEP models are complex beasts and may not easily be created with user code. For this reason, the STEP model generator (StepGenerator.hpp) uses the 3D modelling toolkit OpenCASCADE to calculate the solid geometry data and handle the STEP files. OpenCASCADE has a header file for almost every function and data structure, so the sources may easily get cluttered by a lot of includes. The file OpenCascade.hpp serves as a central place for all these includes.

The main file Main.cpp holds the previously described parts together and serves as a place for the application logic. As already noted, the program should be easy and efficient to use. For this reason (and because I'm a bit lazy), it does not even include a GUI. Should user interaction be necessary (such as asking if a file should be overwritten), the terminal window serves as a user interface.

Program usage

The most common use case is to simply drag the IDF files to process and drop them on the executable. This results in a call like

$ idfstepper /path/to/library.idf /path/to/board.idf

The ordering of the file types does not matter, neither do the file name extensions. All passed files will be parsed as they are encountered, but their contents will always be processed in the following order:

1. Configuration files (the main config idfstepper.conf in the executable directory is implicitly processed first, just before any files specified on the command line)

2. IDF library files (component descriptions)

3. IDF board files (board outline and component assembly)

4. IDF panel files (panel outline and multiple boards)

This ordering ensures that all data is available when it is referenced if multiple file types are passed at once.

Should something go wrong while processing, the program emits a warning to the terminal. As there may be a lot of progress information as well, the list of errors or warnings is printed again at the end of the run. The most common source of errors are invalid paths. When generating files, the target location is built from the values of the XY_PATH and XY_NAME_PATTERN config options (see idfstepper.conf for details).

Note:
The resulting path must be fully existant and writable for the STEP generator to succeed. If this rule is violated, the program simply says that it cannot store the file. It is not very communicative in this respect at the moment.

Care must be taken when working with relative paths. These are always relative to the working directory of the application. If using the drag&drop method mentioned above, then the working directory is most likely the folder in which the dragged files are located. Suppose, for example, you have a file my_library.idf located at /home/user/idf/. When you drag this file onto the executable /usr/share/bin/idfstepper, then the working directory of the application is /home/user/idf/. So if the config option LIBRARY_PATH has the value "step", the resulting files will be placed into /home/user/idf/step/, provided that this folder exists. Problems with this behaviour can be avoided if specifying absolute paths in the config file.

Testing

The QTest library serves as a basis for automated testing of the application. The test classes can be found in the "test" subdirectory of the source distribution. The unit tests are not very extensive at the moment, they mainly test the IDF and config file parsers.

License, disclaimer, and such

The software is provided as-is and without any warranties. Here would follow all the usual stuff for lawyers, which hardly anyone ever reads.

The code is released without a specific license, it's just "public domain", as far as this is applicable. You may freely modify and/or redistribute it, but please let me know. Thanks.

This application makes use of other code, in source as well as in compiled form. It does especially depend on a subset of the OpenCASCADE 3D solid modelling toolkit and on parts of the boost C++ library. These components are copyright by their respective owners and may be used as specified in their licenses.

For additional information, feedback, downloads, etc., please check http://hb9etc.ch

Philipp Burch

 All Classes Namespaces Files Functions Variables Typedefs Enumerations Enumerator Defines