application development for automated positioning of 3d

Institutionen för datavetenskap Department of Computer and Information Science

Final thesis

Application development for automated

positioning of 3D-representations of a

modularized product

by

Christian Larsson

LIU-IDA/LITH-EX-G--13/034--SE

2013-06-03

Linköpings universitet

SE-581 83 Linköping, Sweden

Linköpings universitet

581 83 Linköping

Linköping University Department of Computer and Information Science

2 2013-06-03

Final Thesis

Application development for automated

positioning of 3D-representations of a

modularized product

by

Christian Larsson

LIU-IDA/LITH-EX-G--13/034--SE

2013-06-03

Supervisor: Tommy Färnqvist

Examiner: Tommy Färnqvist


3 2013-06-03

Abstract

This thesis presents an application that performs positioning of modules automatically based on

given data for every module, and the development of it. The basis of the application is from a

previous thesis code. On top of that code, more features and error handling has been added, as well

as fixes for various bugs. A stress test has been performed and further development possibilities are

being presented.

The thesis work was carried out at Toyota Material Handling Mjölby (TMH) and was made in parallel

with another thesis by Fredrik Holden who was generating data for the application. For a complete

understanding of the theory and background, please also read Holden’s thesis report “Development

of method for automated positioning of 3D-representations of a modularized product”, as well as the

former thesis ”Analysis for Automated Positioning of 3D-representation of a Modularized product””.


4 2013-06-03

Sammanfattning

Detta examensarbete presenterar en applikation som positionerar moduler automatiskt med hjälp av

given data för varje modul, samt utvecklingen av applikationen. Applikationen bygger på kod från ett

tidigare examensarbete. Ovanpå den koden har flera egenskaper och felhanteringar lagts till, samt

har olika buggar fixats. Ett stresstest har också utförts och framtida utvecklingsmöjligheter

presenteras.

Examensarbetet genomfördes på Toyota Material Handling Mjölby (TMH) och gjordes parallellt med

ett annat examensarbete av Fredrik Holden som genererade data för applikationen. För en

fullständig förståelse angående teorin bakom samt bakgrunden till examensarbetet, vänligen läs

också Holdens rapport ”Developmentof method for automated positioning of 3D-representations of

a modularized product”, samt rapporten från föregeånde examensarbetet ”Analysis for Automated

Positioning of 3D-representation of a Modularized product”.


5 2013-06-03

Acknowledgements

I would like to thank my supervisor at TMH, Boris Ahnberg who has made a great work in supporting

and guiding throughout the project. I would also like to thank my supervisor at Linköping University

Tommy Färnqvist for valuable input and feedback, Per Axner, Carl-Olov Naeslund and Leif Axelsson at

TMH for discussion, feedback and information that was needed for understanding and to complete

the thesis.

Last I would like to make a special thanks to my friend Fredrik Holden who has been with me all the

time during the thesis work.


6 2013-06-03


7 2013-06-03

Table of Contents 1 Introduction ........................................................................................................................................ 11

1.1 Background .................................................................................................................................. 11

1.2 Assignment and project goal ....................................................................................................... 11

1.3 Delimitations ............................................................................................................................... 11

2 Thesis context ..................................................................................................................................... 13

2.1 Module, module family, interface ............................................................................................... 13

2.2 Configurator ................................................................................................................................ 14

2.3 Calculating position of modules .................................................................................................. 14

2.5 Visualization ................................................................................................................................ 15

3 Method ............................................................................................................................................... 17

3.1 General approach ........................................................................................................................ 17

3.2 Prioritization matrix ..................................................................................................................... 17

3.2.1 Time ...................................................................................................................................... 18

3.2.2 Level in chain ........................................................................................................................ 18

3.2.3 Priority .................................................................................................................................. 18

3.3 Iterative design ............................................................................................................................ 18

4 Result .................................................................................................................................................. 21

4.1 Read a list of modules, calculate position and write file for the visualizer ................................. 21

4.2 Error handling .............................................................................................................................. 22

4.2.1 Module not placed ............................................................................................................... 22

4.2.2 Interface on multiple modules ............................................................................................. 23

4.2.3 Multiple of same interface on module ................................................................................. 24

4.3 Stress test .................................................................................................................................... 24

4.3.1 Comparing between using excel cells and arrays ................................................................. 25

4.4 Template for platform and assembly structure .......................................................................... 25

4.5 From configurator string to list of composing modules .............................................................. 27

4.6 Usage of real data ........................................................................................................................ 27

5 Conclusion .......................................................................................................................................... 29

6 Discussion ........................................................................................................................................... 31

6.1 Prioritization Matrix .................................................................................................................... 31

6.2 Iterative Design ........................................................................................................................... 31

