dd1ad57c

Connecting Beckhoff TwinCAT to NVIDIA USD Composer – Taking Virtual Commissioning to the Next Level

Wed, 17 Jun 2026 06:45:36 GMT

Connecting Beckhoff TwinCAT to NVIDIA USD Composer – Taking Virtual Commissioning to the Next Level

Why Direct PLC Connectivity in NVIDIA USD Composer Matters

Digital twins and virtual commissioning are becoming increasingly important across modern industrial environments. While CAD data, robots, and simulation models are often available within digital platforms, direct connectivity to industrial control systems is frequently missing.

This is exactly where my new TwinCAT Extension for NVIDIA USD Composer comes into play.

The extension allows users to connect a Beckhoff TwinCAT PLC directly to NVIDIA USD Composer. PLC signals can be both read and written, enabling real-time interaction between the digital twin and the control system. In addition, variables from a TwinCAT project can be imported directly into USD Composer, eliminating the need for manual signal creation.

Direct Import of TwinCAT Signals

One of the most time-consuming tasks in simulation projects is manually creating and maintaining PLC signals.

With the TwinCAT Extension, variables can be imported directly from the TwinCAT PLC project. Once imported, all signals are immediately available within the simulation environment and can be used for:

Machine animations
Equipment states
Material flow simulations
Process visualization
Logic validation
Interactive operator interfaces

This significantly reduces engineering effort while minimizing configuration errors.

Connecting to a Beckhoff PLC

Setting up the connection is straightforward.

Users simply enter the IP address of the TwinCAT controller and establish a connection between the PLC and USD Composer.

Once connected, the extension provides full access to PLC variables, allowing users to:

Read PLC signals
Write PLC signals
Visualize machine states
Simulate equipment behavior
Validate automation logic
Test operator interactions

This creates a seamless bridge between the virtual and physical worlds.

Virtual Commissioning with NVIDIA USD Composer

One of the most powerful applications of the extension is virtual commissioning.

Instead of waiting for the physical machine to be available, engineers can connect the PLC to a digital twin and begin testing much earlier in the project lifecycle.

Control logic can be verified, machine behavior can be validated, and integration issues can be identified before commissioning starts on-site.

Typical use cases include:

Conveyor systems
Intralogistics solutions
Manufacturing lines
Special-purpose machinery
Robotic cells
Material handling systems
Automated warehouses

By connecting directly to a PLC, NVIDIA USD Composer becomes a powerful platform for advanced virtual commissioning workflows.

Why NVIDIA USD Composer?

NVIDIA USD Composer is built on OpenUSD, an open and scalable framework for creating, visualizing, and simulating complex 3D environments.

The platform offers several advantages for digital twin and industrial simulation projects:

OpenUSD-based workflow
High-fidelity RTX real-time visualization
Physically based simulation capabilities
Support for robotics and automation applications
Scalable digital twin environments
Real-time collaboration
Integration of external systems and industrial data
Foundation for virtual commissioning and Physical AI applications

These capabilities make USD Composer an ideal environment for connecting industrial automation systems with modern digital twin technologies.

Benefits for Engineering Teams

By combining Beckhoff TwinCAT with NVIDIA USD Composer, engineering teams can:

Detect issues earlier in the project lifecycle
Reduce commissioning risks
Accelerate development cycles
Improve collaboration between controls and simulation engineers
Validate automation logic before hardware is available
Increase confidence before plant startup

The result is a more efficient and predictable commissioning process.

Conclusion

The new TwinCAT Extension transforms NVIDIA USD Composer into an open platform for industrial simulation and virtual commissioning.

By enabling direct PLC communication, automatic signal import, and real-time read/write access to TwinCAT variables, the extension creates a seamless connection between automation systems and digital twins.

The combination of Beckhoff TwinCAT, OpenUSD, and NVIDIA USD Composer opens new possibilities for modern engineering workflows and the next generation of industrial digital twins.

# Process Omniverse – Why I Created This Category

Fri, 05 Jun 2026 07:52:46 GMT

This is a subtitle for your new post

Process Omniverse – Why I Created This Category

