DReS Robot Cell Simulator - Tools on the Robots: Attach, Change, Tool Change UP81 on All Robots (YouTube, English)
DReS Robot Cell Simulator - Werkzeuge an den Robotern: Anbauen, Wechseln, Werkzeugwechsel UP81 (YouTube, Deutsch)

Tools on the robots

When a cell is opened, the tools placed on the flanges in the study are attached to the robots. The column Attached to of the Model Browser and the list in the Work Zones tab show the current tool of every robot. Tools are changed by hand with the context menu of a robot or a tool:

• Attach to robot... – attaches the selected tool to a chosen robot,
• Detach, Detach tool, Detach fixtures – leave the tool (fixtures) at the current place,
• Attach default tool – restores the tool from the study.

Components that can be a tool (grippers, guns, docking systems, components mounted in the study) have a hammer icon in the Model Browser: gray = free, orange = attached to a robot, crossed out in red = changed in this session compared to the study. The default tool is the tool mounted on the robot in the study.

The dialog Attach sets the robot, Tool or Add fixture (e.g. a part in the gripper) and the mounting position on the flange (X Y Z, A B C). Buttons fill in the position:

• Position from the study – the mounting position saved in the study,
• Keep the position in the cell – the component stays exactly where it is in the view,
• Model origin on the flange – only when the origin of the tool model lies on the flange,
• Same as the current tool – the position of the previous tool.

Check the result by moving A6. When the study contains a complete mounting chain (tool changer → adapter → tool), the whole chain is attached automatically. The robot menu in the Work Zones list offers the same functions: Attach a tool... / Change the tool..., Add a fixture on the flange..., Detach tool, Show the tool in the model tree, Attach default tool.

Detaching all tools and attaching the default tools of all robots is in the Auto-Docking tab.

Tool model from a JT, glTF, STL or STEP file

The context menu of a robot (Model Browser) has the entry Tool model (JT / STEP / STL / glTF).... The dialog asks for:

• Model file – the JT model of the tool (e.g. a spot welding gun), or a glTF 2.0 (.gltf with its .bin, or .glb), binary STL (.stl) or STEP (.stp, .step) file; ... opens the file dialog in the folder used last,
• X Y Z [mm], A B C [deg] – the position of the model origin relative to the KUKA flange ($FLANGE, KUKA ABC; 0 = the model is in the flange frame). This is the mounting position, not the TCP ($TOOL_DATA): in a Process Simulate study it is the mountLocation (mm) / mountRotation of the tool (welding guns on a tool changer usually Z 38, A B C 0). The CAD flange of the KUKA robot model is turned by 180° about Z; the simulator converts the position itself,
• Additional element on the flange (fixture, e.g. tool changer) - the tool stays – without the checkbox the model is the tool of the robot: it replaces the tool on the flange and a dummy tool is removed; with the checkbox the model is an additional element (fixture) and the current tool stays.

The tool model is used for the work zones and the 3D collision check like any other tool. When the robot already carries a tool model, the dialog opens with its file and position, so the position can be corrected. The Message Window shows the mounted model with its position and the path of the file.

One model once, no dummy with a model. The same model (the same name, or a name that starts with the other name at an underscore) is never mounted twice on a robot: the API tool_model returns an error that names the mounted elements (replace: true replaces it), and the robot menu Remove duplicate models keeps one (the element of the study first). A robot with a 3D model of its tool has no dummy tool.

Mounted elements. The robot menu Mounted elements has a submenu for the tool and for every fixture: Hide / Show (the model is hidden or shown; saved with the simulation and the package) and Remove from the robot (a model from a file is deleted from the scene, an element of the study stays hidden). A hidden model stays in the collision checks; only a removed one is no longer checked. API: tool_info, tool_remove, tool_hide, tool_show.

The tool model is saved with the simulation (Save simulation...: element Docked with the path in the attribute jtFile, also for glTF / STL / STEP files) and with the session (attached[].file): on load the model file is inserted again and the model is mounted with the saved position. Relative paths are resolved also when the simulation package was moved to another folder; a file that cannot be found is listed in the Message Window.

Example: a spot welding gun EuroX on robot R5 – the origin of the JT model lies 38 mm behind the flange, so the position is X 0, Y 0, Z 38, A B C 0. The TCP of the robot ($TOOL from the robot archive) then lies on the tip of the fixed electrode; check it with robot goto in a weld point (see below) or by moving A6.

