The post FAQ OLP: CAD Editor appeared first on Convergent Information Technologies.

Q: Can I name 2 or more entities identical?

A: No. Each CAD, each obstacle, each part, each scene, each setup, each workflow must have a unique name.

The post FAQ OLP General appeared first on Convergent Information Technologies.

The post FAQ OLP – Cell / Scene appeared first on Convergent Information Technologies.

Saving project failed: boost:filesystem::copy_file:

Q: When I try to store the .ap project file, the SW shows the error message “Saving project failed: boost:filesystem::copy_file: Der Prozess kann nicht auf die Datei zugreifen (the process can not access the file) …. [system:33] ..\…\project_xy.ap …. An error occured while saving the Project. What happened here? Can I fix it?

A: That is a problem with too large files. Even though AUTOMAPPPS compresses its .ap project-files, if you load several CAD or sensor-datad between 200 and 500MB, the resulting compressed .ap file can get large as well. If the .ap file gets larger than 500MB, chances are python boost has problem in storing. Open C:/user/username/AUTOMAPPPS/temp (or /AUTOMAPPPS_demo/temp or AUTOMAPPPS_xy – depending on the SW version you are using) contains files with the cryptic naming auch as “Projectde6-7507-2824-cda8” or similar. Look for the larger ones, 0.5GB. 1.0GB… Open it in AUTOMAPPPS. Delete some big sensor (ply or similar) file or huge STL or STEP recently added and try if you can now safe it regularly. Reload the files (if needed after reducing details, remeshing or similar size reduction)

Problems with planning a workflow

Device “ExternalAxis” is not allowed to have an enabled end action because it is an auxiliary device for a device which has no end action

The situation is that the robot is mounted at an external axis or is controlling the external axis and the external axis had a defined end configuration (action) and the robot had not - or the robot also had an end (home) configuration but the action was by accidend disabled. The key is that all "associated" robots and axis should be the same with respect to end action or no end action.  

The post FAQ OLP Trouble-Shooting appeared first on Convergent Information Technologies.

Q: I did change the home-configuration of the robot in the robot editor. However, in the workflow the “home-configuration-action” is unchanged.

A: The home-configuration that is used per each robot (in the workflow) is the home-configuration in the scene / cell that is used in in the workflow. Update the home-configuration in the scene and you will find it updated in the workflow as well. Why is that? Usually in multi-robot cells the robots (which are often mounted symmetric) do not have the same “home” but often each robot has its own home-pose.

Device `Linear´ is not allowed to have an enabled end-action because it is an auxillary device for a device which has not end action

The planning (or calocation of the feasability maps is terminated with the error message “Device `Linear´ is not allowed to have an enabled end-action because it is an auxillary device for a device which has not end action."

See also the image below for the error message.

Image:

The reason is the following. The device with the name Linear is a linear module to which the robot is mounted. It is planned together with the robot. It is also linked to the robot, so the exporter will export the axis values together with each motion step of the robot program as external axes values.

The devide Linear is planned actively and has an end-action (see 1). The Fanuc robot to which it is assigned to however has no end action (see 2). It can also be that the robot has an end-action but it is de-activated. It can also be the other way around that the axis Linear has no end-action.

In any case, robot and associated active devices shall be consistent with startactions and end-actions.

Image:

I changed the HOME in the robot editor, but in the workflow the old one is used

The home defined in the “robot editor” will be used for all robot cells / scenes created in the future as default. If you change it, it will not overwrite the HOME in existing scenes of individual robots.

Image: Defining the home in the robot editor

It is best practice in robot programming to define in each scene (each robot cell), the HOME pose of each individual robot, e.g. to consider symmetries of different mounting poses of the robots. See image below.

These individual HOME settings are used in the workflow. Changing the default value in the robot editor therefore has no consequence. You have to change them in the scene.

Image: defining the HOME-pose of the robot in the “scene editor”: Change the joint values and then press “set home configuration”.

The post FAQ Workflow – Robot offline programming appeared first on Convergent Information Technologies.

The exported robot program uses “mm” for the external rotation axis instead of “deg” degree.