Over the last few years, I have spent a significant amount of time working with NVIDIA Omniverse and USD Composer. During that journey, a new category slowly emerged for me, which I eventually started calling “Process Omniverse.”

The term did not come from marketing, and it is not simply a new name for a few extensions. For me, it describes a gap that became very obvious once I moved from the traditional industrial simulation world into the world of NVIDIA Omniverse.

My background comes from automation technology, virtual commissioning, and industrial simulation. That means the way I look at software is heavily influenced by production systems, robotics, PLC logic, material flow, cycle times, plant behavior, and real industrial processes. When I think about simulation, I do not first think about beautiful camera animations or cinematic 3D scenes. I think about systems that must behave logically. Robots executing real programs. Signals exchanged between PLCs and simulation systems. Material moving through production lines. Processes that must be validated before the real plant even starts production.

That was exactly the mindset I brought with me when I started working with NVIDIA Omniverse and USD Composer.

At first, of course, the technology is impressive. The graphics are outstanding, RTX rendering looks fantastic, large CAD datasets can be visualized smoothly, and the USD format itself offers enormous flexibility. On top of that, there are concepts such as references, layers, modern material systems, textures, multi-user workflows, and realtime visualization. Technically, it is extremely fascinating.

But at the same time, you quickly realize something important:

USD Composer is not a traditional industrial simulation software.

And that distinction matters a lot.

USD itself originally came from Pixar. It was designed for large-scale 3D productions, complex scenes, animation pipelines, asset management, and cinematic workflows. And for those use cases, it is incredibly powerful.

Inside USD Composer, it is relatively easy to create high-quality animations. You can work with timelines, sequencers, keyframes, camera movements, object animations, and cinematic rendering workflows. Combined with RTX and path tracing, the visual quality becomes extremely impressive, with realistic materials, lighting, reflections, and shadows.

But animation is not the same thing as simulation.

That difference may sound small at first, but for industrial applications it is fundamental.

An animation simply shows that something moves. A simulation must explain why something moves, when it moves, which signal triggered it, whether the process logic is correct, and whether the behavior matches the real production system.

In classical industrial simulation, the focus is not only on movement. The focus is on material flow, cycle times, robot behavior, PLC communication, process logic, conveyor systems, signal states, timing, and complete production workflows.

A robot moving from point A to point B is not enough.

The real challenge is understanding whether the process itself behaves correctly.

Of course, NVIDIA also offers simulation technologies such as Isaac Sim or PhysX. And those technologies are extremely powerful for many use cases. But for someone coming from tools such as Siemens Process Simulate, Plant Simulation, Visual Components, or other industrial engineering platforms, the meaning of “simulation” is often very different.

Traditional industrial simulation is deeply process-oriented. It combines robotics, PLCs, logic, production behavior, safety concepts, sequencing, and real manufacturing processes into one complete virtual environment.

And that was exactly the point where the idea of Process Omniverse was born.

I started asking myself:

What kind of tools, extensions, workflows, and supporting systems are actually needed to bring true industrial process simulation into NVIDIA Omniverse?

Because from my perspective, this is where the real potential begins.

USD Composer already provides an incredibly strong technological foundation. It can handle huge worlds, modern rendering, realtime visualization, open data structures, references, streaming, APIs, extensions, and scalable scene management. But what is often missing for industrial users is the actual process layer.

And that process layer is exactly what Process Omniverse is about.

For me, Process Omniverse means treating Omniverse not only as a visualization platform, but as a foundation for real industrial workflows and process-driven simulation.

It is about connecting plant logic, robotics, material flow, PLC communication, user interaction, signals, movement systems, and industrial behavior models into one usable environment.

Because in industry, beautiful 3D data alone is simply not enough.

A factory scene inside USD Composer may look visually impressive. But the real value only appears once the factory actually behaves like a factory. Once conveyor systems transport material. Once robots execute workflows. Once signals influence real states. Once process logic controls behavior. Once users can interact with understandable industrial tools instead of simply looking at static geometry.

That is why Process Omniverse, for me, is not only about extensions.