6.3 Application ................................................................................................................................... 31

6.4 Limitations ................................................................................................................................... 31


8 2013-06-03

6.5 Future development .................................................................................................................... 32

6.5.1 Excel vs. Database ................................................................................................................ 32

6.5.2 VBA vs. C++/Java................................................................................................................... 33

References ............................................................................................................................................. 34

Picture reference ............................................................................................................................... 34

Appendix A – The initial use cases and their level in chain ................................................................... 35

Appendix B – Stress test code ............................................................................................................... 37

Appendix C – Prioritization matrix ........................................................................................................ 38

Appendix D – Code ................................................................................................................................ 40

Modules ............................................................................................................................................. 40

Forms ................................................................................................................................................. 40


9 2013-06-03

Table of Figures

FIGURE 1, MODULES AND MODULE FAMILIES ................................................................................................................................................. 13

FIGURE 2, THE CUSTOMER TO CONFIGURATION CHAIN .................................................................................................................................. 14

FIGURE 3, SELECTION OF MODULES FOR A CONFIGURATION .......................................................................................................................... 14

FIGURE 4, TRANSLATION CALCULATION .......................................................................................................................................................... 15

FIGURE 5, ROTATION CALCULATION IS CARRIED OUT AFTER THE MODULE IS MOVED TO ITS CORRECT POSITION IN THE ASSEMBLY ........... 15

FIGURE 6, THE FUNCTION GRAPH FOR TIME SCORE ........................................................................................................................................ 18

FIGURE 7, ITERATIVE DEVELOPMENT MODEL .................................................................................................................................................. 19

FIGURE 8, MODULES ARE CALCULATED AND POSITIONED USING BREADTH-FIRST ......................................................................................... 21

FIGURE 9, PRINTOUT OF A MODULE IN THE KNOWLEDGE BASE WHERE THE NEW TRANSLATION AND ROTATION IS MARKED IN RED ......... 22

FIGURE 10, THE POSITIONING STEPS OF TWO MODULES WHERE THE BLUE MODULES ORIGIN IS IN ITS CENTRE .......................................... 22

FIGURE 11, ERROR MESSAGE WHEN MODULE IS NOT PLACED........................................................................................................................ 22

FIGURE 12, MULTIPLE MODULES NOT POSITIONED SHOWN IN THE VISUALIZER ............................................................................................ 23

FIGURE 13, MESSAGE AND CHOICE WHEN SAME INTERFACE IS FOUND IN MULTIPLE MODULES ................................................................... 23

FIGURE 14, MESSAGE AND CHOICE WHEN THERE IS MULTIPLE OF SAME INTERFACE IN SELECTED MODULE ................................................ 24

FIGURE 15, PRINTOUT OF THE RESULT FOR STRESS TEST ................................................................................................................................ 24

FIGURE 16, TIME DIFFERENCE BETWEEN USING EXCEL CELLS AND ARRAYS IN ERROR HANDLER ................................................................... 25

FIGURE 17, MESSAGE AND STRUCTURE CHOICE .............................................................................................................................................. 25

FIGURE 18, THE STRUCTURE HAS BEEN PRINTED FOR FOUND MODULES ....................................................................................................... 26

FIGURE 19, EXAMPLE OF THE STRUCTURE FOR MODULES SHOWN IN 3DVIA ................................................................................................. 26

FIGURE 20, PART OF A FORKLIFT POSITIONED WITH GENERATED DATA BY FREDRIK HOLDEN........................................................................ 27

FIGURE 21, THE CASES WITH THEIR LEVELS WITH THE ARROW REPRESENTING THE LIST OF COMPOSING MODULES ................................... 36


10 2013-06-03

Nomenclature

3Dvia Software that illustrate 3D animations

CSV Comma-separated values

ERP Enterprise Resource Planning

Interface A designed solution to connect and realize interaction between two different modules

Module A set of components with an interface driven by a company strategy

Module Family Contains modules interchangeable with each other. They fulfill the

same function

SMGXML An variant of xml-file that is used by 3Dvia

VBA Visual Basic for Application XML Extensible Markup Language


11 2013-06-03

1 Introduction The introduction section includes some background information about this thesis, what the

assignment and project goal was, and also delimitations that were set before the thesis started.

1.1 Background In spring 2012, a master thesis was made at Toyota Material Handling (TMH) by Tobias Johansson and

Stefan Karlsson called “Automated positioning of 3D-representation of a modularized product”*1+.

They were studying if it was possible to make automated 3D-representations of the forklift TMH is

building. The result of the thesis was a success, and they were also able to make a 3D-representation

of some dummy parts.

The project this thesis is concerned with was about developing an application that uses live and real

