Skip to main content

Offline Programming and Simulation: ROBOGUIDE, RoboDK, and NVIDIA Isaac

Offline programming creates, simulates and generates a robot program on a computer, away from the robot, for a specific robot arm and controller, and simulation is how that program and its cell model are checked before the robot moves. UTEC Industrial designs, engineers, machines, fabricates, and installs custom material handling systems for aerospace and heavy industry from its Spokane Valley, WA facility, integrating Allen-Bradley PLC and motion control with in-house CNC machining, heat treating, and stress relief. This article sets out what FANUC's ROBOGUIDE, RoboDK and NVIDIA's Isaac Sim are each documented to do, why a program that runs cleanly in simulation can miss its targets on a real robot, what calibration claims to recover, and where learned behaviors meet the gap between simulation and reality. In the chain design → engineering → parts machining → fabrication → assembly → weld fatigue → stress relief → drives → controls → tuning → monitoring, offline programming begins at design and engineering, depends on machined and fabricated parts matching their CAD, and is finished only when the program has been touched up, tuned and monitored on the built cell.

What is offline robot programming, and how does it differ from teaching at the pendant?​

RoboDK's documentation gives a compact definition: "Offline Programming means that robot programs can be created, simulated and generated offline for a specific robot arm and robot controller." The same guide says that "All Offline Programming applications require defining a reference frame to locate the object with respect to a robot to update the simulation accordingly." A 2012 review by Pan and co-authors at the University of Wollongong covers programming methods for industrial robots "including online programming, offline programming (OLP), and programming using Augmented Reality (AR)," and its abstract says "the complexity of programming remains one of the major hurdles preventing automation using industrial robots for SMEs." Only that review's abstract is used here.

A 1999 handbook chapter on industrial robotics standards by a NIST author ties the programming method to accuracy. It says most industrial robot applications of that time did not require high accuracy and repeatability, and that "manual teach programming is used for most of these applications, which eliminates the effect of the kinematic mechanism model errors." It adds that "a hybrid manual-teach-off-line programming technique is growing in popularity."

The next two sentences are engineering reasoning. A taught point is recorded where the real robot actually stood, whatever its kinematic model says, while an offline point is computed from the model and from the cell's CAD. Every difference between model and robot, and between the drawn cell and the built cell, therefore appears as a position error in an offline program, and the rest of this article follows that trade of model error for programming time away from the robot (RoboDK Basic Guide, accessed September 2026, Introduction and Reference Frames; Pan et al. 2012, abstract; Dagalakis 1999, pp. 447-459, Conclusions).

What does FANUC document ROBOGUIDE as doing?​

FANUC America's product page describes ROBOGUIDE as offline robot programming and simulation software and says ROBOGUIDE V10 "creates programs and simulates robotic workcells in 3D." It calls V10 a 64-bit application that supports "the importing and exporting of a wider variety of CAD models in greater detail," says "Virtual pendants can be displayed simultaneously for each controller," and lists VR playback of 3D simulation recordings. The page also says V10 eliminates the need for physical prototypes while reducing costs and improving accuracy; those are FANUC's marketing statements, made without a stated method, and this article does not treat them as findings.

Under ROBOGUIDE Classic V10 the page lists application packages. Three of them are quoted here, for material handling and for transfer of work to the real robot:

  • HandlingPRO "is used for material handling applications including load/unload, packaging, assembly and material removal," with "CAD to Path programming, conveyor line tracking, machine modeling and programming."
  • PalletPRO "can be used to completely build, debug and test a palletizing application offline," and its data "can be downloaded to a real robot controller containing PalletTool software."
  • WeldPRO: "Programs and settings from the virtual workcell can be transferred to the real robot to decrease installation time."

The page makes no statement about how closely a simulated position or a simulated cycle time matches the real robot. UTEC Industrial integrates FANUC robotic cells, including vision, with a FANUC design and engineering partner (FANUC America, ROBOGUIDE Robot Simulation Software, undated web documentation, accessed September 2026, ROBOGUIDE V10 key features and ROBOGUIDE Classic V10 package descriptions).

How does RoboDK turn a simulation into a program for a specific controller?​