It is also about know-how, workflow design, usability, automation, interfaces, industrial logic, process understanding, and user-oriented engineering.

Because in the end, industrial software is not successful simply because the technology works. It becomes successful when users can efficiently work with it and solve real industrial problems.

And that, in my opinion, is one of the biggest differences between a technical platform and a true industrial solution.

NVIDIA Omniverse already provides many of the technical building blocks. But these building blocks still need to be connected into meaningful industrial workflows. And that is exactly where I see the role of Process Omniverse: creating the bridge between traditional industrial simulation and modern technologies such as USD, RTX, realtime rendering, web streaming, multi-user collaboration, and open platform architectures.

Over the next months and years, I want to continue building and presenting different tools, extensions, workflows, and technical approaches under this category that help make industrial simulation possible inside NVIDIA Omniverse.

The goal is not to simply recreate existing simulation software one-to-one.

The goal is to combine the strengths of both worlds.

Traditional industrial simulation brings process understanding, virtual commissioning, production logic, and engineering methodology.

Omniverse brings modern visualization, scalable data structures, realtime graphics, openness, flexibility, and entirely new possibilities for the Industrial Metaverse.

And exactly at that intersection, I currently see one of the most exciting technology areas of all.

And that is exactly why Process Omniverse exists.

My Journey with Robcad Process Simulate

Sat, 30 May 2026 13:06:41 GMT

My Journey with Robcad and Process Simulate

When I look back today at topics such as virtual commissioning, robot simulation or Siemens Process Simulate, it is not just some kind of software or technical tool to me. It is much more a journey that now goes back more than 20 years and has shaped me both professionally and personally.

My first points of contact with automation technology in automotive manufacturing began back in 2003 at the company ATEC, which later became VESCON. The work there was about classical automation technology, plant commissioning, project management and many different topics around production systems in the automotive environment. In other words, exactly the world of PLCs, robotics, conveyor technology and plant control.

Back then, many things were much more “hands-on” than they are today. Digitalization was already a topic, but it was far from being as natural and established as it is today. Many things were tested, adjusted and optimized directly at the real plant. That is exactly why it was so exciting for me when I first came into contact with offline programming and robot simulation around 2008.

At that time, the first projects were running at Rolls-Royce, and through that there was the opportunity to look behind the scenes of robot simulation together with an engineering office. At that time it was still Siemens Robcad - long before it later became Siemens Process Simulate.

Even the hardware back then was impressive. Robcad ran on SGI workstations, those large blue high-end CAD machines that were incredibly expensive at the time. These systems alone already had something special about them. This was not ordinary office hardware, but specialized high-end technology for CAD and simulation.

The first robot simulations in Robcad then ran on these SGI workstations. For me, that was absolutely fascinating at the time. Suddenly it was possible to simulate complete robot movements in 3D, create programs offline and virtually test entire sequences. Things that feel almost self-evident today were technically extremely impressive back then.

At the beginning of 2009, I was finally able to install Robcad myself for the first time and really use it actively. And that was where my real journey into virtual robot simulation actually began.

The problem back then was: there was hardly any information. Today you open YouTube, watch tutorials or read through hundreds of forum posts. Back then, it was completely different. Robcad was highly specialized software. Documentation was difficult to find, experts were extremely rare and much of the information was only available through projects or contacts with other companies.

That is why a huge part of my work back then consisted simply of testing.

At ATEC, we had a small KUKA KR3 robot standing in the office. And that small robot basically became my personal test system. I started adding the robot in Robcad, modeling the gripper and creating my first offline robot programs.

That may sound trivial today, but at the time it was incredibly exciting to me.

I was able to create programs in Robcad, transfer them to the real robot afterwards and then observe how the robot suddenly executed real movements that had been created completely virtually beforehand. In some cases, we let the robot grip simple things or draw with a pen. Afterwards, the programs were loaded back into Robcad and further analyzed or adjusted there.

And that was where my real enthusiasm for virtual commissioning and simulation began.

