A first draft of position teaching has been created in a design phase of the test creation process. Before starting to create a robot program from the test, it is recommended to perform a step test from the taught positions according to position sequence table. This way it can be ensured that the taught positions are correct, and no transitional positions are needed. Positions can be added to position files at any time with Teach positions utility. Example test program is represented as a whole in appendix 4.
FIGURE 31. First part of the example robot program.
The first part of this robot program is a “Connect” subVI. It initiates the robot connection, so that other methods can use the robot object. The second rou-tine is the starting of MATS user panel.” Start MATS User panel” subVI starts event monitors and updates the MATS user panel.
The first Move to subVI drives the robot to a safe position above the work-bench 1. This movement is added because it is not sure where the robot is inside a work area.
Motions that push the power key are placed inside a while loop structure. This way the push motion can easily be repeated for 30.000 times. The push mo-tion is formed from two posimo-tions. The first one is located above the power key, and the second is the position where power key is pushed down. When the robot moves between these positions it creates the push motion
When the “Loop counter” subVI is given the wanted cycle amount and the loop iteration as an input, it gives a Boolean output value that can be used to stop the loop when desired amount of cycles have been performed. The “Loop counter” also calculates the estimate how long this particular loop runs, and updates the time information to user panel.
FIGURE 32. Second part of the example robot program.
When the loop iteration is 30 000 the stop condition is set to true. After this the robot is driven to a safe position above the workbench 1. “Send email” subVI sends an email notification for the test operators. Email receivers are de-terminated in MATS user panel. “Dialog box” subVI stops the program execu-tion. It reserves the robot reference and lets the operator to change the posi-tion of the test object. Program execuposi-tion continues when the operator pushes button from dialogue box that pop ups when program execution reaches the
“Dialog box” subVI.
FIGURE 33. Last part of example robot program.
This section of the robot program is copied from the first loop. Copying similar code segments with LabVIEW is easy and saves time. Pushing operation the same as in the first push operation. This time volume up key is pushed for 300 000 times.
The last Move to subVI drives the robot to a safe position above workbench 1.
“Finalize” subVI closes the robot connection and event monitors. It also sends a notification email for the operators. After the test program is created, it can be tested with low speed. The speed can be controlled with the teaching pen-dant. Testing of the robot program ensures that the robot performs all needed operations correctly.
5 RESULTS
An outcome of this thesis is a working test creation environment that utilizes an industrial robot. The environment can be easily modified if new hardware components are introduced. The test creation environment is also easy to use as can be seen from MATS usability study from appendix 5.
The largest part of the work hours put to this project has been spent to con-necting FANUC Robotics R-J3 robot controller with LabVIEW. Trying different connection methods and interfaces before choosing the one described in this
thesis was very time consuming.
Another large time consumer was the creation of the LabVIEW subVIs in a way that the test programs would be easy to create. Figuring out the internal structure of PCDKs ActiveX components was the main duty in this part of the project. Correcting detected structural faults from LabVIEW code took equally much time. This time was largely lengthened by the fact that there were no earlier studies or examples published about this subject. Additionally inade-quate PCDK documentation caused few bad surprises and even development halts.
The creation of LabVIEW programs for position teaching and robot monitoring was an easy task after the structure of the ActiveX components was resolved.
Some consideration was put into usability and alteration of the user interfaces of these programs after user experiences had been received.
Integrating LabJack U6 data acquisition card to the system was straightfor-ward task because LabJack provided compatible LabVIEW functions in the package. It only took a small time to convert these functions to look like sub-VIs that I had created for the robot. This way test designer will not get con-fused about the different structure of the data acquisition cards LabVIEW sub-VIs.
The last part of the project was the documentation. This documentation on my part included writing the software and hardware user manuals, LabVIEW sub-VI list with functional descriptions and an annual maintenance table.
6 SYSTEMS FUNCTIONALITY AND USABILITY
The functionality of the test creation systems software was verified by creating and running test cases that resembled actual tests. The tests cases were sim-plified in a way that robot did not affect any actual objects. This way it could be assured that occurring faults were caused by the system's software and not by
the hardware parts.
The test system was left to perform a test for a weekend. On Monday it was verified that the test was still running. This ensured that there were not any software crashes or malfunctions during the weekend test session. Some of the test runs were interrupted by system crash, but crashes were caused by faults in the test program design, not in the system software itself.
LabVIEW’s and robot server's memory consumptions were written down in the first cycle of the weekend test. These figures were then re-checked after the weekend, and verified that they were not above the normal levels. This test ensured that LabVIEW functions and subVIs did not leave any unclosed ob-jects in the computer's memory.
The overall usability was verified by interviewing the person who uses this system. A form was created that consisted of questions about the usability of the system. The answers of this questionnaire can be seen in the appendix 5.
These results can not be used widely because only one person has taken the test. However the usability of the system can be verified from the results.
There is no real need to create more accurate tests about the software's func-tionality at this point of the system development. For the employer, it was enough that the system works as requested.
7 REQUIREMENTS
This thesis project was a very challenging task for me. At the beginning every-thing looked fairly simple. The first time estimation for the completion of the project was three months. In the end this project took about a year. A major part of it was part time work, done during studies. People at the Cassidian Fin-land were flexible and gave the author more time and resources. Thanks to them, the end product of this thesis is a functional and an easy to use me-chanics automated test system.
I had some robot studies in the university before this project, but they consist-ed mainly of robot programming and light peripheral communication exercises.
The university had no Fanuc robots available for learning. For this thesis I had to examine and learn the functionality of the R-J3 controller very deeply, much deeper than I even knew was possible from my classes. I took part in the me-chanical maintenance and troubleshooting operations that had to be done for robot before it was functional.
I also learned the TP language that FANUC normally uses for robot program-ming. I used this language early in the project to test the robot's functionality and capabilities of the peripheral devices. I created robot programs with TP language with FANUC's offline programming applications and Teaching Pen-dant. I also learned a bit of VisualBasic programming language while interpret-ing FANUC’s PCDK program examples.
One significant thing that I learned during my thesis project was the
knowledge acquisition from different sources, and making the decisions and interpretations early on based on this knowledge. After the first two months working in this project I understood that there were no persons or documents available who could explain how get LabVIEW and R-J3 controller to com-municate. People at the Cassidian Finland did not know that much about ro-botics, and people at the Finland's FANUC importer Fastems did not know much about LabVIEW robot applications. Combining the knowledge from all the sources and applying it to this project was a skill that I learned.
Lack of publications about this subject added a great number of difficulties to the project. There were only some different forum discussions where was mentioned that someone somewhere in the world had controlled a FANUC robot with LabVIEW. Everything else was up to me to learn and to discover.
The referenced actions of learning and discovering are actually a small under-statement when talking about the knowledge that I absorbed from PCDK's and LabVIEW's combined functionality. It was not enough to find out material and then apply it to the system. I had to really internalize the information about the
PCDK's structure, and then use this information in a way that FANUC, Nation-al Instrument nor any other source have documented, or at least published.
The useful issue in my education was the LabVIEW experience I had from many of the courses. We never actually handled ActiveX components with LabVIEW but still the existing LabVIEW skills helped. Additionally the idea of a robot being just another programmable machine came from university studies.
During school exercises I discovered that there was nothing difficult about ro-bots. It is basically just a computer with an arm. This mentality helped a great deal during this project.
8 CONCLUSIONS
8.1 General
The project that this thesis describes was quite different from “traditional” robot applications. Usually industrial robots perform particular programmed task for long periods of time without any need of reprogramming. They may react to sensor and vision information; however the same program might be used for several years without any changes.
In this project the goal was almost the opposite of traditional robot program-ming. A whole test creation system had to be created that would be modular and highly adaptable because one test case might only be performed once.
Every new fault or mechanics detail would need a new test program to be cre-ated.