Enter FactoryTalk Logix Echo. Released by Rockwell Automation in 2021, Logix Echo is a full-fidelity PLC emulation tool that allows you to directly download and test any modern Rockwell PLC project – no controller or I/O changes required! This emulator behaves exactly as if it were a physical PLC sitting on your desk, which allows for significant testing of your PLC logic before you ever connect to the real machine. In cases where your project necessitates some form of digital twin – whether it be minimal I/O simulation or a full-fidelity machine model – tools like Emulate3D and Simulink can integrate with Logix Echo to provide full virtual commissioning functionality.

At DMC, we make heavy use of FactoryTalk Logix Echo every day to allow Automation engineers in any of our offices to program and test PLC code before deployment for our customers. To do this, we set up a centralized Logix Echo server that many users can access at once. This blog will walk through the process of setting up a FactoryTalk Logix Echo server, creating an emulated PLC, downloading PLC programs, and connecting your simulated PLC to external Rockwell applications.

Using FactoryTalk Logix Echo on a server can support lots of developers at once.

Step 1: Set Up Your Server

Server Performance

Before you get started, make sure you have the right IT hardware for the job. From testing, we’ve found that each emulated PLC likes to take up one entire processor core and around 1GB of memory on the host computer. Excessive numbers of emulated PLCs on an undersized server can quickly lead to performance issues or cause some PLCs to lose their onboard programs. At DMC, we got around this problem by using a virtualized server with the following critical stats:

• Windows Server 2022
• Intel Xeon processors @ 2.30 GHz
• 36 GB RAM
• 24 (virtual) processor cores

These stats work very well for us right now, but having a virtual server allows us to quickly add or remove processing resources as necessary to keep up with our customers’ project needs.

Network Provisioning

Since your Logix Echo server will be hosting many PLCs at once, it’s likely you’ll want to assign a unique IP address to each PLC. Fortunately, there’s a way to do this without running bundles and bundles of Ethernet cable to the same server! We’ve taken advantage of Windows’ ability to assign multiple IP addresses to the same physical Ethernet port on a PC.

To do this, open the adapter properties for your (virtual) server’s network adapter, navigate to the IPv4 settings, and click the “Advanced” button on the bottom-right corner of the pop-up window. The “Advanced” pop-up window that opens allows you to add an arbitrary number of IP addresses. The server at DMC has over 10 IP addresses all running off the same physical Ethernet connection! This gives us a large pool of IP addresses to use when spinning up a brand-new Logix Echo PLC.

Once you have your server configured properly, install FactoryTalk Logix Echo using Rockwell’s install wizard.

Step 2: Add a Controller to Your Server

Now that we’ve got Logix Echo installed, it’s time to go ahead and set up our first emulated PLC! To do this, we’ll use the FactoryTalk Logix Echo Dashboard::

The left-hand toolbar on the Logix Echo dashboard shows a list of all emulated PLCs that have been created on the server. Emulated ControlLogix controllers are hosted in a virtual chassis, just like a physical ControlLogix. Emulated CompactLogix controllers do not belong to a chassis.

To add a new controller (or chassis) to your Logix Echo server, right-click in any white space in the Devices toolbar or press the hamburger button on the top right-hand corner of the toolbar.

Choosing “Add controller” will open a configuration pop-up window. Here, you will pick the controller type and firmware version, give your controller a name, and assign it to a chassis slot (if it’s a ControlLogix).

Note that at the time this blog was published, only the following PLCs are available for emulation with Logix Echo:

• ControlLogix 5580 controllers
  • v33 through v36
• GuardLogix 5580 controllers
  • v35 and v36
• CompactLogix and Compact GuardLogix 5380 controllers
  • v36 only

Before hitting “Add,” the last step is to assign an IP address to your controller. If you’ve assigned lots of IP addresses to your Echo server using the steps above, they will all appear in the drop-down menu here.