data of forklift modules that is used at TMH. The thesis was made in parallel with another thesis

made by Fredrik Holden, who was calculating position data for modules that is being used in the

application *2+.

1.2 Assignment and project goal

The project goal was to make an application that is able to automatically generate a 3D-

representation of a forklift that consists of modules that is today used at TMH.

The application would start by using an information output from a configurator to make a list of

composing modules. To make the list of modules, different data tables needs to be used. The

application should also include a choice, where the user will be asked if the application would use

verified or prototype data tables. An analytic function that shows the difference between a verified

model and a prototype model would also be implemented. All info would be saved in a .xml

document.

After this, a program written in Visual Basic and Excel starts by using the information from the .xml

document to build a data structure of all the modules, and set the correct coordinates for each

module. If there is some error in building the data structure, an error handler catches the problem

and handles it. The information would then be saved in a .smgxml document.

A Visual Basic program did exist before this project started; however it had almost no error handling,

there was no choices to be made by the user if a conflict came up in the calculations and used only

prototype data.

Because of the amount of data that is used, a stress test needed to be done to study if Excel is able to

handle all the calculations in the application.

1.3 Delimitations Some limitations were set before the project started to minimize work that might take long time

without giving much result:

Directory paths is configured in a setting file or hardcoded

Data tables will be changed and updated by the user and not by the application

Input files will not be saved by the application


12 2013-06-03

The input from the configurator file will be saved in the result

The application will only support one forklift platform

Data tables will be saved as .csv files for easier data reading.


13 2013-06-03

2 Thesis context This section contains general information about how a forklift is ordered and how the parts are being

chosen. Definitions and terms are also presented. Also, information on how the positions are being

calculated is provided.

2.1 Module, module family, interface

FIGURE 1, MODULES AND MODULE FAMILIES

A forklift is divided into different modules, where a module is a set of components that have one or

more interfaces to other modules. Modules are divided into module families. There are two

conditions that must be fulfilled for a module to be in a module family. First, they all must have the

same functionality. Second, they must all have the same interfaces. The maximum amount of

modules from a module family that can be in a forklift configuration is one. [1]

An example of a module family is Gear, and in the Gear-family there are many different gear

modules.

At TMH, an interface is defined as the connection node between modules. A module might have

many different interfaces for connecting to other modules; however they are required to have at

least one. Since every module in a module family must have the same interfaces, interfaces are

connected to a module family rather than a module. The position of the interface however may vary

depending of the size and shape of the specific module. [1]


14 2013-06-03

2.2 Configurator

FIGURE 2, THE CUSTOMER TO CONFIGURATION CHAIN

The production of a forklift starts with a sales configurator that makes a set of choices of different

features the customer wants for his forklift. The configurator includes constrains, so the customer

cannot choose features that will not work together. [1] [3]

FIGURE 3, SELECTION OF MODULES FOR A CONFIGURATION

After the sales configurator choices have been made, the configurator will give a list of valid features

that is translated to work for a different configurator part of the ERP-system EnterpriseOne™ (E1).

The E1 configurator will then look though a number of condition tables that includes combinations of

features. A certain combination in a condition table might have a module as output, or no module as

output (marked as Notvalid). If a combination from the configurator matches the combination, and

that combination has a module as output, that module will be used in the forklift setup and is saved

in the list of composing modules.[3]

2.3 Calculating position of modules The calculation is divided into two parts, position and rotation. All modules have one interface that is

seen as its own point of origin (0,0,0). Any other interface has a position that is relative to that


15 2013-06-03

interface. When a new module is connected to a placed module, the new module will get the

position of the placed module added with the position of the connected interface as illustrated in

figure 4.

FIGURE 4, TRANSLATION CALCULATION

The rotation is calculated in the same way as the position which is illustrated in figure 5. However,

when a module has been rotated, its position needs to be adjusted to work for the global coordinate

system. For more information about the theory behind this and how it is calculated, please read the

previous thesis. [1]

FIGURE 5, ROTATION CALCULATION IS CARRIED OUT AFTER THE MODULE IS MOVED TO ITS CORRECT POSITION IN THE ASSEMBLY

2.5 Visualization To visualize all the modules, the previous thesis made a scheme for a smgxml-file that is opened with

3Dvia. The file includes the position and the name of the geometry file for each module. When the

file is opened by 3Dvia, it will visualize all the modules together. [1]


16 2013-06-03


17 2013-06-03

3 Method The method chapter includes information about the methods that were used when making this

project.

3.1 General approach Since this project is based on a master thesis, it was fundamental to start out by studying and

understanding its report, especially the result and conclusion. To save time and energy, it was also

important to examine and understand the code they made so the application development wouldn’t

start from scratch. Some info needed to be learned, especially what module, module family and