glTF, STL and STEP: the model must be in the same coordinate system as the JT model (e.g. converted from the JT file), then the position on the flange is the same as for the JT file (e.g. Z 38). glTF 2.0 keeps the colors of the parts (the original JT color extras.jtDiffuse written by the converter jt2step, otherwise the linear baseColorFactor of the materials converted to sRGB – the same colors as the JT model; parts of the same color form one part in the model tree); its coordinates are in metres with +Y up, as the glTF standard says, and are turned into millimetres with +Z up. Supported: triangles (mode 4), float positions, normals, 8 / 16 / 32-bit indices, node matrices and translation / rotation / scale; files with required extensions (e.g. Draco compression) or sparse accessors are refused with a message. A glTF or STL file is used triangle by triangle (a welding gun with 800 000 triangles in about one second) – STL has no colors, the model is shown in one color. A STEP file made only of triangles (faces with a POLY_LOOP of 3 points, e.g. converted from JT) is read directly (about 30–60 s for 500 000–800 000 triangles); any other STEP file is triangulated like the robot models of the library (linear deflection 1 mm), which takes very long for large models. The triangles of the file are used for the work zones from triangles and the Live 3D collision check, like the triangles of a JT model. The Message Window shows the number of triangles and the reading time. In one session the model is read only once. Only the finest triangles of the file are used, while a JT model also brings its simpler levels of detail (all of them are used by Live 3D) – the results of a JT model and of a STEP / STL copy can therefore differ slightly. The JT and the STEP / STL model of the same name are different components (id TOOLMODEL_<robot>_<name>_stp, _step, _stl, _gltf or _glb).

By a script or the AI agent: the command {"cmd":"tool_model","robot":"R5","file":"D:/.../gun.jt","pos":{"x":0,"y":0,"z":38,"a":0,"b":0,"c":0}} does the same as the menu entry: the model is inserted and mounted on the flange, it replaces the tool on the flange (a dummy tool is removed) and it is saved with the simulation and the session; "fixture":true adds it as a fixture. The same command without file only moves the tool model already on the robot to a new pos. To check the tool, {"cmd":"robot","robot":"R06","goto":"UP42/P17"} puts the robot in a point of the program (e.g. a weld point) without running the program; the answer of robot contains the tool on the flange (tool: id, name, x..c) and the flange position in the scene (flange: [x, y, z] mm, e.g. as target of view to zoom on the tool). A tool model made of several parts (e.g. a welding gun) keeps the position of each part from the JT tree. Details: command API, AI Agent window.

Insert robots at study positions

File → Insert robots at study positions... inserts the robots of the study from their archives at the positions saved in the study. The archive of every robot is linked automatically: a folder or a ZIP file with the robot name in the study folder is taken, also when the name has a suffix after the robot name (e.g. ...r01rs--kux). A ZIP file is extracted to the user cache folder (the files of the user are not changed; it is extracted again only when the ZIP file is newer). The linked archive is shown as a small archive icon in the second column (Attached to) of the Model Browser next to the robot; its tooltip shows the folder or the ZIP file of the archive (and the folder it was extracted to). A robot that cannot be simulated is inserted as a gray model, see Robots that cannot be simulated.

The SPS program (tab SPS) is kept in the settings, so after the insert it may still be the program of another station. When no robot of the SPS program is in the cell, it is replaced by a new program with the robots of the cell (like New from the robots of the cell; the console writes a warning with the old robots). When only some robots of the program are missing, the program stays and the console warns which robots are not in the cell – check the program (SPS > Edit).

After the insert the base check runs automatically: the bases of the study are compared with the bases in the robot archives and the result is written to the console (the summary of the insert names the number of deviating bases).

Check bases against the study

File → Check bases against the study... compares the bases of the Process Simulate study with the bases in the robot archives. The study holds the nominal values, the archive the measured values (calibration of the table or of the station base, e.g. the zero of the car on the station). A large deviation means that the fixtures of the study and the points of the archive do not match there – the simulation of a robot then runs at another place than the robot in the cell.