RoboDK describes itself as "software for Simulation and Offline Programming." Its Basic Guide's getting-started sequence runs from loading a robot from the online library, through adding reference frames, objects, tools and targets, to creating programs offline, simulating them, and generating a program "for the robot controller" with a selected post processor. The guide says that when a program is generated, RoboDK "will automatically generate the correct orientation values required by your robot controller (using a post processor)." Its library's posts "make programs generated by RoboDK compatible with different robotic arms, controllers and CNC machinery," and "enable RoboDK to generate robot programs for specific robot controllers." The toolbar lets the user "Activate or deactivate collision checking."

The rest of this answer is engineering reasoning. The post processor is the translation step between one simulation and many controller languages, and it is a place where a program can change meaning: a frame, tool or motion-type convention that the post handles differently from the controller sends the robot somewhere other than the simulation showed. Collision checking that is switched off, or a cell model missing a guard post or a cable tray, produces a clean simulation of a cell that does not exist. A generated program is therefore first run on the real controller at reduced speed and compared point by point with the simulation before it runs at production speed (RoboDK Basic Guide, undated web documentation, accessed September 2026, Introduction, Getting Started, Reference Frames, Library and Toolbar Menu).

What is NVIDIA Isaac Sim built for, and what does its documentation not claim?​

NVIDIA's documentation for Isaac Sim version 6.1.0, last updated on 18 September 2026, summarizes the tool in two sentences: "Import robots and scenes from URDF, MJCF, Onshape CAD, or USD. Simulate with PhysX or Newton, add RTX and physics-based sensors, generate synthetic data, prepare robots for Isaac Lab, and validate robot stacks with ROS 2." Its workflow overview runs import, configure, simulate, and connect or deploy, and describes the last step as "Export datasets to training pipelines or connect external robot stacks for pre-hardware validation." Its robotics-ecosystem section lists, in its workflow tables:

  • Isaac Lab, marked optional, an RL and IL framework to "Train RL and imitation-learning policies with parallel environments."
  • Software-in-the-loop testing, to "Run software-in-the-loop tests with your ROS 2 or Isaac ROS robot stack."
  • Replicator, the synthetic data generation framework in Isaac Sim, to "Script randomization, capture sensor outputs, and write labeled datasets."

The page read does not describe generating programs for an industrial robot controller, post processors, or interoperability with ROBOGUIDE or FANUC controllers, and this article does not imply that Isaac Sim replaces a controller-specific offline programming tool. The documentation is versioned, and every statement here is pinned to version 6.1.0 (NVIDIA 2026, What Is Isaac Sim?, Isaac Sim Documentation 6.1.0, What Is Isaac Sim?, Isaac Sim Workflow Overview and Robotics Ecosystem).

How do ROBOGUIDE, RoboDK and Isaac Sim differ for a heavy handling cell?​

No neutral, published comparison of the three tools was found; each vendor documents only its own product. The table restates what each vendor's page says, and the paragraph after it is engineering reasoning.

ToolDescribed by its vendor asOutput the page namesNot claimed on the page read
ROBOGUIDE V10 (FANUC America)Offline robot programming and simulation software that creates programs and simulates robotic workcells in 3DPrograms; PalletPRO data downloaded to a real controller with PalletTool software; WeldPRO programs and settings transferred to the real robotHow closely simulated positions or cycle times match the real robot
RoboDKSoftware for simulation and offline programmingPrograms generated for a specific robot controller through a post processorAccuracy figures; RoboDK addresses accuracy on its separate calibration pages
Isaac Sim 6.1.0 (NVIDIA)A simulator that imports robots and scenes, simulates with PhysX or Newton, adds sensors, generates synthetic data and validates robot stacks with ROS 2Datasets for training pipelines; software-in-the-loop tests of a ROS 2 or Isaac ROS stackProgram generation for an industrial robot controller, or post processors

Read together, the documentation points to different jobs. ROBOGUIDE is the robot maker's own tool, and its page describes programs and data that are transferred or downloaded to the real FANUC robot controller. RoboDK's post-processor model fits a project with robots from more than one maker, or one programming environment serving several controllers. Isaac Sim fits a project that trains a perception model or a learned policy, or tests a ROS 2 stack, and it sits beside a controller-native program rather than in place of it. For a heavy handling cell built around one robot make, using the robot maker's tool for the motion program and a physics simulator only where a learned or vision-driven function needs synthetic data is one defensible split; it is a project decision, not a ranking of the tools.