interface are and how they are connected.

After the initial study, the project was divided into several use cases. A total number of 13 use cases

were identified from start. A complete list of the use cases is presented in Appendix A.

The project time was divided into three sequences. Each sequence was given a number of use cases.

Which use cases that were given to a sequence was decided using the prioritization matrix method.

A sequence started with planning on how the time would be spent. After that the development of

the use cases started. Before the end of the sequence, each task that has been worked on was both

tested and checked if it was completed or not. Notes on the test result were also made.

Between two sequences, there was a verification meeting with the supervisor at TMH and/or LiU.

The main idea with these meetings was to see if everything that was planned to be done on the

sequence were done. If everything was finished in time, the next sequence will go on as planned. If

some parts were not yet finished, a new list of task has to be produced using the same method as

before.

The idea of splitting the project time in different slots was taken from SCRUM. In SCRUM, project

time is divided up into sprints, where a sprint is usually between 3 to 30 days. For each sprint, some

parts of the project are being implemented that is decided before the sprint start. [4]

If something critically would have appeared in the middle of a sequence, it was also possible to

arrange a new meeting to modify the list of task.

To verify if a requirement was fulfilled, tests were done with employees at TMH.

3.2 Prioritization matrix Due to limited time available, a method to decide what use cases that should be focused on was

needed. For this a prioritization matrix was used. When using the prioritization matrix, all use cases

gets point from different criteria where each criterion has its own weight. The criteria used was

estimated time to complete that use case, in what level of chain the use case is in relation to the

whole application, and what priority does the use case has.

The final score for a use case is the sum of all criteria score, and the use cases with the highest score

were focused on first; however some conditions were also set. If B have higher score then A, but it is

not possible to do B before A, B would be prioritized to a level under A. What cases that should be

focused on where ordered for each sequence separately. This meant that even if a case had a higher


18 2013-06-03

score, there was a possibility that it would not be focused on at that sequence depending on whether

it could be done in the remaining time slot or not. The initial prioritization matrix that was used is

being presented in Appendix C.

3.2.1 Time

All use cases were given an estimated time for completion. The time score was calculated with the

formula: (Average - | Average – Time |), where Average was the average time for completing a use

case, Time was the estimated time for that specific use case, and the score for each case was

between five to zero. The main idea about using this formula for scoring was to find a balance

between numbers of cases done and time spent on each case.

FIGURE 6, THE FUNCTION GRAPH FOR TIME SCORE

3.2.2 Level in chain

Level in chain describes in what level each use case is in the order of data handling, where the start

of the application is on a high level and the end of the program is on a low level. A higher level gives a

higher score, and the score is between five to zero. The level in chain is being illustrated in Figure 21

in Appendix A.

3.2.3 Priority

Each use case had a priority. The priority was set depending of that the employees of TMH thought

was most desirable. The priority score had a double weight in relation to the other score, and the

score was between ten to zero.

3.3 Iterative design When a part of the project was implemented, an iterative design method was being used. This was

used rather than using a more traditionally waterfall method, which has been getting criticism for

being a non-working method [5]. Instead of making all the design before coding, the iterative method

is used by doing design, implementation and testing in a circle until finished [6]. This circle is

illustrated in figure 7. Since the project is both split in time and cases, iterative design felt like a

natural choice to work with. The design, tests and their results for each use case were documented

and time stamped.


19 2013-06-03

FIGURE 7, ITERATIVE DEVELOPMENT MODEL


20 2013-06-03


21 2013-06-03

4 Result Much of the code from the former thesis was extracted and used. On top of the existing code,

different features have been added. All coding is written in VBA using Excel.

4.1 Read a list of modules, calculate position and write file for the visualizer At first the idea was to read in the properties from the configurator string together with the list of

composing modules. However since the reading of the configurator string was not done (see section

4.6 for more info), the reading of properties was skipped.

Rather than starting from an initial module when the calculation of positioning is done, one or more

modules are connected to an initial world zero where the calculation will start. This means that

different trees of modules that are not connected can be positioned and viewed together, which is

illustrated by a tree in figure 8. Otherwise the calculation works like before, where a module has

exactly one interface where it is placed, and a number of interfaces where other modules might be

placed. If nothing is being placed on the module, it has no such interfaces.

FIGURE 8, MODULES ARE CALCULATED AND POSITIONED USING BREADTH-FIRST

Later in the project, it turned out that the origin of the module might be different than the position

of the interface where it should be placed. To fix this, the translation and rotation data between

these positions was added in the knowledge base, which is seen in figure 9. The module’s position is

then compensated with the new data when positioned. This will position the module correct every

time. An example where the place of origin and the interface of a module are different is illustrated

in figure 10.