• Study: the frames at the robot element ir_<robot> of the study (systemFrames) – KUKA robots: frames b1, b2 ..., Fanuc robots: user frames uf1, uf2 ...
• Archive: KUKA $BASE_DATA[n] from $config.dat, also bases of an external TCP (base type #TCP, a tool on a stand); Fanuc user frames UF[n].

The check is taken against the study from which the robots were inserted (Insert robots at study positions); without it the program asks for the study file. The window has these fields:

• Tolerance position (default 2 mm) and Tolerance rotation (default 0.2 deg) – a base with a larger deviation is marked as a warning.
• Report: Project, Place, Customer, Team, Station, Comment – shown in the head of the report and remembered for the next report; Report with the current 3D view adds a picture of the 3D view as it is now.
• Check saves the tolerances and checks the bases – the result is in the console, a short window says when the check is finished; Check and save report... also saves the report as PDF or HTML (chosen by the file extension) and opens it; Cancel closes without checking.

The console writes one line per robot and base: the deviation of the archive from the study in mm (X, Y, Z in the robot coordinates) and in degrees (warning above the tolerance), one line for every common base of the station and a summary.

Report (in the style of the reports of the VKRC / VFanuc Calibration plugins): logo from the print settings, head with the project data, date, study and tolerance, a short explanation and the tables:

• Bases of the robots – per robot and base three rows: study (nominal frame), archive (measured frame) and difference, each with X Y Z [mm] and A B C [deg]. KUKA: relative to the robot base like $BASE_DATA; Fanuc: relative to the world of the robot like UF. Then |d| [mm] (length of the position deviation), Rotation [deg] (angle between the two orientations) and OK / check against the tolerance. A base of an external TCP is shown as n (ext. TCP), a Fanuc user frame as UF[n].
• Common bases of the station – bases of different robots that lie at the same place in the study (closer than 1 mm, the number of the base can differ between the robots), e.g. the zero of the car for all robots around the station. Spread [mm] shows how far apart the archives of the robots place this base (Largest between: the two robots with the largest distance) – a spread above the tolerance means that the base of a robot or the position of the robot in the cell is not measured correctly.
• Robots of the study that are not in the scene are listed under the tables; optional: the 3D view.

License: the check of the bases (menu, automatic check and API) needs the base license of the Robot Cell Simulator (140).

API: command base_check (tolerances, report fields, report file, result as JSON). See also the VKRC Calibration plugin (measurement of the table with the points of the labels MBxx X/Y/Z and a measuring spike). A measurement of the table with measuring points directly in the Robot Cell Simulator is planned.

Fanuc robots (VW standard)

Since 2026-10-20 the simulator also takes Fanuc robot archives. A robot archive that contains system.va and .ls programs but no $config.dat is recognized automatically as a Fanuc archive (VW standard) – when it is loaded from the simulation file (ArchiveRobot), with File → Insert robot from archive or when a session is restored. For the simulation RCS translates the archive into a substitute KUKA archive in the user cache folder %LOCALAPPDATA%\DrAmaT\dres_<version>\cache\RCS_fanuc\<robot>; the files of the Fanuc archive are not changed, and the simulation file and the session keep the path of the Fanuc archive. The console of the load writes Fanuc archive - translating the programs for the simulation, then the robot type and the number of programs and points. How the programs are translated and what is not simulated: Fanuc programs in the simulation.

• Kinematics – from SYMOTN.VA (DH data of motion group 1). The conversion of the axes between Fanuc and the KUKA model is exact (the same kinematic model) and is checked at every load; when the check fails, the robot is not inserted (error in the console). In addition, the kinematics is checked against the position stored by the controller in SYMOTN.VA ($MCH_ANG, $MCH_POS, $UTOOL): when the model does not match (e.g. a Fanuc robot with a parallel link of a type not yet confirmed) or the controller data are missing, the robot is inserted not simulated.
• Parallel link (M-900) – the Fanuc M-900 robots with a parallel link M-900iA/260L, M-900iB/280L and M-900iB/400L are simulated: the offset of the forearm is confirmed with the position stored by the controller and with the CAD model, and the library contains their 3D models. Other parallel-link types stay not simulated until they are confirmed.
• Travel track (axis 7 of group 1) – simulated as a linear unit E1 along the X or Y axis of the world. The direction of the track is taken, in this order, from
  1. the position stored by the controller in SYMOTN.VA (the controller position is shifted exactly by E1),
  2. when the controller position gives no direction (E1 stands near 0, or the axis angles and the stored position come from different moments), the controller configuration $SCR_GRP[1].$EXT_XYZ_MAP (1 = X, 2 = Y, 3 = Z, positive direction),
  3. only when that is missing too, the robot type in the Process Simulate study (e.g. a type ending with _7ACHSE_Y+).
  Steps 2 and 3 are used only with the option Deduce the direction of the travel track (axis 7) of a robot that has one (plugin settings → Simulation, on by default, see Plugin settings > Simulation). Every deduced direction and every disagreement between controller position, controller configuration and study is written to the console as anomaly: ... – check these lines before relying on the results of the robot. E1 of the points moves the robot; the console of the load writes the direction of the track and the E1 range. When no direction can be found (or the option is off and the controller position does not confirm it), the robot is inserted not simulated with the measured shift as the reason.
• Drawing of the travel track – when the Process Simulate study has a model of the track (mechanism .m in the study library), that model is shown. Without a CAD model of the track RCS draws it as a transparent box over the software limits of E1 (+500 mm): the + direction red, the - direction blue, a cross bar at E1 = 0 and the frames $ROBROOT (at E1 = 0) and $ERSYSROOT.
  

  Fanuc robot on a travel track without a CAD model of the track: transparent box over the E1 limits, + direction red, - direction blue
• Signal descriptions – the comments of the signals in DIOCFGSV.IO (comment tables with signal type and index) are used as the long texts of the robot: DI n = E n, DO n = A n. The interlock map finds the partner robots from them, e.g. DI 41 "L.Ant.1>R1" = release from the partner robot R1. Without the file the console warns DIOCFGSV.IO not found - no signal descriptions for the interlock map.
• Tools and bases – UT n = tool n (UT 0 = tool 32); UF n = base n+1. The Fanuc world lies $MOUNT_LOC.Z above the robot foot.
• Points keep X Y Z W P R; the arm configuration comes from CONFIG (turn numbers included). Points taught as joint positions are converted too.
• Not supported mounting – robots not floor mounted ($MOUNT_ANGLE), with $MOUNT_LOC not only in Z, without DH data or not 6-axis are not inserted (error message); robots on a travel track that the controller position does not confirm are inserted not simulated – the simulator never calculates such a robot with missing data.
• 3D model – the library model from cad.rcc is chosen by the robot type ($SCR / version ROBOT_ID, e.g. R-2000iB/210F, R-2000iC/210F, R-2000iC/270F, M-900iA/350, M-900iA/260L, M-900iB/280L, M-900iB/400L). The Fanuc models have no reference data, so their dimensions are not compared with the archive – the simulation uses the kinematics of SYMOTN.VA. Other robot types get the kinematic model (no CAD).

Robots that cannot be simulated

A robot whose positions cannot be calculated correctly is shown in the cell, but never simulated with wrong positions. This is the case for

Model tree: R9 is gray, with the no-entry icon and the short reason in the second column (the tooltip shows the full reason and what to do)

The same cell in 3D: R9 stands as a gray model in the zero position at its place in the study – for the layout only, no motions, collisions or times are calculated for it

• a robot on a linear unit (group 1 axis 7) whose track direction is not known – a Fanuc travel track is simulated as linear unit E1 when the position stored by the controller in SYMOTN.VA is shifted exactly by E1 along the X or Y axis of the world, or (with the option Deduce the direction of the travel track (axis 7) of a robot that has one) when the direction comes from $SCR_GRP[1].$EXT_XYZ_MAP or from the robot type in the study; the reason shows the measured shift (or that axis 7 has no position, stands near E1 = 0 or has no software limits in the backup),
• a robot whose kinematics does not match the position stored by the controller – e.g. Fanuc robots with a parallel link of a type not yet confirmed (confirmed and simulated: M-900iA/260L, M-900iB/280L, M-900iB/400L): the position calculated from the controller axis angles differs from $MCH_POS,
• a backup without controller data in SYMOTN.VA ($MCH_ANG / $MCH_POS / $UTOOL) – the kinematics cannot be checked.

Such a robot is inserted as a static gray model with the title <archive> (not simulated) in the zero position at its place in the study. The Model Browser shows a red no-entry icon and the short reason in the second column (Attached to), e.g. not simulated: linear unit (axis 7) not confirmed or not simulated: kinematics differs by 500 mm; the tooltip shows the whole reason. Its programs are not loaded, and the robot is not part of the runs, the interlock checks and the reports; the summary of the insert counts it as not inserted. When the robot is selected in the Model Browser, the Message Window writes the full reason – the values of the controller (axis angles, position calculated by DReS and position reported by the controller) and what to do (e.g. use a complete backup).

What this means for you:

• The gray robot only shows the layout of the cell. No collisions, zones, cycle times or reports are calculated for it, and it never moves.
• Partner robots that wait for its signals (interlock releases, handshakes) wait in the simulation, or are released by the options of the run – such waits for a robot that is not simulated are not program errors of the partners.
• To simulate the robot: load a complete backup (with SYMOTN.VA and the controller position), use a robot of a confirmed type, or – for a travel track – switch on the option Deduce the direction of the travel track (axis 7) of a robot that has one and load the robot again.

DReS Robot Cell Simulator - Move the Robot by Hand: Axes, Cartesian Jog, 7th Axis (YouTube, English)
DReS Robot Cell Simulator - Roboter von Hand verfahren: Achsen, kartesisch, 7. Achse (YouTube, Deutsch)

Robot Axis tab

The tab moves the current robot (selected in the Model Browser). The sliders and spin boxes set the axes A1–A6 and the linear unit E1 within the limits from the machine data. The robot follows immediately in the 3D view. Keep TCP position when moving E1 compensates the 7th axis: the TCP stays in place while the robot moves along the linear unit. Show TCP coordinate system and Show base coordinate system draw the frames in the 3D view.

Cartesian jog

The group Cartesian (TCP) shows the TCP position in the selected Tool and Base (tool and base data from $config.dat of the robot archive). The buttons − / + move the TCP by the Step in X, Y, Z or rotate it around A, B, C; a value can also be typed directly. The status S and T of the current position is displayed below.

Current robot with the TCP and base coordinate systems

The current position can be written to a program point with Touch up.