Generative AI that drafts controller code is a separate class of tool, and what PLC copilots can and cannot draft covers its documented limits (FANUC America, ROBOGUIDE Robot Simulation Software, accessed September 2026; RoboDK Basic Guide, accessed September 2026, Introduction and Library; NVIDIA 2026, What Is Isaac Sim?, Isaac Sim Documentation 6.1.0).

Why can a program that runs cleanly in simulation miss its targets on the real robot?​

RoboDK's calibration page states the vendor's view in two sentences: "Industrial robot arms are highly repeatable but not accurate," and "The nominal accuracy of a robot depends on the robot brand and model." Qiao and Weiss, writing at NIST, describe the mechanism: "The initial kinematic parameters defined within the robot's controller will become less reflective of the robot's true geometry as physical degradations manifest," and "Thermal expansion, gear error due to degradation, and structural deformation can cause TCP accuracy degradation." In their error-model section they write that real robot joint motion is not ideal, and that there exist nongeometric errors between successive joints, such as the nonideal motion of joints and deflections of the structure and joints due to external loading, gravity and backlash.

The list below is engineering reasoning. Three gaps separate a simulated target from where the real robot goes:

  1. Robot model. The simulation and the controller both start from nominal kinematics; the built arm differs from them by its own geometric and nongeometric errors, and a heavy payload adds deflection that a rigid-link model does not show.
  2. Cell model. The reference frame that locates a fixture or conveyor relative to the robot comes from CAD or a layout drawing; a fabricated base, riser or fixture that is a few millimeters out of position moves every target that uses that frame.
  3. Tool model. A tool center point taken from the gripper drawing, rather than measured on the built gripper, offsets every pose that uses it.

ISO 9283:1998 is the international standard for performance criteria and related test methods for manipulating industrial robots. How its repeatability and accuracy figures appear on heavy-payload datasheets, and why they are not compared one-for-one, is set out in the heavy-payload robots comparison (RoboDK, Robot Calibration, Laser Tracker, accessed September 2026, Introduction; Qiao and Weiss 2019, §1 and §4; ISO 9283:1998).

What does robot calibration do, and what accuracy is claimed for it?​

Roth, Mooring and Ravani's 1987 overview of robot calibration names four issues in its abstract: "Modeling, measurement, identification, and correction issues in robot calibration are discussed, and some of the unresolved questions are identified." Only the abstract is used here.

RoboDK's laser-tracker calibration page gives these vendor statements and conditions:

  • Calibration with its option can "improve robot accuracy by a factor of 2 to 10."
  • For 6-axis arms, "you can obtain accuracies up to 0.050 mm for small robots and 0.150 mm for medium sized robots," and "The accuracy you can obtain after calibration highly depends on the robot model and your setup."
  • "With RoboDK you can't calibrate 5-axis or 7-axis robot arms."
  • "A measurement system is required to calibrate a robot," such as a laser tracker or an optical CMM; besides the base and tool setup measurements, the calibration set needs "60 measurements or more", and optional validation measurements "are used only to validate the accuracy of the robot and not to calibrate the robot."
  • It is "better to calibrate the robot using the same tool that will be used for manufacturing/production (same tool payload and center of gravity)."
  • After calibration, filtering an existing program means "all the robot targets inside a program are modified to improve the accuracy of the robot."
  • "A calibrated robot has a higher absolute as well as relative positioning accuracy than an uncalibrated one," and calibration "can remarkably improve the accuracy of robots programmed offline."

These are RoboDK's own claims, not independent test results. The page's post-calibration accuracy figures are for small and medium-sized robots only, and it gives none for larger robots.

A peer-reviewed paper shows what one calibration model contains, at summary level. Nubiola and co-authors improved the absolute accuracy of one small industrial robot with a 30-parameter model that "takes into account a full kinematic calibration and five compliance parameters related to the stiffness in joints 2, 3, 4, 5, and 6." The robot was calibrated using fewer than 50 configurations and validated in 1000, with a laser tracker and an optical CMM used independently, and the authors report that the optical CMM yields slightly better results. The summary gives no accuracy figures, covers one small robot, and is not a check on RoboDK's figures (Roth, Mooring and Ravani 1987, abstract; RoboDK, Robot Calibration, Laser Tracker, accessed September 2026, Introduction, Requirements, Generate calibration targets and Program Filtering; Nubiola et al. 2014, summary).