22 2013-06-03

FIGURE 9, PRINTOUT OF A MODULE IN THE KNOWLEDGE BASE WHERE THE NEW TRANSLATION AND ROTATION IS MARKED IN RED

FIGURE 10, THE POSITIONING STEPS OF TWO MODULES WHERE THE BLUE MODULES ORIGIN IS IN ITS CENTRE

The writing of the .smgxml-file to the visualizer by using the xml-scheme and the style of the

knowledge base has not been edited. However the .smgxml-file is being modified and is further

explained in section 4.4.

4.2 Error handling The former program did not handle many errors. In addition to various bug fixes, some handlers

were added for different scenarios.

4.2.1 Module not placed

When modules are not placed, they are placed behind the forklift rather than being removed. This is

done by a check between the input of modules and the output of calculated and positioned modules.

If a module is in the input and not in the output, it is placed behind the fork. If there is more than

one module that is not in the output, they will be set in a line with a fixed distance between them

which is illustrated in figure 12. When a module is not being placed, the message in figure 11 will be

shown.

FIGURE 11, ERROR MESSAGE WHEN MODULE IS NOT PLACED


23 2013-06-03

FIGURE 12, MULTIPLE MODULES NOT POSITIONED SHOWN IN THE VISUALIZER

4.2.2 Interface on multiple modules

There might be cases where a module can be placed on two or more different module. Since the

application matches interfaces, it is impossible for it to know which interface to use. For this, a

handler was made that is looping through all modules interfaces. If there is a module that is to be

placed on a specific interface, and that interface is found on two or more different modules, a

textbox will pop up that says that the interface has been found on multiple modules. A list of the

modules will then come up where the user has to manually select the one of these modules, which is

shown in figure 13.

FIGURE 13, MESSAGE AND CHOICE WHEN SAME INTERFACE IS FOUND IN MULTIPLE MODULES

When a module has been selected, its interface and the other module’s interface change name so

that the application will later match them when the calculation of positioning starts. The selected

module will also make a copy of the interface, in case something else is being placed on it.


24 2013-06-03

4.2.3 Multiple of same interface on module

This handler works much like the former one, with the difference that it looks for more than one of

the same interface on a selected module. If multiple is found, one must be selected by the user. The

coordinates for these interfaces are displayed so the user will know the difference. The output of this

handler to the user is illustrated in figure 14. The interfaces will be renamed and copied like in the

previous handler.

FIGURE 14, MESSAGE AND CHOICE WHEN THERE IS MULTIPLE OF SAME INTERFACE IN SELECTED MODULE

4.3 Stress test Since a forklift consists of many modules, a stress test was carried out to study the software

performance. The test consisted of 500 modules that were to be calculated with no errors. The total

running time for this test was around 40 seconds, as seen in figure 15.

FIGURE 15, PRINTOUT OF THE RESULT FOR STRESS TEST


25 2013-06-03

4.3.1 Comparing between using excel cells and arrays

The stress test showed that one part of the application that took a long time to run was the error

handler for multiple modules. The error handler uses a loop in the loop to check for matching

interfaces and this gives a time complexity of O(n2)[7], which means that if modules are added, the

time taken will increase quadratic.

To study if improvement in performance can be generated by using arrays in visual basic rather than

cells in excel, another test were made. The test consisted of two parts, one part where the error

handler made lookup in excel cells like before, and another part where the lookup was made in

arrays instead.

The test result is shown in figure 16, and it showed that the second part of the test was over 250

times faster than the first part when using 500 modules.

The code that was used to make this test is written in Appendix B.

FIGURE 16, TIME DIFFERENCE BETWEEN USING EXCEL CELLS AND ARRAYS IN ERROR HANDLER

4.4 Template for platform and assembly structure A template for extracting structure of the modules has been added. The user will be asked to pick a

desired structure that is included in the application. For adding a new structure, a new sheet needs

to be made in the main program, and a string variable with the sheets name need to be included in

an array in the code. Initial, platform and assembly structure has been added. The output to the user

is shown in figure 17.

FIGURE 17, MESSAGE AND STRUCTURE CHOICE


26 2013-06-03

The code will search for each module in the selected sheet. Everything to the left of the module in

that sheet will be copied to the right of the coordinate for the module in the main sheet. The level of

the structure goes from left to right in the sheet. If a module is not being found, nothing will be

printed in that section in the main sheet.

When all data has been printed, all modules are sorted by the level of structure, with start from left

to right. If a module didn’t receive any data, it will be in the end of the list. This can be seen in figure

18.

The sort, together with a modifier of the made .smgxml-file that will read strings and replace it with

added structure information, will show the structure when the file is opened in 3Dvia. An example of