In case of a FANUC “.ls” robot program it would look as follows for a linear motion point. The external axis E1 is however a rotation axis.

P[113]{
GP1:
UF : 1, UT : 1, CONFIG : ‘N U T, 0, 0, 0’,
X = 4402.896 mm, Y = -2677.32 mm, Z = 2690.996 mm,
W = -30.559 deg, P = 9.583 deg, R = -95.614 deg,
E1= -26.586 mm
};

If your exporter does not directly support switchting to deg for the given rotation axis you can have the exporter automatically modify the exported text also in the exporter setting.

Step 0: Open the “Workflow” Editor. Step 1: Select the robot “Parameters”. Step2: Add a “Text modifyier”. Step 3: Select “Regular Expression” and edit the “text to be replaced” and the “replace with”. In our case of the FANUC program exporter:

Search for: “E1=(.*?)  mm”

Replace with: “E1=$1 deg”

WARNING:

One warning though: If your rotation module is already supported and its values are correctly exported in degree, the text-replacement can have an unexpected side effect: It collects E1= and mm beyond several command lines of the robot program. This converts:

P[136]{
GP1:
UF : 1, UT : 1, CONFIG : ‘F U T, 0, 0, 0’,
X = 3714.904 mm, Y = -2037.529 mm, Z = 937.005 mm,
W = -0.085 deg, P = -86.669 deg, R = 150.35 deg,
E1= -79.611 deg
};
P[137]{
GP1:
UF : 1, UT : 1, CONFIG : ‘F U T, 0, 0, 0’,
X = 3676.824 mm, Y = -2015.773 mm, Z = 959.199 mm,
W = -0.085 deg, P = -86.669 deg, R = 150.35 deg,
E1= -79.611 deg
};

into

P[136]{
GP1:
UF : 1, UT : 1, CONFIG : ‘F U T, 0, 0, 0’,
X = 3714.904 mm, Y = -2037.529 mm, Z = 937.005 mm,
W = -0.085 deg, P = -86.669 deg, R = 150.35 deg,
E1= -79.611 mm
};
P[137]{
GP1:
UF : 1, UT : 1, CONFIG : ‘F U T, 0, 0, 0’,
X = 3676.824 mm, Y = -2015.773 mm, Z = 959.199 mm,
W = -0.085 deg, P = -86.669 deg, R = 150.35 deg,
E1= -79.611 deg
};

The post FAQ Robot Exporter appeared first on Convergent Information Technologies.

Preconditions: obstacles, robots, conveyors/axes, workpieces and tools have been created/imported

The video is embedded by YouTube and only loaded and played from there when you click on the play button. From then on, the privacy policy of Google applies.

Step 1: create a new scene, i.e. commonly a workcell. Alternatives would be to copy one already existing in the same project/database or to import from another project / database. Assign a name to the scene.

Step 2: Define one initial safety distance between entities in the scene, such as tools, robots, workpieces, obstacles against each others. Safety distances for specific entities –like tool vs. work-piece, can be changed individually later. Note: collision pairs, that can not collide in the scene, such as joints or bases of the robot against (remote) obstacles, or static obstacles against other ones, are set to [void] automatically.

Step 3: Add elements to scene. Such as robots, obstacles etc. In the case of the image below, 2 obstacles have been added.

Step 4: Then add robot to the robot cart.

If you select the cart and then add the robot, it is assigned to the cart, and if the cart has a mounting point, the robot might be positioned correct right away. Potentially the robot (its base) must be re-posistioned. The base of the robot is not collison tested against the cart, since it is “connected” in the tree-representation.

If you still have selected the scene, the robot is added in the tree-representation to the scene, not to the cart.

Step 5: Add the tool to the robot in tha same way —from the list of tools in the project. Note: the tool will by default be connected with its Flange-pose (if define) to the robots-flange. You can modify this transformation afterwards. For part-in-hand applications, the part is attached to the robot (with a gripper inbetween) and the tool is attached to an obstacle, table, etc.

Step 5b: The orientation of the tool can be changed by edit -> set transformation. The defined transformation will be visualized after “apply” (alternatively after OK).