What is the sim-to-real gap for robot behaviors trained in simulation?​

Tobin and co-authors, at OpenAI and UC Berkeley, described the problem in 2017 as the "reality gap" that "separates simulated robotics from experiments on hardware." They write that "discrepancies between physics simulators and the real world make transferring behaviors from simulation challenging," that system identification "is time-consuming and error-prone," and that "Even with strong system identification, the real world has unmodeled physical effects like nonrigidity, gear backlash, wear-and-tear, and fluid dynamics that are not captured by current physics simulators." Their method, domain randomization, is "a simple technique for training models on simulated images that transfer to real images by randomizing rendering in the simulator," and they write that "With enough variability in the simulator, the real world may appear to the model as just another variation." The task they studied was object localization, and they report a real-world object detector "accurate to 1.5 cm" trained only on data from a simulator with non-realistic random textures. That figure belongs to their experiment; it is not a figure for robot positioning accuracy.

Zhao, Peña Queralta and Westerlund's 2020 survey is scoped to sim-to-real transfer in deep reinforcement learning for robotics. It says "the gap between the simulated and real worlds degrades the performance of the policies once the models are transferred into real robots," and it covers domain randomization, domain adaptation, imitation learning, meta-learning and knowledge distillation. Its Fig. 1 caption calls domain randomization "One of the most common methods," in which simulator parameters such as colors, textures and dynamics are randomized. Isaac Sim's Replicator is documented to script randomization and write labeled datasets.

The rest of this answer is engineering reasoning. Both papers address learned models, a detector or a policy, not a deterministic program generated offline for an industrial controller, and neither is a statement about offline-program path accuracy. Where a heavy handling cell uses a learned function, such as a vision model that locates castings or bundles in varying positions, the reality gap applies to that model, and its acceptance test set comes from the real cell. The rule-based versus deep-learning inspection article covers how such a model is trained and validated (Tobin et al. 2017, abstract and §I; Zhao, Peña Queralta and Westerlund 2020, abstract and Fig. 1 caption; NVIDIA 2026, What Is Isaac Sim?, Isaac Sim Documentation 6.1.0, Robotics Ecosystem).

What can simulation prove before a heavy cell is built, and what waits for the floor?​

The documentation cited above names several functions that run in simulation, before the hardware exists: RoboDK's collision checking; ROBOGUIDE's 3D workcell simulation, HandlingPRO's machine modeling and conveyor line tracking, and PalletPRO's offline build, debug and test of a palletizing application; and Isaac Sim's software-in-the-loop tests of a ROS 2 stack. The reach and payload arithmetic a simulated layout is checked against, including load diagrams and wrist inertia, is worked through in Sizing an Industrial Robot. PLC logic tested against simulated I/O or a plant model before startup is covered in validating AI-generated automation code.

The list below is engineering reasoning. On a heavy handling cell these items stay open until the real robot moves:

  • Absolute position. Every offline target is touched up or confirmed against the built cell, for the reasons in the two answers above.
  • Payload dynamics. Deflection, overshoot and settling with the real part and gripper on the arm.
  • Dress and clearance. Hoses and cables on the arm, which a cell model can omit or simplify, can set the real clearance to a guard or fixture.
  • Cycle time. A simulated cycle time is an estimate until the cell is timed running the real program.
  • Safety. A collision-free simulation is not a risk assessment, and the cell is assessed as built.

Two sourced points bound that list. The ROBOGUIDE page read makes no claim about how closely simulated cycle times match the real robot, and the title of ISO 12100:2010 names general principles for design, risk assessment and risk reduction in the safety of machinery; its clauses are not cited here (RoboDK Basic Guide, accessed September 2026, Toolbar Menu; FANUC America, ROBOGUIDE Robot Simulation Software, accessed September 2026, ROBOGUIDE Classic V10 package descriptions; NVIDIA, What Is Isaac Sim?, Isaac Sim Documentation 6.1.0, Robotics Ecosystem; ISO 12100:2010).

What controls and sensing does an offline-programmed heavy cell need?​