the structure shown in 3Dvia can be seen in figure 19.

FIGURE 18, THE STRUCTURE HAS BEEN PRINTED FOR FOUND MODULES

FIGURE 19, EXAMPLE OF THE STRUCTURE FOR MODULES SHOWN IN 3DVIA


27 2013-06-03

4.5 From configurator string to list of composing modules After more studying of how the procedure from configurator string to list of composing modules

works, this part of the project was skipped. The reason for this was that the time calculated for this

part was high and that this part had lower priority from TMH, which gave it a low score in the

prioritization matrix and was because of that not prioritized.

4.6 Usage of real data The application was tested with data and modules that were generated by Fredrik Holden when

making his thesis and it was able to position them correctly. The modules that were used in the test

can be seen positioned in figure 20.

FIGURE 20, PART OF A FORKLIFT POSITIONED WITH GENERATED DATA BY FREDRIK HOLDEN


28 2013-06-03


29 2013-06-03

5 Conclusion The project goal to make an application that is able to automatically generate a 3D-representation of

a forklift that consists of modules that is today used at TMH was achieved.

The part where the application would read the configurator output to make the list of composing

modules was not made. The estimated time of this part were high due to that the application to

make this today is decentralized into several excel documents and macro. To centralize it into one

application would take more time than what was available in the project.


30 2013-06-03


31 2013-06-03

6 Discussion This section contains discussion about the project and its result. The first part is a discussion about

the method used during this project; the other part is about the application, its limitation and future

development.

6.1 Prioritization Matrix To split the project into several parts and score them was overall a good idea. One large benefit was

that when each part was given an amount of time to complete, it gave a better overview of how

much time the whole project would take to complete rather when only looking at the big picture.

When the initial planning started, it was believed that everything could be done in time, but that was

not the case and it was also shown when every case was given an estimated time.

The level in chain score was something that could have been skipped, especially if the input and

output for each part of the system was planned at start. If all cases were given a set of data to work

with, and what data they should save or send, artificial data could be made by the user for each case

instead of being generated by the case a level above.

This was something that was done when testing the list of composing modules; however, since there

was a way to make that list before the project started, it was seen as something that was already

generated and reading the list was at highest level.

Another benefit was that it was easier to discuss the project with the employees at TMH when it was

divided into different parts.

6.2 Iterative Design The iterative design worked well when making this project. The main reason for this was that all

design for the complete project was not made before the coding started. If all design would have

been done before, much design would have been made on parts that were not even implemented.

The design was also friendly when something new came up during the project time that needed to

be implemented. Rather than make a new design and code from the start, it was added on the

already implemented part, which saved much time.

6.3 Application The application was made with the code from the old thesis as basis, which saved a lot of time.

Although, the given code still needed to be tested to make sure that it worked, which it in some

cases did not. The testing part was one of the most time consuming parts of the project. The

unofficial policy under the project was to test at least one time for each change that was made, but

often it was tested more than that, and much too often even more test would have been desirable to

prevent errors that came up later.

The code have been commented fairly well, especially the parts that has been changed. If wanted to,

it should be easy to develop the code more.

6.4 Limitations When the application is positioning each module, it sees the interfaces on each module in a

master/slave-perspective, where a module needs to have one interface where the module is being


32 2013-06-03

positioned (slave interface) and a number of interfaces where other modules is being positioned on

(master interfaces). If two modules that should be positioned with each other and they both see

their governing interface as either master or slave interface, they will not be positioned. In the

knowledge base, the first interface of the module is its slave interface and the rest is its master

interfaces. This could lead to error if the user accidently switches place on the interfaces in the

knowledge base, or don’t know that this perspective exists.

The Structure for modules has been set to work for a dynamic number of levels; however, for the

application to work correctly, every module must have the same amount of level or no level at all.

This is illustrated in Figure 18. A name in one level cannot also be found in another level. If this would

happen, the structure shown in 3Dvia will not be correct. The maximum number of levels has been

set to eight.

Errors were found when tried to rotate a module around X-, Y- and Z-axis at the same time. After

discussion with employees at TMH, a fix for this was not made since a case where this would happen

seemed unlikely.

6.5 Future development The application has some possible future development. To remove the master/slave-perspective on

interfaces would remove a possible source of error. Another benefit is that the calculation could

start from any modules in the list and would also remove the tree structure represented in figure 8.

To export the structure of the modules to 3DVia, it is possible to modify or make a new smgxml-

scheme. It was looked into as a possible solution in the project, but it was canceled due to lack of

knowledge and information. There is also a possibility to implement that the structure level is

dynamic for each module.

The tests in 4.3.1 showed that there are a lot of potential performance improvements available by

only using arrays instead of excel cells. This could be done by removing the temp-sheet in the excel