Once your controller has been added to the server, you can always go back and edit its properties by double-clicking on the device in the “Devices” toolbar on the left-hand side. This will open a status page on the main window of the dashboard where you can:

• Cycle controller “power”
• Change the controller’s name and IP address
• Change the assigned chassis or slot (for ControlLogix controllers only)
• Attach or detach a simulated SD card to your controller
  • Yes, really! Logix Echo creates a folder on your server that emulates file storage on an SD card connected to a physical controller – you use all the functions of a real SD card in your emulated PLC environment.
  • The server storage location for the emulated SD card is in
    C:\ProgramData\Rockwell Software\FactoryTalk Logix Echo\Controllers\<your_controller>\Root\sd

Step 3 – Connect to Your Echo PLC and Get Programming!

The next series of steps should be familiar to any Rockwell PLC programmer – since your emulated PLC is running and has an IP address, you should be able to browse it using FactoryTalk Linx. To make things easy for myself, I’ve created a whole Ethernet driver in FactoryTalk Linx specifically to browse for Logix Echo PLCs on DMC’s server. Keeping the Logix Echo PLCs segregated from physical ones in my Linx browser helps me remember what I’m connected to.

Once your emulated PLC shows up in FactoryTalk Linx, you’ll notice that it will have a model number of 9310-WED300ENT. Don’t panic! You can still download your ACD file without needing to change the controller type in your project – just make sure the firmware version of your project matches the firmware running on your Logix Echo PLC.

Once you confirm you can successfully locate your PLC in FactoryTalk Linx, you should be able to perform the following Linx-based tasks:

• Connect and download an ACD file using FactoryTalk Logix Designer
• Create a shortcut to the PLC inside a FactoryTalk View ME or SE application
• Expose PLC tags to third-party software via OPC-UA using FactoryTalk Linx Gateway
• Configure scheduled PLC program backups using FactoryTalk AssetCentre

We’ve used all these functions – plus plenty more advanced Logix Echo tricks – to continue to deliver quality solutions for customers.

The post Getting Started with FactoryTalk Logix Echo appeared first on DMC, Inc..

Recently, a customer asked me to set up a closed-loop position axis in TIA Portal using an S7-1500 PLC, a G120C VFD, and an external encoder. Patrick Smith wrote a great blog explaining how to gear a drive to an external encoder using native Siemens hardware. For me, however, I needed a more generic solution because my encoder communicates over IO-Link instead of Profinet or Profibus. Furthermore, the G120C drive I was using natively supported speed axis control via Telegram 1, but did not support any of the more complex Telegrams required for position control. 

To interface my setup with a Position Axis tech object, I repackaged the drive and encoder data into a simulated Telegram that the Siemens tech object could understand. I decided to use Telegram 3: which is used to package status info and control setpoints for one drive and one encoder. You can simulate Telegram 3 using the following steps:

Step 1: Create Servo Organization Blocks

The servo tech object is called in TIA Portal using an organization block (OB) called “MC-Servo.” All the logic required to simulate the Telegram communication should be placed in “MC-PreServo” and “MC-PostServo” (OBs). Doing so ensures that the MC-Servo OB has all the data it needs from your hardware to operate the tech object logic correctly. 

Select “Add new block” in the project tree, select the MC-Servo block, and press “OK.” We’ll repeat this process to add the “MC-PreServo” and “MC-PostServo” OBs. 

Step 2: Create a Virtual Telegram

Next, we need to set up a data block where our virtual Telegram will be stored. Create a new data block called “dbServo” and add a new object of type “PD_TEL3.” Portal will automatically generate the data structures required for Telegram 3 communication.

Step 3: Set up Telegram data in “MC-PreServo”

Simulate Sign-of-Life Signals

The Telegram 3 communication protocol maintains a “sign-of-life” signature between master and slave devices. The Profinet master device uses 4 bits in Status Word 2 (STW2) of the Telegram to count from 0 to 15 cyclically. The slave device simply echoes those bits back to the master to prove that the communication between these devices is active. 

