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.

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:

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.

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.