file, which has the information of each modules gathered from the knowledge base and is using for

all calculation and error handling, and instead gather and save everything in arrays directly in the

code.

After discussion with employees at TMH, a desired implementation would be to select any module

that is represented in the knowledge base. Onto the selected module, any module in the knowledge

base that has a connecting interface with the selected one will be placed on it. The main reason for

such an implementation would be to visually find errors.

Another possible implementation is to add a question to the user where all the geometry files is

located and should be opened from.

6.5.1 Excel vs. Database

Instead of saving the knowledge base in a excel sheet, it would be possible to save it in a centralized

database. This would give a higher data integrity, especially if only some people were authorized to

update the information. A drawback would be that if you would like to change or add information, it

is much easier to do so in excel. During the time at TMH it has been discussed that many employees


33 2013-06-03

don’t have so much programming skill, however skills in Excel is much more common since it is being

used often.

There is also possible to take a hybrid solution between using Excel and Database. One way is to use

the application as it is today, but have the application on a read-only part of a server with only some

people allowed to edit it. This would give a higher integrity rather than if everyone could edit the file.

Another solution would be to implement a choice for the user and ask if the information should be

read from a centralized database, or from local files. This would also give higher integrity and still

make it easy to test with local prototype data.

6.5.2 VBA vs. C++/Java

VBA have few advantages. The first is that it has commands to read and write to excel sheets, which

was good since all data was saved in Excel, and the other is that the code is written directly in the

excel document.

Other than that, opinion is that VBA has only disadvantages against languages like C++ and Java.

VBA is an implementation of Visual Basic for different application. Some code was or looked like

Visual Basic, but it could also be completely different. That you did not know if a function or a specific

syntax that was found for Visual Basic would work in the code was something that took a lot of time,

especially if it did not work which happened quite often. Not much documentation on Microsoft’s

webpage was about VBA function. Most of the time information about functions and their syntax

were found on different internet forums posted by users.

Many basic functions that exists in C++ and Java, like sort function for arrays, was not implemented

in VBA. This meant that a sort functions needed to be made. Sometimes it was possible to search for

code on the internet that someone else had done.

A final summary of this section is that VBA might be good for simple and small macros in different

applications. For the application that was made in this thesis project and the part that did not get

finished, VBA is a very bad language and a more powerful language with more implemented

functions is desirable.


34 2013-06-03

References *1+ T. Johansson and S.Karlsson, ”Analysis for Automated Positioning of 3D-representation of a

Modularized product”, Linköping, 2012.

[2] F. Holden, ”Development of method for automated positioning of 3D-representations of a

modularized product”, Linköping, 2013

[3] P. Axner and J. Hillman, Interviewee, The Configurator. [Interview]. 21 05 2013.

[4] J. Shuterland and K. Schwaber, ”The Scrum Guide”, 2011

[5] R. Winston, ”Managing the Development of Large Software Systems”, 1970

[6] A. Cockburn, “Using Both Incremental and Iterative Development”, STSC CrossTalk, May 2008; 21

(5): 27–30

[7] M. A. Weiss: “Data Structures and Algorithm Analysis in C++”, Third Edition. Addison-Wesley,

2006.

Picture reference

Figure 1: T. Johansson and S.Karlsson, ”Analysis for Automated Positioning of 3D-representation of a

Modularized product”, Linköping, 2012, page 10.







Figure 6: Wikipedia, The Free Encyclopedia,

http://upload.wikimedia.org/wikipedia/commons/a/ac/Iterative_development_model_V2.jpg (13

September 2006)


35 2013-06-03

Appendix A – The initial use cases and their level in chain

1. Read a list of composing module, that includes real modules, and features from .xml file

2. Calculate the position for each module and build the structure that is necessary to visualize the product

3. Write the necessary lines in a .smgxml file that will be used by the visualizer

4. Complete an error handler for modules that has no available interface zero

5. Complete an error handler for modules that has multiple interface points available

6. Make a template for platform structure and assembly structure

7. Read and analyze the configurator information to the program

8. Choose between working with verified or prototype data tables

9. Calculate what data tables that has to be read

10. Save what modules that has been selected from the data tables

11. Save the list of composing module and features to a .xml file

12. Analytic function that compare verified and prototype list of modules

13. Stress test for VB part


36 2013-06-03

FIGURE 21, THE CASES WITH THEIR LEVELS WITH THE ARROW REPRESENTING THE LIST OF COMPOSING MODULES


37 2013-06-03

Appendix B – Stress test code The following section contains the code that was used to compare performance between Excel cells

and arrays.

First part:

For SlaveCounter = 1 To No_of_Modules

Slaveinterface = Worksheets("Temp").Range("D" & SlaveCounter).Value