In 2009, I really invested every free minute into this topic. I tried out all kinds of things in Robcad, searched for documentation, watched videos and simply tested. You have to remember: back then YouTube was nowhere near as full of specialist content as it is today. Especially in the field of robot simulation, there was hardly any public knowledge.

At some point I realized that Siemens had already released the successor to Robcad: Siemens Process Simulate in version 8.2. And at that moment I thought to myself: “Okay, now I will stop looking at the old Robcad stuff and move directly into the new topic of Process Simulate.”

Fortunately, we already had the corresponding licenses at ATEC, so I was able to install and test Process Simulate quite quickly. What was interesting back then was that many people were still fully working with Robcad, while I had already started to deal intensively with Process Simulate. That meant I was relatively early with this system.

In addition, I was lucky that, through various projects - for example at Rolls-Royce or BMW Leipzig - we repeatedly had points of contact with offline programming and virtual commissioning. They were not directly our own OLP projects, but it was possible to get a glimpse, try things out and observe how other companies were already using these technologies.

Because I originally come from automation technology and am a trained automation technician, my focus was never only on the robot itself. I was much more interested in the entire topic of virtual commissioning.

Questions such as:

How do you connect a PLC?
How do you model plant behavior?
How do interfaces work?
How do you simulate complete production processes?

For me, the robot was actually only one part of the overall system.

In 2009, we then had a project at BMW Leipzig where we had to, or rather were allowed to, carry out the plant commissioning. And that was exactly where I thought: “Now you try the whole thing with Process Simulate.”

Back then, I converted the existing Robcad data into Process Simulate and started building a full virtual commissioning setup. That was in fact my first large VIBN project in Siemens Process Simulate.

We had a Siemens S7-400 PLC, several ABB robots, offline programs, behavior models inside Process Simulate and a complete PLC connection. And when I think about it today, it is actually crazy. We are talking about 2009 and Process Simulate version 8.2. Back then, virtual commissioning was nowhere near as widespread as it is today. Many things were experimental, a lot had to be figured out by yourself and often there were no clear procedures.

But that was exactly what made it so exciting back then.

From there, things continued over the years. I carried out many different virtual commissioning projects for different manufacturers, standards and special-purpose machines. Always new PLC systems, new interfaces, new plant concepts and new challenges.

At some point - I think from around 2014 - it became increasingly clear that professional virtual commissioning requires many supporting tools. Whether inside or outside Process Simulate: without automation, you eventually become too slow in large projects.

That was where the first custom tools began.

Together with colleagues, we started developing our own applications in C#. The goal was to automate typical processes and build complete VIBN projects faster. This included, for example, signal imports, automatic signal assignments, separate viewers and various support tools for virtual commissioning.

The idea was always the same:

You receive CAD data, signal lists and process descriptions - and as quickly as possible, this should become a runnable VIBN project so that testing can start early.

So we started developing more and more of our own tools for ourselves, allowing us to become faster, more efficient and better in projects.

And I think there is one project I will probably remember for the rest of my life.

I no longer remember exactly whether it was Christmas 2015 or 2016, but we carried out a virtual commissioning project for a Rolls-Royce plant back then. The plant had around twelve KUKA robots. At first, that may not sound that spectacular. But the real dimension was somewhere else.

The plant had a cycle time of around 45 minutes.

That means it took 45 minutes until a vehicle, or a part of the vehicle, had passed through the entire plant. The robots had an incredible number of sequences, tool changes, docking stations and complex process steps. The entire plant was huge.

And that was exactly where we carried out the complete virtual commissioning together over Christmas.

It was stressful, extremely demanding and at the same time an incredibly exciting time. There, we really tried to get everything out of Process Simulate that was technically possible.

To this day, it is probably one of the projects I remember most strongly.

At some point, someone once told me that Process Simulate basically has three levels.

At the bottom starts the classic simulation.

Above that comes offline programming.
And at the very top is virtual commissioning.

Virtual commissioning is basically the supreme discipline.

Because that is where all areas suddenly come together:

Robotics,
PLC,
electrical engineering,
sequence control,
signals,
interfaces,
behavior models,
safety technology
and real production logic.

And that is exactly where the devil is in the details.