Because our Telegram is virtual, we need to simulate the sign-of-life communication between its input and output structures. This logic should exist in the “MC-PreServo” OB, so our tech object doesn’t throw a communication error when it is called in “MC-Servo.” 

We can simulate the sign-of-life signals by implementing a counter that executes continuously and is reset back to 0 once it reaches a value of 15. We’ll split the value of the counter into binary representation by addressing individual bits of the integer, from %X0 to %X3. 

These counter bits will be used to control both the master and slave sign-of-life bits in our virtual Telegram, so it will look like our virtual slave device is always responding to its virtual master:

Configure Encoder Settings

For the tech object to correctly read data from the encoder, the master and slave “devices” in our virtual Telegram must agree on the type of encoder used. The following rung ensures both the input and output structures of our Telegram recognize the encoder settings that we will eventually set up in our tech object:

Configure VFD Telegram tags

In our project’s PLC tags, we’ll make two tags that correspond to the Telegram 1 data being passed between the PLC and our G120C. These Send and Receive tags should be of datatypes “PD_TEL1_IN” and “PD_TEL1_OUT,” respectively, and should have the same address as the G120C’s Telegram as shown in the hardware configuration:

Move Encoder and Drive Data into Telegram

Here’s where the magic happens! We need to take the incoming Telegram data from the G120C and external encoder and pack it into the input structure of our virtual Telegram. In Telegram 3, the velocity feedback is stored in “NIST_B” while the encoder position is stored in “G1_XIST1.”

Please note that both of these variables are double words (DWord) in Telegram 3. If your hardware returns data in a different numerical format, you may need to do some data manipulation to make sure your feedback values are correctly represented in the tech object.

In my project, the external encoder already sent data in DWord format so I could move that directly into the virtual Telegram. The G120C was a little trickier – since Telegram 1 returns velocity feedback as a single Word, I had to do some bit-shifting to pack the data into the Telegram input in DWord format.

Enable Drive Operation

The final setup step required in the “MC-PreServo” OB is to energize all the status bits that enable the drive to run. If the tech object does not receive all these status bits correctly, it will not be possible to operate the axis.

Step 4: Unpack Telegram Data in “MC-PostServo”

Once our tech object has been called in the PLC program, we need to send our newly calculated speed setpoint and control bits to our physical drive. The hardware outputs required will depend on the make and model of your drive. However, the rungs below demonstrate the basic process of unpacking Telegram 3 data.

The first rung sends the status word from the virtual tech object directly to the G120C. Since the first status word (STW1) structure is the same between Telegram 1 and Telegram 3, a direct MOVE command worked just fine here.

When sending setpoint data, just remember – depending on how your drive interprets setpoints – you may need to do some operation to get the Telegram data to a format that the drive can understand. In my case, the drive expects the setpoint as a single Word, but the virtual tech object outputs a speed command in DWord format. 

In order to maintain as much data resolution as possible, I normalized the DWord speed command as a percentage of its maximum possible value in DWord format, then, I multiplied this normalized value by the maximum possible Word value to get the appropriate speed command for my drive.

Step 5: Add a Position Axis Tech Object to the Project

Now that all of our signals into and out of our virtual Telegram have been taken care of, we’re ready to add the position axis tech object to our Portal project. In the Project Tree of TIA Portal, find the Tech Objects folder and select “Add New Object.” Then, select a Positioning Axis object, give it a name, and press “OK.” 

Portal automatically assumes that the encoder connection will match the configuration of the drive connection, so it already set up encoder parameters for us. Just be sure to check that the encoder type in the tech object matches your physical hardware. From this point, you can configure the rest of the tech object as normal. 

Learn more about DMC’s Siemens Solutions Partnership and contact us for your next project. 

The post Integrating a Third-Party Encoder as Feedback for Position Control of a Siemens G120C VFD appeared first on DMC, Inc..