TempSlave = Worksheets("Temp").Range("A" & SlaveCounter).Value

For MasterCounter = 1 To No_of_Modules

No_of_interface = Worksheets("Temp").Range("C" & MasterCounter).Value

TempMaster = Worksheets("Temp").Range("A" & MasterCounter).Value

For InterfaceCounter = 0 To No_of_interface - 2

Tempintface = Worksheets("Temp").Cells(MasterCounter, 5 + InterfaceCounter * 7).Value

If Tempintface = Slaveinterface Then

Exit For

End If

Next InterfaceCounter

Next MasterCounter

Next SlaveCounter

Second part:

For SlaveCounter = 1 To No_of_Modules

Slaveinterface = Interfacenametest(SlaveCounter)

TempSlave = modulenametest(SlaveCounter)

For MasterCounter = 1 To No_of_Modules

No_of_interface = numberofinterfacetest(MasterCounter)

TempMaster = modulenametest(MasterCounter)

For InterfaceCounter = 0 To 4

Tempintface = Interfacenametest(MasterCounter)

If Tempintface = Slaveinterface Then

Exit For

End If

Next InterfaceCounter

Next MasterCounter

Next SlaveCounter


38 2013-06-03

Appendix C – Prioritization matrix

This section contains the initial prioritization matrix, not including the priority score. The score for each variable after the factor are; Time unit: 0 – 5, Level

in chain: 0 – 5, Priority: 0 – 10.

Name Use Case #

Time units

With factor

Level in chain

With factor Priority (1-5) With factor Total score

Read a list of composing module, that includes real modules, and features from .xml file 1 5 5 1 5 6 0 10

Calculate the position for each module and build the structure that is necessary to visualize the product 2 2 2 2 4 6 0 6

Write the necessary lines in a .smgxml file that will be used by the visualizer 3 1 1 3 3 6 0 4

Complete an error handler for modules that has no available interface zero 4 4 4 3 3 6 0 7

Complete an error handler for modules that has multiple interface points available 5 8 3 3 3 6 0 6

Make a template for platform structure and assembly structure 6 10 1 3 3 6 0 4

Read and analyze the configurator information to the program 7 3 3 1 5 6 0 8

Choose between working with verified or prototype data tables 8 3 3 2 4 6 0 7

Calculate what data tables that has to be read 9 6 5 3 3 6 0 8


39 2013-06-03

Save what modules that has been selected from the data tables 10 5 5 4 2 6 0 7

Save the list of composing module and features to a .xml file 11 6 5 5 1 6 0 6

Analytic function that compare verified and prototype list of modules 12 10 1 5 1 6 0 2

Stress test for VB part 13 6 5 3 3 6 0 8


40 2013-06-03

Appendix D – Code The code of the application has been uploaded on webpages presented in this section.

Modules AutomaticPositioning: http://ideone.com/uzmQLj

ClearAll: http://ideone.com/OGMgdr

FileInLocalFolder: http://ideone.com/0zkivG

ThreeDViaExport: http://ideone.com/xjabNt

Forms UserForm1 (Export XML): http://ideone.com/fdA3TW

UserForm2 (Module choice): http://ideone.com/g2B7Ym

UserForm3 (3DVia Composer): http://ideone.com/JslQwE

UserForm4 (Interface choice): http://ideone.com/7zrLBj

UserForm5 (Structure choice): http://ideone.com/4xySmR


41 2013-06-03

På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –

under en längre tid från publiceringsdatum under förutsättning att inga extra-

ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,

skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för

ickekommersiell forskning och för undervisning. Överföring av upphovsrätten

vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av

dokumentet kräver upphovsmannens medgivande. För att garantera äktheten,

säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ

art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i

den omfattning som god sed kräver vid användning av dokumentet på ovan

beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan

form eller i sådant sammanhang som är kränkande för upphovsmannens litterära

eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se

förlagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible

replacement - for a considerable time from the date of publication barring

exceptional circumstances.

The online availability of the document implies a permanent permission for

anyone to read, to download, to print out single copies for your own use and to

use it unchanged for any non-commercial research and educational purpose.

Subsequent transfers of copyright cannot revoke this permission. All other uses

of the document are conditional on the consent of the copyright owner. The

publisher has taken technical and administrative measures to assure authenticity,

security and accessibility.

According to intellectual property law the author has the right to be

mentioned when his/her work is accessed as described above and to be protected

against infringement.

For additional information about the Linköping University Electronic Press

and its procedures for publication and for assurance of document integrity,

please refer to its WWW home page: http://www.ep.liu.se/

© Christian Larsson

http://www.ep.liu.se/

application development for automated positioning of 3d

Documents