Many people do not understand that virtual commissioning requires an incredible number of things to be prepared already. You need finished PLC programs from the PLC programmer, finished robot programs from the robot programmer, prepared electrical engineering, EPLAN data, signal lists and clear sequences.

Only when this information is available early can it also be tested virtually.

And that changed many projects massively over the years.

Suddenly, virtual commissioning was no longer just some additional step, but a real driver within projects. People would sometimes jokingly say: “That annoying VIBN is causing stress again.” But actually, the reason behind it was different: virtual commissioning simply requires information much earlier so that problems can already be detected in the virtual world.

And that suddenly increased the requirements for data quality, project preparation and coordination enormously.

Over the years, virtual commissioning then established itself almost everywhere - whether driven by the customer or by the supplier. Improving quality, saving time, detecting errors early and securing plants faster became more and more important.

And when I look back today, it is crazy to see how Process Simulate has developed over the years.

From version 8.2 through 9, 10, 11, 12, 13 and up to today’s version 26.06, there are simply technical worlds in between. The possibilities, interfaces and functions today are enormous.

Still, I often like to think back to those early days. Because that is where the foundation was actually created for everything I do today in the field of virtual commissioning, simulation and industrial digitalization.

Yours, Ben Voelzke

# How I Started Developing My Own NVIDIA Omniverse USD Composer Extensions

Fri, 29 May 2026 09:29:17 GMT

# How I Started Developing My Own NVIDIA Omniverse USD Composer Extensions

When you search for NVIDIA Omniverse or USD Composer today, you mostly find impressive marketing videos, huge digital twin promises, and perfect RTX renderings. Everything looks futuristic, powerful, and visually outstanding. What you find much less often are honest experience reports about how to actually get started, how complex Omniverse can be in the beginning, and what it really means to develop your own extensions.

That is exactly why I wanted to write this article.

My background is not in the classic 3D or gaming world. I come from industrial digitalization. For almost 20 years, I have been working with topics such as virtual commissioning, robotics, PLCs, material flow, and simulations in the automotive industry. Over the years, I have worked extensively with software such as Siemens Process Simulate and supported many different digitalization projects.

A few years ago, NVIDIA Omniverse entered the market, back then still with Omniverse Create. At that time, many applications were still started through the Omniverse Launcher, including Create, Audio2Face, and Nucleus. Around the same time, Siemens started providing initial interfaces between Process Simulate and Omniverse. This made it possible to transfer simulations and data from Process Simulate into Omniverse. That was the moment when the topic became really interesting for me.

However, I quickly realized that USD Composer is not a classic simulation software. It is more like a large platform or framework that offers an incredible number of possibilities. And that is exactly what makes Omniverse both fascinating and extremely complex. I often describe USD Composer as a kind of “Swiss army knife” for 3D, simulation, visualization, and industrial workflows. You can do almost anything with it — and usually in many different ways.

But that is also a challenge for beginners. If you do not define a clear goal at the beginning, it is very easy to get lost in all the possibilities. That happened to me as well. Everywhere you look, you see RTX, AI, digital twins, physics, streaming, robotics, Audio2Face, avatars, huge CAD worlds, and dozens of APIs. You immediately want to understand everything at once.

That is why my first step was not to directly start programming my own extensions. Instead, I first tried to understand how Omniverse actually works. I tested different NVIDIA tools, explored USD files, tried to understand the structure of prims and hierarchies, and learned how information is organized inside a stage. At the same time, I worked with topics such as CAD import, materials, textures, RTX rendering, path tracing, lighting, and shadows.

USD itself was especially interesting to me. In the beginning, you automatically ask questions like: Are USD files only metadata? Where is the actual geometry stored? How do layers, prims, and references work together? These are things you need to understand before you can build meaningful custom functionality.

At some point, I started developing my first small extensions. And when I say small, I really mean small. In the beginning, it was not about complex simulations or large systems. It was about simple functions such as hiding and showing objects or changing colors.

That may sound basic, but it was incredibly valuable.