Step 6: Select the work-piece. Note the fist entity selected and added to the scene is initially attached to the scene- graph at the root. Assignments inside the hierarchy can be changed later in the scene graph by drag-and-drop.

The post Scene Editor – building up the robot cell appeared first on Convergent Information Technologies.

How to export the robot program

How to deal with the export parameters (linear motions vs. ptp, Object-frames, references), select the program style (“all in one” , “one-sub-program per action”). and so on.

The post Export robot programs appeared first on Convergent Information Technologies.

Actually, for pick-and-place two methods are implemented.

A eays and intutive – guided procedures – inspired by programming cobots in their cell. A look and feel of teaching a collaborative robot – just inside the virtual cell. And with modern features such as more optimal, collision-free motions planned. Or defining a orientation in case liquids or delicated parts are handled.

An expert mode – deerived from our automatic bin-picking. Define grasp and release points at parts to be handled and shelfes, pallets etc. in the environment. Than assign which point of the part is to be moved to which point in the environment – and in which order.

More comming soon

The post Overview / Introduction appeared first on Convergent Information Technologies.

This document explains how to make the virtual world identical to the real world. It describes how to match the part´s pose in the real and in the virtual world. That is to align the the part-robot transformation in the virtual cell as it is in the real cell. The procedure can be done for all objects inb the cell, but commonly only the relation of the robot to the part to be processed is modelled that preciseley. All other objects poses originates from CAD or Layout or is measured and larger safety distances are added.

Step 1: Measure the position of the calibration points in the real cell with the robot:

Select three points on your real workpiece which can be easily reached by the robot and which are not co-linear. The best would be if these points are sharp corners and therefore can be accurately approached by a probe tip tool. Equip your robot with a probe tip tool and take care that the tool center point is correctly defined. Move the robot with the tip of your tool to these three previously selected points. Write down the Cartesian position (which is calculated by the robot controller) for each of these three points. Now you have the X, Y and Z coordinates for these three points in the base coordinate system of the robot.

Step 2: Mark the points at the workiece inside AUTOMAPPPS:

Open the “CAD” editor and select the model of your workpiece.

At the sidebar at the right side of the application open the “Reference Points” tab. Press the “Add a reference point” button for each of three calibration points. Assign a meaningful name to the added reference points like CalibrationPoint1, CalibrationPoint2 and CalibrationPoint3.

Change the transformation of the reference points in a way, that they match the positions of the workpiece you “touched” with the robot in the real world before. This may be done by editing the position values of the translation text control elements of the Transformation widget or by using the object manipulator which is show in the 3D window when a reference is selected. And easier method is to set the “Control Mode” parameter to “Snap to Vertex” or “Snap to Mesh”. This allows you to specify the position of a reference point by clicking with the left mouse button and the CTRL key near the desired position of the part (the same as the robot touched) and the next CAD edge or vertex is selected.

Step 3: Include the poses measured by the robot into the scene in AUTOMAPPPS

Add an arbitrary CAD object to the CAD models editor (e.g. a boy) which will be afterwards temporarily added to the scene. Again add three reference points to this CAD model and use a meaningful name for this reference points. As transformation of the reference points you insert the measured values you got from the robot controller. These are the transformations of the identical points of the parts (which have been marked in the CAD file) but measured in real world by the robot.

Step 4: Alignment of real-world and scene

Select the corresponding scene. Temporarily add the newly generated obstacle (to which the measured points are added) to the scene. Change the position of this obstacle to the same position as the base coordinate system of the robot.

In the scene-tree select the entity of the workpiece with the right mouse button and select “Edit” -> “Align to”.

In the opened dialog select the “Align reference points to other’s”. In the “Align” choice widget element the workpiece should already be selected. For the “To” choice widget element select the newly added obstacle. Afterward press the Next button.

For the “Selected entity” and the “Reference entity” select the previously added reference points. Take care that the order of the selected reference points match. If all the reference points are given the Finish button is activated and have to be pressed.

If everything works fine the scene entity of your workpiece is correctly placed.

The post Align/calibrate virtual robot cell to real cell appeared first on Convergent Information Technologies.