Rockwell's Logix 5000 design considerations manual says controller tasks can be configured as continuous, periodic, or event. It says "A periodic task performs a function at a specific time interval," and "An event task performs a function only when a specific event (trigger) occurs."

The next two sentences, and the list after them, are engineering reasoning. An offline program moves the robot, and the cell's PLC logic decides when it may; a robot simulation that leaves out that logic has not tested the handshakes, permissives and fault reactions around the motion. The sensing below confirms that the real cell matches the model the program was written against:

  • Part presence and seating. Proximity or photoelectric sensors confirm the part sits where the program's reference frame assumes before the robot moves in to grip.
  • Vision offsets. Where parts arrive in varying positions, a camera corrects the target; the hand-eye calibration article covers how that camera-to-robot relationship is found.
  • Gripper state. Clamp, vacuum or pressure switches confirm the grip before the lift.
  • Load and external axes. Load cells or drive torque checks catch a part heavier or further off-center than the simulated payload, and encoders and limit switches on tracks, positioners and transfer cars confirm the external-axis positions the simulation assumed.
  • Zone interlocks. Signals hold the robot out of shared space while a conveyor, crane or operator is in it.

The PLC-to-robot interface itself is covered in the FANUC-to-Allen-Bradley EtherNet/IP article. UTEC Industrial builds this layer as a Rockwell Automation Recognized System Integrator on Allen-Bradley ControlLogix and CompactLogix platforms, with EtherNet/IP networks, VFD and servo drives, and UL 508A panel building (Rockwell Automation 1756-RM094N-EN-P-2025, Ch. 5 pp. 39 and 41).

How is an offline-programmed cell's accuracy accepted?​

ISO 9283:1998 sets performance criteria and related test methods for manipulating industrial robots. The 1999 NIST-authored handbook chapter states that, as the standard's scope section says, its tests "are primarily intended to develop and verify individual robot specifications, prototype testing, or acceptance testing." It says the second version of the standard contains an annex listing standard test path lengths, loads and velocities, and that "The use of these standards is optional though." Its conclusions add that "Most users would like to have application specific performance test results," which it described then as "only available for a few big buyers." The chapter is cited here for the standard's intent and for its 1999 observations, not for current practice.

The next three sentences are engineering reasoning. For an offline-programmed cell, the application-specific test is the one that matters. The robot runs the offline program, unmodified, to a set of reference targets on the built fixtures; the deviation at each is measured before touch-up; and the acceptance criterion is the process tolerance at the part, not the datasheet repeatability. Recording the deviations before and after touch-up gives the baseline that in-service checks are later compared against. UTEC Industrial performs factory acceptance testing and on-site commissioning (ISO 9283:1998; Dagalakis 1999, pp. 447-459, §27.2.2 and Conclusions).

How does a robot's accuracy drift after startup, and how is it monitored?​

Qiao and Weiss's NIST paper presents a quick health assessment methodology for robot accuracy degradation and demonstrates its feasibility with one use case; the statements below come from its abstract, introduction and error-model sections. Its abstract states the consequence: "The degradation of robot tool center accuracy can increase the likelihood of unexpected shutdowns and decrease manufacturing quality and production efficiency." They write that degradations in robot accuracy "are less observable compared to system freezes or shutdowns," and, citing earlier work, that a robot whose accuracy is degrading "may still be operating" but is likely working at a decreased level of productivity or producing reduced quality. Citing another reference, they write that "Improved accuracy allows robot technologies to enable more robot offline programing that leads to significant time and cost savings." They note that component assessments largely depend on historical data, and that when a configuration or operational parameter changes, such as the payload, the assessment criteria for abnormal status may change too. In their error-model section they state, citing a reference, that "if a machine or instrument is not repeatable, it cannot be calibrated or modeled to represent the errors since errors are not repeatable," and that "Because robots are highly repeatable instruments, calibration or modeling is feasible but needs to handle complex errors."

The rest of this answer is engineering reasoning. For an offline-programmed heavy cell, events that justify re-checking accuracy include a collision, a motor, reducer or encoder replacement, remastering, a payload or gripper change, and relocation of the robot or a fixture. A periodic check program that visits a few fixed reference points and compares them with the recorded acceptance values turns slow drift into a monitored trend before it becomes a mis-placed part (Qiao and Weiss 2019, abstract, §1 and §4).