This is exactly where you start to understand how USD Composer works internally. For example, when you hide a prim, you quickly realize that its child objects are not necessarily handled the way you might expect. So I had to understand how to navigate hierarchies, how stages are structured, and how to access information properly. These small problems are often where you learn the most.

For me, the whole process was a huge learning-by-doing journey. I researched a lot, analyzed GitHub examples, and worked through the NVIDIA documentation. And I have to say: the NVIDIA documentation is extremely powerful — if you know where to look. Many users do not realize that USD Composer gives you access to large parts of the API documentation directly from within the application. From there, you can get to topics such as Python, Omni.UI, USD APIs, events, and viewport functionality.

Still, Omniverse can feel like a huge jungle in the beginning. That is why my most important advice for beginners is: start small.

Do not try to build the next big digital twin platform right away. Do not try to solve robotics, physics, streaming, AI, and simulation all at once. Build one small function and use it to learn how Omniverse works.

Another major topic for me was usability. I quickly realized that NVIDIA provides extremely powerful technology, but simple and intuitive usability is not always the platform’s strongest point. Especially in the industrial world, you know very well what users expect. Functions need to be understandable, workflows need to be logical, and the user should not feel lost.

That is why building user interfaces and simple workflows became more and more important to me. I did not want to build extensions that only work technically. I wanted to build tools that are also pleasant and easy to use.

At the same time, I had to get used to Python. Since I originally come more from the C# world, this was definitely a change for me. Of course, Python has many advantages and an enormous ecosystem of libraries. Still, I first had to get used to indentation, syntax, and the overall structure. Anyone coming from a more classic software development background will probably understand what I mean.

Over time, the extensions became more advanced. Simple visibility tools turned into more complex systems for conveyor technology, material flow, robotics, and industrial user interfaces. Especially when working with large virtual worlds, Omniverse shows its real strengths. Huge amounts of data, large CAD structures, and complex scenes can be displayed with impressive performance.

However, the real value does not automatically come from the platform itself. That is one of the most important points about Omniverse in my opinion: you often have to develop the actual value yourself. USD Composer provides the foundation, APIs, rendering, interfaces, and performance — but the actual industrial workflows, functions, and user interfaces often need to be built on top of it.

Over time, this led to more and more custom extensions, tools, and eventually my own marketplace for USD Composer extensions.

For me, this topic is far from finished. On the contrary, I believe that NVIDIA Omniverse and USD Composer still have enormous potential in industrial environments — especially when the technology is not only seen as a beautiful visualization tool, but as a foundation for real, usable workflows.

My goal is to continue expanding this knowledge, develop my own extensions, and support companies in building meaningful applications based on USD Composer. For me, it is not just about “showing something in 3D”. It is about solving real industrial problems in a simpler, clearer, and more efficient way.

If you are currently getting started with USD Composer, want to develop your own extensions, or would like to understand how Omniverse can be integrated into industrial processes, it is definitely worth getting in touch.

You can find more information about my projects, services, and current developments on my website:

https://www.bv-digitalconsulting.com

You can also find my own extensions and further solutions around USD Composer on my marketplace:

https://marketplace.bv-digitalconsulting.com

Yours, Ben Voelzke

dd1ad57c

Connecting Beckhoff TwinCAT to NVIDIA USD Composer – Taking Virtual Commissioning to the Next Level

Connecting Beckhoff TwinCAT to NVIDIA USD Composer – Taking Virtual Commissioning to the Next Level

Why Direct PLC Connectivity in NVIDIA USD Composer Matters

﻿

Direct Import of TwinCAT Signals

Connecting to a Beckhoff PLC

Virtual Commissioning with NVIDIA USD Composer

Why NVIDIA USD Composer?

Benefits for Engineering Teams

Conclusion

# Process Omniverse – Why I Created This Category

This is a subtitle for your new post

Process Omniverse – Why I Created This Category ﻿

My Journey with Robcad Process Simulate

My Journey with Robcad and Process Simulate

# How I Started Developing My Own NVIDIA Omniverse USD Composer Extensions

# How I Started Developing My Own NVIDIA Omniverse USD Composer Extensions

Process Omniverse – Why I Created This Category