Execution and results
Last updated
Last updated
A technical remark needs to be done before describing the procedure: the Excel sheets taken by the Python as an input are different than the use-interface sheets, the ones filled in by the assessor: in fact, they are directly linked to dual hidden sheets in the same file, structured in a way that is more easilly readable by the code. The Python code has two different versions, the first one named 'MOST_OCRA input loading.ipynb', an extended version divided in many cells, so to have the possibility to see all the intermediate results of the code, and the second one named 'MOST_OCRA input loading compressed.ipynb', where the entire code is put in one cell, so to have the possibility to quickly run it without taking care about the details. In both the cases the objective is to take the input activities in the sheet "MOST" of the Excel file just described, starting from the 'Type code' column, where the code understand which of the three sections it has to consider for that specific activity (G-T-C); basing on this, the next step is that of reading the correspondent numerical values inserted in the cells by the assessor and if the number is different than zero, a sub-activity is formed: for the specific scope of this link-code, a set of sub-activity names has been created, as already seen in the chapter 1 of this guide, and reported hereafter in the Table 1:
General move
Tool use
Controlled move
A
move empty
A
move empty
A
move empty
B
body motioin
B
body motion
B
body motion
G
pick object
G
pick object
G
pick object
A
move object
A
move object
M
move in contact
B
body motion
B
body motion
X
process time
P
place object
P
place object
I
align object
A
move back in position
F/L-C-S-M-R-T
tool action
A
move back in position
A
move object
B
body motion
P
place object
A
move back in position
So basing on this information and considering the cell at issue, the right name is found and stored to be given as an output. In the same time, the code also analyse the second input sheet, "Objects_weight", to find and link to the sub-activity just created the respective weight range of the tool or part used, if there is one. The last thing done by the code is to organize all the information gathered in order to give them as an Excel output easilly readable and compliant with the OCRA methodology: in fact the output file now is not again the input one, but it is a new file that is the Excel input of the OCRA methodology. Anyway the specific structure will be shown in the next chapter. For all the details regarding the python code it is possible to look directly at it, and specially at the comments done as an explanation of all the single steps.
In order to run the model, it was used Microsoft Azure Notebooks program with Python3.6 version.
Please, follow the next mandatory steps:
First of all it is necessary to open the code (the extention is .ipynb), and insert the right Excel file name in the first and the last cell of it, as shown in Figures 21 and 22:
The code must be run step by step in the same order in which it was developed if the extended version is choosen, while for the compressed version only one run command is needed;
Warning: the code is tailor made for this methodology, so be careful in modifying it, since all the modifications needs to be extended to the whole code in order to make it funciton;
Anyway this is an open-source toolkit, so any improvement to the code is very appreciated, following the objective of the VLFT project.
Observations:
The order in which the Input File was fulfilled, does not affect the result of the code.
If after running the model, this generates a message of error on Python, please go back to the Input File sheet and check that the data inserted are totally compliant with the guidelines expressed in this guide.
The final step of the model developed for the MOST-OCRA methodology is the downloading of the output Excel file modified by the Python code with the desired output: as already mentioned it will be different than the input one, in fact it will be the OCRA Excel input file, already structured with many sheets needed for that specific methodology. What this code does, is to create a new sheet in the file, called 'FPRpy', where the subactivities and their related information will be displayed. To have a clearer explanation of this, it is possible to look at the Figure 23:
In the first of the five columns, named 'TASK CODE', the code of the macro-activity considered is inserted, to give to the operator the possibility to have an idea of which point the process is while considering the different subactivities: this is very important since new columns have to be filled in aside these, and the assessor need to now which macroactivities are going to be considered;
the second column is called 'TASK NAME' and it is refered to the name of the macro-activity considered. It is directly related to the previous column, so it also has the same objective;
in the third column, 'TECHNICAL ACTION', the sub-activities names are displayed, divided per macro-activity, in line with the requirements of the OCRA methodology;
in the column 'MOVE TYPE' is put a code univocally indicating the sub-activity considered: two sub-activities called with the same name are considered as identical and so their Move Type will be the same;
the last column. 'ACTION DURATION', actually provides the time duration of the specific sub-activity in seconds, basing on the MOST methodology just applied, which responds in a good way to the OCRA needs.
The final action required to the operator in order to set in the wright way these data is that of 'copying and paste' as values the five columns of the FPRpy sheet just analysed, in the first five columns of the sheet FPRdata, that are left black in the original format, as can be seen in Figure 24:
This is the final step for what regard the link between MOST and OCRA methodologies; of course now the implementation of the OCRA is required, and for this it is possible to look at the OCRA User Guide in this toolkit.