Where does offline programming sit in the build chain of a heavy-handling cell?​

As engineering reasoning, offline programming starts at the design link and carries through tuning into monitoring, and the steps below place it in the chain:

  • Design and engineering. The cell layout, robot selection and reach studies are done in the simulation model, against the robot's published load data.
  • Parts machining and fabrication. Fixtures, robot bases, risers and grippers are built to the same CAD that the program's reference frames come from, and the program's accuracy depends on them matching it.
  • Weld fatigue and stress relief. A welded base or fixture that moves as residual stress relaxes during machining or service shifts every target that uses it; the stress relief article covers why welded frames are stress-relieved before final machining.
  • Drives, controls and tuning. The program is loaded, run at reduced speed, touched up against the built cell, and its PLC interface is proven.
  • Monitoring. Reference-point checks track accuracy drift in service.

Two sourced points anchor the list. RoboDK's guide says every offline programming application requires a reference frame locating the object with respect to the robot, and the NIST paper names structural deformation among the effects that can cause TCP accuracy degradation. UTEC Industrial machines bases and fixtures in house to tolerances of ±0.001 in, with CMM inspection and automated vibratory stress relief (RoboDK Basic Guide, accessed September 2026, Reference Frames; Qiao and Weiss 2019, §1).

Related Articles

References​

  • RoboDK. Basic Guide (RoboDK Documentation). RoboDK Inc. (undated web documentation, accessed September 2026).
  • Pan, Z., Polden, J., Larkin, N., Van Duin, S., and Norrish, J. (2012). "Recent progress on programming methods for industrial robots." Robotics and Computer-Integrated Manufacturing, 28(2), 87-94.
  • Dagalakis, N. G. (1999). "Industrial Robotics Standards." In S. Y. Nof (ed.), Handbook of Industrial Robotics, 2nd ed. Wiley, pp. 447-459.
  • FANUC America. ROBOGUIDE Robot Simulation Software. FANUC America Corporation (undated web documentation, accessed September 2026).
  • NVIDIA. What Is Isaac Sim? (Isaac Sim Documentation, version 6.1.0). NVIDIA Corporation, 2026.
  • RoboDK. Robot Calibration (Laser Tracker) (RoboDK Documentation). RoboDK Inc. (undated web documentation, accessed September 2026).
  • Qiao, G., and Weiss, B. A. (2019). "Industrial Robot Accuracy Degradation Monitoring and Quick Health Assessment." Journal of Manufacturing Science and Engineering, 141(7), 071006.
  • ISO 9283:1998: Manipulating industrial robots — Performance criteria and related test methods. ISO, 1998.
  • Roth, Z., Mooring, B., and Ravani, B. (1987). "An overview of robot calibration." IEEE Journal on Robotics and Automation, 3(5), 377-385.
  • Nubiola, A., Slamani, M., Joubair, A., and Bonev, I. A. (2014). "Comparison of two calibration methods for a small industrial robot based on an optical CMM and a laser tracker." Robotica, 32(3), 447-466.
  • Tobin, J., Fong, R., Ray, A., Schneider, J., Zaremba, W., and Abbeel, P. (2017). "Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World." 2017 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pp. 23-30.
  • Zhao, W., Peña Queralta, J., and Westerlund, T. (2020). "Sim-to-Real Transfer in Deep Reinforcement Learning for Robotics: a Survey." 2020 IEEE Symposium Series on Computational Intelligence (SSCI), pp. 737-744.
  • ISO 12100:2010: Safety of machinery — General principles for design — Risk assessment and risk reduction. ISO, 2010.
  • Rockwell Automation 1756-RM094N-EN-P-2025: Logix 5000 Controllers Design Considerations. Rockwell Automation, 2025.

Ready to Discuss a Material Handling System?​

UTEC Industrial designs, engineers, machines, fabricates, and installs custom material handling systems for heavy industry, from the stress-relieved structure and drives to the Allen-Bradley PLC controls, tuning, and monitoring that run them, at its Spokane Valley, WA facility. Send UTEC the application, loads, and duty cycle to start a system review.

Request a Quote →

Questions? Call (509) 922-1832 or email sales@utec.co

Last updated on