Such is the fate of the InGear NET.LOGIX Driver.

This post explores this recent shift in the tech ecosystem; what exactly happened to InGear, why support has ended, and what you should use instead if your application still relies on NET.LOGIX today.

InGear Drivers End-Of-Life

Once a common choice for communicating between .NET software and Allen-Bradley LOGIX series PLCs, all software drivers have been fully discontinued. This isn’t a “maintenance mode” situation; driver development has stopped, and the license servers used to establish new development environments are no longer available, making ongoing support impossible.

Where did InGear go?

InGear NET.LOGIX was designed at a time when .NET drivers were the primary method for communicating with Allen-Bradley Logix controllers. Since then, the ecosystem has evolved:

• Rockwell has extended its native support for other communication options.
• Open-source libraries like libplctag have gained greater adoption among developers.
• Security and deployment expectations have increased significantly, changing driver demands.

With this shift, InGear NET.LOGIX’s developer decided that it was better to focus its efforts and investments in other areas.

And don’t feel bad if you missed the announcement that support for InGear NET.LOGIX driver has ended. There was no formal public EOL date; their website simply displays an unprotected 404 page with no documentation, downloads, or publicly available support channels.

Which Driver Should I Use Now?

If your application still relies on InGear Net.LOGIX, the good news is, you’re not stuck. We have successfully migrated systems to modern, actively maintained alternatives. In a previous post, we walked through a free and open-source option: Replacing the NET.LOGIX InGear Driver with libplctag.NET, including considerations to make about system architecture as well as migration tips.

This is just one of the many instances in which DMC engineers regularly modernize PLC communication layers as part of broader automation and application development projects, helping teams reduce technical debt and maintain system reliability and efficiency.

The post Support Ended for InGear NET.LOGIX Driver appeared first on DMC, Inc..

To address this, DMC applies modern version control, continuous integration, and continuous deployment practices widely used in traditional software development. These processes, and the software that enables these processes, seek to lower the barrier between development (Dev) and operations (Ops). This blog will review how to apply the foundational DevOps principle of version control to Rockwell PLCs.

Version Control and Git

Version control systems (VCS) are essential for applying modern DevOps practices to Rockwell PLC development. These systems help create a standardized and reliable way for teams to collaboratively develop, manage, and test code efficiently.

Git, which is a distributed version control system (DVCS) originally created by Linus Torvalds, enables effective collaboration among developers through useful features such as branching and merging. Some of the key concepts to understand in Git include the following:

Local/Remote Repository

A full copy of the entire code base is synchronized to a developer’s local repository. This means that each developer has their own complete version of the project on their computer. Developers can then synchronize their code changes with others by pushing their updates to the remote repository and pulling changes from it into their local repository. This process allows multiple developers to collaborate effectively by keeping their work up to date and integrated with the team’s overall progress.

Non-Linear Development

Multiple developers can work on different features simultaneously without interfering with each other. Git facilitates this by allowing branching, merging, and pulling code changes. It also has built-in data integrity mechanisms that help prevent lost changes and keep the history consistent

The main branch of code is called “main” or, in legacy systems, “master”. This branch should generally be the head of development and is the only branch present when first starting a project.

Other branches of development branch off from main, usually with a focus on implementing a specific feature or fixing a specific bug. After this code is completed, it is merged back into main (which can be configured to require appropriate permissions), and then usually either deleted or compressed into a single commit.

Local Repository Command

These core Git commands interact directly with your PC’s local repository. It is important to note that these commands do not affect the remote repository, which requires a different set of commands that will be covered next.

• Branch: This command allows you to create a copy of an existing branch, usually the main branch, so you can work on new features separately without affecting the main codebase.
  • This command stages your changes, preparing them for commit to the active branch. It essentially tells Git which changes you want to include in the next commit.
• Commit: This command saves the staged changes to the active branch, creating a new snapshot of your project at that point in time.
• Merge: This command combines two branches into a single branch, allowing you to integrate changes from different lines of development.

The following additional commands are also commonly used as part of the normal git workflow. These commands are typically utilized by more experienced developers who are comfortable with advanced git operations and want to manage their code more effectively.

• Stash: This command allows you to temporarily save the changes you have made to your modified files in your current working branch without committing them. This is useful when you want to switch contexts or branches but are not yet ready to commit your work.
• Switch: This command is used to move between different active branches of development within your repository. It enables you to quickly and efficiently switch your working branch, making it possible to work across features or fixes.
• Diff: This command compares two different branches and highlights the differences between the files contained in each. It is particularly useful for reviewing changes, understanding what has been modified, and preparing for merges or code reviews.

Remote Repository Commands

These commands and concepts are commonly used to facilitate interaction between the local repository on your personal computer and a remote repository hosted on a server. They help synchronize and manage changes efficiently across different environments:

• Fetch: This command downloads commits, branches, and tags from a remote repository into your local repository. It allows you to see changes made by others without merging them into your working branch immediately.
• Pull: This command fetches changes from the remote branch and then merges those changes directly into your current working branch. It is a convenient way to update your local branch to the latest remote changes in a single step.
• Push: This command sends your committed changes from the local working branch to the designated remote branch. It is used to share your updates with others and keep the remote repository up to date with your work.

Merging

When developing, code differences and conflicts can arise when multiple developers work on the same file across different branches. When this occurs during a merge, it is called a merge conflict and must be resolved.

This is easily handled in traditional text-based programming environments using standard compare-and-merge tools like VSCode (free), which includes functionality for merging text files.

The following example shows a basic Python merge in VS Code. In this example, we had a main branch that was split off into another development branch, foo, which had its own function and function call added. During that time, the bar function and function call were added to our main branch. Because both branches modified the same file, a merge conflict was created. To resolve this conflict, we called git mergetool -t vscode to bring up the VS Code merge functionality. Git automatically understood what files to merge and what program to call because we configured the VS Code merge tool earlier.

The image of VS Code shows both branches (left/right) being merged, as well as the final merge result at the bottom of the screen. It is important to note that the developer could have chosen to merge the calls to the foo/bar functions without actually merging the function definitions. This makes this tool very powerful, but not error-proof.

For programs that are not text-based or are overly complicated to merge by hand, additional merge tools can be configured to simplify these conflicts.

Git and Logix Designer Compare Tool

As part of their standard product offering, Rockwell provides the Logix Designer Compare Tool to allow visual merging of Rockwell PLC code and to identify differences between PLC code. See the full Getting Results Guide from Rockwell.

This application not only offers a GUI for starting compare/merge operations, but also provides a full command-line interface to run them automatically. Based on our previous example with VS Code, the Logix Designer Compare Tool can be configured as a full git merge tool using the following commands. The path to the application can vary depending on where the tool is installed, which is accounted for by the additional path command.

git config --global merge.tool rockwell_merge

git config --global mergetool.rockwell_merge.path 'C:\Program Files (x86)\Rockwell Software\\'

git config --global mergetool.rockwell_merge.cmd 'RSLCompare.exe -m \$LOCAL \$REMOTE \$BASE'

After configuring the Rockwell merge tool, the development workflow operates exactly the same as if developing with a text-based language like Python, i.e., using standard commit, branch, merge, and push/pull commands.

Repeating the foo and bar example from earlier with Rockwell, I created a Studio 5000 ACD project with a single program/rung. From there, I created two branches of development:

• Foo – JSR to a new Foo routine, with basic logic
• Bar – JSR to the new Bar routine, with basic logic

When merging these branches, I encountered a merge conflict because the ACD file in both branches had been modified. I can resolve this by calling git mergetool -t rockwell_merge. This will tell git to take the file from both branches, as well as the base file they both originated from, and perform a three-way merge. The left content is the local branches, the right content is the remote branch, and the center content is the base branch that the local/remote branches diverged from. The following images show how this merge works:

After selecting all of our changes, we will select File → Save As… to save the resulting ACD file over our existing ACD file in our local repository. After we close the merge application, we can commit the merge result and push to our remote repository. Once this change is in the remote repository, other developers can use the same method to synchronize their code changes, enabling accelerated system development and programming.

Next Steps in DevOps

This tutorial introduced the basic concepts of Git, how to configure merge tools, and how to leverage them for Rockwell-based PLC development. Over the next few blogs in this series, we will review how to leverage Git and GitLab for continuous integration and continuous deployment (CI/CD).

In the meantime, you can work on refining your git skills and workflow with the following free resources:

• Git – Learn
• Git and GitHub learning resources – GitHub Docs
• Git Tutorials and Training | Atlassian Git Tutorial

The post Rockwell PLC DevOps: Modernizing Version Control appeared first on DMC, Inc..

Utilizing ACM and configurable library objects allow you to streamline development by deterministically generating the code you need based on easy to modify configurations. This saves time, reduces mistakes, and enforces approved coding standards. While this blog illustrates the use of a few specific AOIs, the concept can be extended to any objects in your development library. 

Planning the Routines and Programs

The first step is to define the routines and programs within the library to organize the logic being generated. For this example, the alarm logic is organized in routines within the MainLogic program, which is dedicated to alarms and other control logic such as sequences. The MainProgram is used to organize and generate AOIs for devices, such as transmitters, into related routines. Both program names are intended to be placeholders and will be modified via parameter substitution in ACM. 

In this example, Analog Objects are configured with LoLo, Lo, Hi, and HiHi status thresholds. The Lo and Hi thresholds generate alarms, while LoLo and HiHi generate shutdown conditions. Alarm handling is contained within a dedicated Alarm routine, and shutdown handling is contained within a dedicated Shutdown routine, as illustrated in the figure below. 

Next, we’ll need to define the routine for our devices. For demonstration purposes, this routine will house the AOIs for processing and scaling the input data from either in-chassis IO or from a Turck IO block. 

For this example, we will use the name “myRoutine” so that we can later modify it via parameter substitution in ACM.  

Programming the Routines

We will create an analog input routine consisting of two AOIs, AOI_TurckAnalogInputProcessing and AOI_AnalogInput.  

Analog Input Routine

The Analog Input routine will be structured to be fully configurable and allow the use with Turck I/O or without. This will be handled with configurable ACM parameters that will be explained later in the article.

The Turck Analog Input Processing AOI is intended to be used with a BLCEN-8M12LT-4AI-VI-4A-VI. This AOI will combine the two Bytes which make up the analog input raw value, which will then be passed into iInRaw tag of the AOI AOI_AnalogInput via configurable ACM parameters. If Turck I/O was not being used ACM will not generate the Turck logic and will insert the user’s preferred I/O tag into iInRaw of the AOI_AnalogInput AOI. 

Alarms Routine 

The Alarms routine will be used to configure alarm logic automatically if the AnalogInput is configured to have the corresponding Alarm(s). What does this mean? We will only generate Hi or Lo alarm logic if the input is configured to use them in ACM. In this example, we will use simple alarm bits with a global reset. 

Notice that the naming convention “C0000_myAnalog” matches the generic name of the AOI_AnalogInput that was added in the Analog Input Routine. This is done so we can use the parameter substitution feature in ACM to replace this text when generating code. 

Shutdowns Routine 

Similar to the Alarms routine, HiHi and LoLo shutdowns will be added to the Shutdowns routine if the analog input is configured to use them.  

Building the Library Object with Library Designer

From here, we’ll work within Rockwell’s Library Designer Plugin and configure the required text substitutions, parameters, and deterministic logic creation. 

Access the Library Designer plugin by right clicking the top of your controller organizer tree. 

Once in Library Designer, navigate to “myRoutine” to get ready to apply conditional expressions that will handle logic creation. 

In Library Designer, you can set up instantiation rules per rung, per ladder branch, and even down to logic components like contacts and coiles. Here, we will be applying a rule for a rung containing the Turck AOI. Select the rung by clicking it. A green box will appear indicating that the rung has been selected. 

Update the condition to control the creation of the logic. By default, the library will have the field filled in with “Always.”

This means that no matter what, this logic will always be created during the code generation process. For our example, we will only instantiate this logic if the configured IO is coming from a Turck IO device, which will be set using the parameter “bTurckIO.” 

This new parameter is added to the parameters section of our library object.  

With that rule configured, the Turck AOI will only be included if the device is configured as a Turck IO point, while the Analog Input AOI will always be included when we instantiate one. We will leave the condition set to “Always” for the AOI_AnalogInput so that it will always be added for every input we configure. 

Next, we will use the same concept for the Alarms and Shutdowns routines. Just like the Turck object, we will create parameters to define if an alarm should exist.  

In the Alarms routine, we will apply a conditional parameter for both the Hi and Lo alarm rungs. 

We will apply the same concept to the Shutdowns routine as well. These parameters are shown below. 

To demonstrate an additional option, we will add a conditional statement on the Alarms and Shutdown routines themselves. Just like choosing to instantiate rungs and small pieces of logic, you can choose to optionally create routines as well. Here, if no alarms or shutdowns are enabled, we will not create the respective routine. 

For Alarms we will require the following ACM parameters bAlarmLEnable (Low Alarm Enabled) or bAlarmHEnable (High Alarm Enabled) to be true.

For Shutdowns we will require the following ACM parameters bAlarmHHEnable (High High Alarm Enabled), bAlarmLLEnable (Low Low Alarm Enabled), or bAlarmOREnable (Out of Range Alarm Enabled) to be true. 

From here, we can jump to the Application Code Manager and see how we can enter values into the parameters to affect what is created with the logic during code generation. 

Application Code Manager Code Generation

To continue with our demonstration, let’s add an Analog Input instance within ACM. For the first instance, we’ll configure it to require the Turck I/O without any alarms. To do so, we’ll need to concentrate on the following fields. 

• Name – This field specifies the device name and is used to generate the corresponding PLC tag name. 
• sRoutineName – This field defines and creates the routine that the device will be instantiated in. 
• bTurkIO – This field is used to enable or disable the creation of Turck IO logic.  
• AI_ADDRESS – This field is used to assign the I/O tag to the AnalogInput AOI. In this example we use “TIT_100.iInRaw” so that it can be referenced by the Turck AOI output. 

Next, we’ll create an Analog Input instance that does not use Turck IO but has all its alarms enabled. For now, I will put a placeholder into the AI_Address that can be configured later once I/O is configured in the project.  Additional fields for alarm configuration will be used in this example.  

• bAlarmHHEnable – This field specifies if the High High alarm is enabled or disabled for the device. 
• bAlarmHEnable – This field specifies if the High alarm is enabled or disabled for the device. 
• bAlarmLEnable – This field specifies if the Low alarm is enabled or disabled for the device. 
• bAlarmLLEnable – This field specifies if the Low Low alarm is enabled or disabled for the device. 
• bAlarmOREnable – This field specifies if the Out of Range alarm is enabled or disabled for the device. 

Now we’re ready to use ACM to generate our code. To do so, right click on the controller in ACM and click Generate Controller. 

When the pop‑up dialog box appears, select Create ACD, enter the desired file name, select whether to overwrite the existing ACD file, and define the file path. 

After you generate the .ACD file from ACM you will see that the following routines and programs have been created.

If we open the AnalogInputs routine, we will now see the two instances, TIT_100 and PIT_100 that were configured in ACM.

You’ll see that the Turck Interface created only for the TIT_100 object based on the parameters we set. Note that PIT_100 was instantiated without the Turck AOI based on its parameterization. 

Now, let’s look at the newly generated Alarms and Shutdowns routines. In this example, alarms were only created for PIT_100 as TIT_100 was not configured to use them. 

Conclusion

While this demonstration was simple in nature, it illustrates the benefits that can be derived by creating your own library objects and utilizing ACM to autogenerate a significant portion of your PLC logic.  

These concepts can be extended to create much more advanced programs and routines based on configurable parameters. For very large projects, or for OEMs with very similar systems, this can significantly streamline the development process.  

Here at DMC, we leverage ACM as a powerful tool to accelerate development timelines, improve code standardization, and quickly modify projects to account for changing requirements.  

For more information on Application Code Manager, read our other articles:  

• Streamline Rockwell’s Application Code Manager with Excel 
• Importing and Customizing a Library with Application Code Manager
• How to Use Application Code Manager (ACM) with PlantPAx Distributed Control System (DCS)

The post How to Create a Configurable Routine Using Application Code Manager appeared first on DMC, Inc..

A quick reminder: NC host is used to monitor the status of MagneMotion controllers, motors, and movers. The NC host IP address should be the node controller.

MagneMotion Guide Series

• MagneMotion Guide Part 1: Creating Configuration Files
• MagneMotion Guide Part 2: Starting up and Commissioning a Track
• MagneMotion Guide Part 3: Controlling a System with a PLC
• MagneMotion Guide Part 4: Using Path and Station AOI’s
• MagneMotion Guide Part 5: Alternative Routing Controls
• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Guide Part 7: Traffic Lights
• MagneMotion Guide Part 8: Simulation
• MagneMotion Guide Part 9: Traffic Jam Prevention
• MagneMotion Guide Part 10: Moving Track
• MagneMotion Blog Part 11: Tuning

Track Graphic Files

Track graphics are files with the .mmtrk extension that are used to help visualize a MagneMotion system when using NC Host. For general information, see MagneMotion Guide Part 2: Starting up and Commissioning a Track.

Typically for MagneMotion Lite systems, track graphics are generated in the Magnemotion Configurator tool by going to File -> Export -> Create MMTRK File From Config 

Below is an example of a track layout file. 

Here is that same track’s corresponding .mmtrk file visualized in NC Host.

When monitoring the track graphic in NC Host, you can easily see where each vehicle is on the track. By hovering over track segments, you can also see which path of the track you are hovering over. 

These .mmtrk files are simple text files which can be opened in the text editor of your choice. If needed, you can also modify the track file to better fit your system. 

The track file components are simple. Each section starts with a comment describing the path that the section of the text file is defining. If you are making changes to a track file, it is advisable to include additional comments on whatever change is being made.  

Next, the track file defines the path connection. The path_start #a #b line indicates that you are defining path #a that has a previous path of path #b. Note that some paths have multiple previous paths defined in the configuration file, but only one previous path needs to be defined in the track file. This is because the track file is only concerned with the physical location of the path, not how it links to the rest of the system. 

Following the path definition, the file will contain information on each motor in the path. Starting from the first motor, there will be a line that contains the motor type and the motor’s direction. This direction corresponds to the orientation of the motor in the track graphic file. Everywhere the track turns, this direction should change for the next motor. 

In the examples below, note that the direction changes from “left” to “right” after the “motor_r_curve” entry to ensure that the track graphic follows the actual track layout from the configuration file. 

In track layout files, there are no separate definitions for switches. Instead of having a single entry for a switch on the track, there will be an entry for each path that the switch is on for both the straight and curved section of the switch. 

For example, for a right switch that merges paths 3 and 4, one path will have a “motor_q_meter” entry for the straight section of the switch, and the other path will have a “motor_r_curve” entry for the curved portion of the switch. 

In addition to defining the track, you can also modify the track graphic to change how vehicles are displayed in NC host. Adding a line setting the vehicle_size will change the size of the vehicle graphic displayed in NC Host to better match your system. 

Note that NC Host doesn’t do any verification that the track graphic you are using lines up with the configuration file of your system. If you end up using the wrong .mmtrk file, NC Host will still display the graphic and attempt to display where vehicles would be on the track even if path lengths and orientations do not match up. 

Disjointed Tracks

There are unfortunately some limits in the track graphics that can be created by the MagneMotion configurator tool. If any track is “disjointed” (i.e. completely separated from the rest of the track), then the configurator tool will be unable to generate the track file for that system. However, you are still able to create the track file for that system manually. 

Let’s say we have a MagneMotion Lite track where the majority of the track is in a loop on the ground. A part of this loop is a section of track that can be raised to connect to a stretch of track that is suspended by the ceiling. So, we have one track system that is split into different sections. 

You can’t get this track file directly from the configurator, but you can start by making the paths of just the ground track and creating a .mmtrk file from that partial section of track. 

Now, to add additional track segments to this file, we need to create a disjointed track section. We do this by adding another line that starts with “track_start” followed by parameters that determine where in your graphic the disjointed track will appear. For each new disjointed track added, you need to input the distance and angle from the very start of the track file to the start of your disjointed track. Then you simply need to add paths/motors to the file to match your system. 

If you’re having trouble calculating the position your added track can be in, you can always just display the track graphic to check the position and adjust as needed. 

Now, it’s a simple matter of repeating that same process to add the ceiling track. 

Note that there are other ways you can arrange your track. If you wanted to have your elevator track show up in line with the ground track loop you can tell the track graphic file to consider path 2 to immediately follow path 1 by just manually adding path 2 as a following path for path 1. 

Quickstick Track Graphics 

You can also manually create track graphics for Quickstick systems similar to how you’d create them for a disjointed track. The formatting of Quickstick .mmtrk files is a little different from MMLite track. 

Instead of being given a cardinal direction with each motor, Quickstick motors are each assigned an angle. This allows a track graphic to properly display the curved motors sections that Quickstick can allow. After each Quickstick motor entry, you can also enter a gap distance and angle to display the larger motor gaps allowed between Quickstick motors. 

Below is a straightforward example with a linear track. 

If the Quickstick angles are adjusted, you can also display a nice track curve. 

You can even combine methods to create disjointed tracks with Quickstick graphics to create complicated layouts involving things like rotary tables and moving path nodes. 

The post MagneMotion Guide Part 12: Track Graphics and .mmtrk Files appeared first on DMC, Inc..

MagneMotion Guide Series

• MagneMotion Guide Part 1: Creating Configuration Files
• MagneMotion Guide Part 2: Starting up and Commissioning a Track
• MagneMotion Guide Part 3: Controlling a System with a PLC
• MagneMotion Guide Part 4: Using Path and Station AOI’s
• MagneMotion Guide Part 5: Alternative Routing Controls
• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Guide Part 7: Traffic Lights
• MagneMotion Guide Part 8: Simulation
• MagneMotion Guide Part 9: Traffic Jam Prevention
• MagneMotion Guide Part 10: Moving Track

What is Tuning?

Tuning is the process of adjusting the parameters of your system that control the motion profiles used to turn motion commands (i.e., move this vehicle to this position) into mechanical movement. In the case of MagneMotion, tuning usually involves adjusting the Control Loop Parameters in the configuration file along with other advanced parameters that handle the system response to vehicles being out of position. 

While some systems have automatic tuning processes, MagneMotion tuning is a very iterative process. Typically, you’ll adjust tuning parameters before running your track, make observations about the current track behavior, and then iterate on the parameters again until system performance meets application requirements. 

Benefits of Tuning

There can be several different reasons why you would want to tune your system. The first is to ensure that vehicle motion is smooth. A properly tuned system will reduce vibrations and jerky movements from vehicle motion. 

Tuning can also be useful in increasing the overall throughput of your system. Mistuned vehicles can take longer to get up to speed or might slightly overshoot their targets, causing delays as they need to correct their positions. 

Similarly, tuning can also considerably reduce the current draw and thermal load on your MagneMotion motors. When a vehicle is moving smoothly and precisely, there is less need for the motors to draw an excessive amount of current to correct the vehicle’s positioning. 

Before you begin tuning your system, it is important to consider what your priorities are in tuning. A system tuned to optimize speed and responsiveness may look different from a system tuned to reduce thermal load. 

Configuration File Adjustments

See MagneMotion Guide Part 1: Creating Configuration Files for additional details.

The relevant parameters for MagneMotion tuning are found in the motor defaults section of the track. While you can adjust these parameters on a per motor basis, it’s usually a good idea to adjust them on a per path basis to keep vehicle motion consistent across your track. 

Here you can set up different sets of control parameters. To make use of a new set simply fill out the parameters and click the Enable check box. When commanding a vehicle to move (through NC Host or a controller) you can set the command to run at one of the PID sets configured here. Typically, it is a good idea to have a PID set for unloaded vehicles and another for vehicles that are loaded. Additional PID sets can be added, either to account for different load types or different types of moves along the track. 

Below is a quick description of each parameter used in a control set: 

Tuning Process

Using Virtual Scope

To properly tune a system, you will need to run a vehicle around your track while assessing whether the vehicle’s behavior is improved after each adjustment to the system’s control parameters 

While you can certainly do this by just monitoring the system, MagneMotion has created a tool to help gather more specific motion data called Virtual Scope.

The Virtual Scope tool gathers data about a vehicle’s position error, velocity, and current use as it moves along a motor of your track. 

To use Virtual Scope in your tuning process simply hit the setup button and input the IP address of your HLC controller along with the vehicle ID you are planning on tracking and the path and motor you are running your tuning tests over. 

Note that for a running system it can be tricky to line up a scope of a specific vehicle crossing a specific motor. Make use of NC Host’s ability to track vehicle positions to setup a trace before the vehicle approaches the motor you are monitoring. 

When a profile is captured, you can select which parameters you wish to display. You can also choose to set up a data capture to record the data from the scope into a .csv file for additional analysis. 

Data Streams

The Virtual Scope tools make use of data stream files to determine which data it is capturing from the MagneMotion motor. By default, virtual scope uses a data set that includes information on the vehicle position, error, and velocity.  

The virtual scope tool can gather additional information on things like motor temperature, power specifics or other details if the scope tool is loaded with different data streams by going to “Advanced” -> “Load Data Stream.” Rockwell does not publish these data stream files, but you can reach Rockwell ICT’s support team for alternative data streams if needed. 

Using NC Host

While you can certainly run your tuning by setting up a PLC program to run tests, it is often easier to use NC Host to control a singular mover instead of spinning up a whole PLC program or modifying your production code. 

For more details on NC Host see MagneMotion Guide Part 2: Starting up and Commissioning a Track.

NC Host also has a tool that allows you to use a temporary set of PID parameters to reduce the number of times you’ll need to change the configuration file of your system. This means you can try out PID values without needing to restart your system. (Note that any parameters changed through NC Host will be reset the next time the system restarts or the relevant path is reset). 

Other Tuning Considerations

On top of the typical PID-based configuration adjustments, there are also several additional configuration modifications that can be made to improve your system’s behavior. 

Disable Control Thrust

 If a vehicle is having trouble settling into position, the configuration file can be adjusted to disable the control thrust on a vehicle when it is within a certain tolerance of its target. This comes at a cost to how closely the vehicle will hold to its destination but removes any oscillation or additional thrust from a vehicle that is within tolerance of its position. 

Motion Limits

If you are having trouble ensuring smooth motion on your vehicles, configuring a stricter velocity limit or acceleration limit can prevent the vehicle motion from overshooting its target too aggressively at the cost of overall system speed. Importantly, this also is the easiest way to reduce temperature issues on a motor. 

Arrival Tolerance 

Similarly, if a station has too large of a settling time where vehicles are adjusting themselves to get into a station position, you can adjust the arrival position and velocity targets. This way, if on that particular path vehicle tolerance is not too strict, you can reduce the delay between when a vehicle arrives at its destination and when MagneMotion indicates that the vehicle is in position. 

This parameter only affects when MagneMotion considers a vehicle ‘in position’ and does not change the motion profile of a vehicle. 

Host Controller Communication 

You can also potentially reduce settling time by adjusting the system’s communication with its host controller. For high throughput systems, changing the Send Vehicle Status Period or the Vehicle Records/Status Period values can reduce the delay caused while waiting for the Node Controller to tell the host controller that the vehicle has arrived. Care should be taken when adjusting these values to ensure that you are not overloading the communication resources of the Node Controller or the Host Controller. 

On a host controller, this update frequency also depends on the cycle time of the MagneMotion device handler. 

Also note that these settings are specifically for systems that make use of Rockwell’s ICT library, see MagneMotion Guide Part 3: Controlling a System with a PLC. 

The post MagneMotion Guide Part 11: Tuning appeared first on DMC, Inc..

The competition will take place over a day and a half, Monday and Tuesday of Automation Fair week, with the winning team announced on Wednesday at 2:30 PM on the Discovery Theater stage.

DMC’s team of experts will be competing against six other teams for honor and glory in a coding challenge that incorporates FactoryTalk Optix, FactoryTalk DataMosaix, FactoryTalk Analytics LogixAI, Studio 5000 Logix Designer, FactoryTalk Historian Site Edition, and Plex.

Good luck to all the teams competing!

Exploring the Expo? Visit us in Booth #752

Stop by our booth to connect with our team, explore our latest automation solutions, and see our custom-built “Drop Bot” in action.

Test your skills against Drop Bot in a life-sized game of Connect Four or challenge your colleagues to a game.

Will we see you at the show? Let us know!

Connect with Us

The post DMC is Competing in the 2025 ROKathon! appeared first on DMC, Inc..

Exploring the Expo? Visit us in Booth #752

Stop by our booth to connect with our team, explore our latest automation solutions, and see our custom-built “Drop Bot” in action.

Test your skills against Drop Bot in a life-sized game of Connect Four or challenge your colleagues to a game.

Will we see you at the show? Let us know!

Connect with Us

DMC is Competing in the 2025 ROKathon!

DMC is excited to be participating in the first-ever ROKathon coding competition at Rockwell’s Automation Fair 2025!

DMC’s team of experts will be competing against six other teams for honor and glory in a coding challenge that incorporates FactoryTalk Optix, FactoryTalk DataMosaix, FactoryTalk Analytics LogixAI, Studio 5000 Logix Designer, FactoryTalk Historian Site Edition, and Plex.

The competition will take place over a day and a half, Monday and Tuesday of Automation Fair week, with the winning team announced on Wednesday at 2:30 PM on the Discovery Theater stage.

Good luck to all the teams competing in this new challenge!

What to Expect at the Rockwell Automation Fair

Automation Fair 2025 offers attendees the chance to:

• Gain new insights from 400+ domain expert presenters.
• Explore 120+ interactive exhibits with new technology and solutions.
• Connect with 10,000+ professionals in industrial operations.
• 450+ hours of training opportunities and hundreds of solution showcases & more!

DMC and Rockwell Automation

As a Rockwell Automation Gold System Integrator, DMC is proud to demonstrate our expertise in advanced integration and custom engineering solutions. Our session highlights how we apply FactoryTalk Optix and C# to real-world customer challenges, delivering both innovation and measurable impact.

Don’t miss the chance to connect with the DMC team at Automation Fair 2025. Register today and meet us in Chicago at Booth #752.

The post Join DMC at the 2025 Rockwell Automation Fair appeared first on DMC, Inc..

The DEI Award honors a Rockwell partner that has made DEI part of its business strategy and taken steps to make the industry more diverse. 

Giana Fallara, Systems Engineer, and Marilyn Sedlak, Project Engineer, accepted the award on behalf of DMC by video. Kristie Shea, Vice President, accepted the award in person at the PartnerNetwork Conference. 

“One of DMC’s core values is to make things happen. The employee-driven nature of DMC’s DEI efforts make them personal, impactful, and flexible to meet the actual needs of employees,” said Fallara. 

DMC supports diversity, equity, and inclusion through Employee Resource Groups (ERGs) created by DMC employees who share a minority identity. Additionally, the FRIEND (Fostering Relationships, Inclusion, Equity aNd Diversity) user group at DMC encourages community members to share their experiences and identify areas for improvement. Beyond the company workforce, DMC is a proud sponsor of Society of Women Engineers (SWE) chapters at a handful of universities. 

“Rockwell’s prioritization of DEI initiatives meshes with DMC’s focus on creating a workplace culture where everyone feels safe, supported, and valued,” Sedlak shared. “This is one of the factors that contributes to our successful partnership.”

This recognition reflects DMC’s ongoing commitment to creating an inclusive culture where every team member feels empowered to thrive. 

DMC previously received the 2024 Rockwell System Integrator Innovation Award at the PartnerNetwork Conference. 

The post DMC Receives DEI Award from Rockwell Automation appeared first on DMC, Inc..

Typically, a MagneMotion track is designed to fit a 2D profile, the track might turn left or right but not up or down. While this is sufficient for most MagneMotion applications, sometimes systems are designed to lift or move MagneMotion track out of its typical 2D plane.  

Whether this is to move MagneMotion closer to tooling or to transport MagneMotion vehicles from one level of track to another, configuring this type of track involves careful modifications to the typical MagneMotion system. In this blog we’ll review general guidelines on how to handle these situations. 

Note: This blog is for MagneMover Lite systems only. QuickStick systems have a built-in feature of linking and unlinking paths which is a preferred way to handle this issue.

MagneMotion Guide Series

• MagneMotion Guide Part 1: Creating Configuration Files
• MagneMotion Guide Part 2: Starting up and Commissioning a Track
• MagneMotion Guide Part 3: Controlling a System with a PLC
• MagneMotion Guide Part 4: Using Path and Station AOI’s
• MagneMotion Guide Part 5: Alternative Routing Controls
• MagneMotion Guide Part 6: Track Recovery Considerations
• MagneMotion Guide Part 7: Traffic Lights
• MagneMotion Guide Part 8: Simulation
• MagneMotion Guide Part 9: Traffic Jam Prevention

Step 1: Creating the Track Layout 

When laying out track, any moving segments of track should be carefully considered. You will need to account for any moving track in your system configuration, but different tracks have different considerations. 

Terminus Nodes vs. Relay Nodes 

Regardless of how the track is set up it is often a good idea to define any moving track as its own specific path. This allows the host controller to suspend or start that track section independently and makes it much easier to follow if there are any vehicles on the track. 

If the track is simple, you can usually add relay nodes to your system to break out your lifting path. In the below example, a single meter of track would be used to raise carriers from a ground section of track to a raised section of track. 

Here, you can maintain a simple track setup. Vehicles can still be sent from the ground track to the lift track or from the lift track to the ceiling track using the same typical motion commands that you’d use in other parts of your MagneMotion System. 

However, some tracks are more complicated to set up. Since MagneMotion is constrained to 2D systems any track that requires having multiple motors in the same two-dimensional position will require more a complicated track configuration to set up. 

In the example below, the track has been set up with a lift that can move vehicles to any one of three different levels of track. 

In this example, the track must be configured so that the different levels of track are considered separate from the rest. While regular vehicle commands can still be used to pass vehicles from the left ground track to the lift track, any vehicles sent from the lift track to one of the right-side tracks will need to be done with a terminus node handoff. 

Terminus Node Considerations 

In general, this terminus node-based configuration should be reserved for tracks where alternate configurations are not possible. While these terminus nodes will function, they come with some additional caveats. 

While terminus nodes can be properly simulated, you will need to add additional simulation logic to your PLC to properly run a simulation test of your system. Since MagneMotion will not know that the track on either side of the terminus node spot is next to each other when a vehicle exits through one terminus node it will not automatically appear on the other track section. Spoofing logic will be required to create an additional vehicle to receive it on the other track. 

Also, while MagneMotion supports disjointed tracks, many of the MagneMotion tools used in generating files will not work for non-contiguous tracks. For example, the “walk the paths” action will only create a configuration file with the paths of one disjointed section, any additional paths and nodes will need to be added manually. Similarly, the configurator tool cannot generate an .mmrtk file from the configuration of a disjointed track (though you can manually create an .mmtk file on your own using any text editor). 

Terminus nodes also require more programming overhead to control and manage. Moving vehicles across a terminus node is more complicated than regular MagneMotion motion commands. 

Step 2: Controlling Motion Across Your Lift 

Once you have your track laid out, you need to consider how to best control the movement of vehicles across your track.  

Having moving track in your system adds another considerable risk to your project. If a vehicle is commanded off the lift track at the wrong time it can fly off the lift into empty air and hurt anyone nearby. While you could theoretically control your lift track the same exact way you control all your other track, it is always a good idea to add some extra precautions when dealing with moving track.  

It is also worth noting that MagneMover Lite is not a safety-rated system so including reasonable mechanical constraints in your system is also a good idea. Ideally, any system would be set up so that no matter what, a vehicle wouldn’t fall off the track. 

Mechanical Restrictions 

Implementing simple solutions like mechanical guarding around your track can help prevent incidents. Alternatively, adding cylinders to the end of a track that actuate to restrict vehicle motion can help ensure system reliability even if power is lost to the MagneMotion track. 

There are countless ways to design a system to prevent issues with moving track. It is important to consider the possible failure modes of the system and ensure that they are accounted for in the design. 

Traffic Lights 

Traffic lights are used in MagneMotion systems to stop vehicles in certain spots of the track. For more information see MagneMotion Blog Part 7: Traffic Lights. 

Where moving track is used, it can be useful to keep traffic lights on either side of the track. 

To help ensure that no vehicles are commanded off the end of the track, the lights will be set to turn red when it is not safe for a vehicle to cross. 

It is important to note that the traffic light setting is not instantaneous. Not only is there a slight delay in a command for a traffic light being sent from the host controller, but any incoming vehicle will need time to decelerate before the traffic light. This means that when using traffic lights, they should be set to red before the moving track starts to get out of position to ensure there are no issues with incoming vehicles as the track is moving. 

Another consideration is that while traffic lights are defined as a single point on a track, they can take up a fair amount of space. When a vehicle is approaching a traffic light it will maintain a distance between itself and the traffic light based on its configured vehicle length. 

This means that track lifts can run into situations where there is insufficient space to have traffic lights and move vehicles onto the lift track. 

Keepout Areas 

Another tool MagneMotion has for controlling vehicle flow is the creation of keepout areas.  

Keepout areas are configured spots on the track that are set up to make it less likely for vehicles to come to a stop in those spots. When a vehicle approaches a keepout area it will only continue into the area if it has permission to move through the entire area. 

This means that vehicles will not get stuck in a keepout area when they’re backed up, but they will still be able to move through them if the track is clear. Similarly, any vehicles in the keepout area when the track suspends will continue moving until they are outside of the area. 

Unlike traffic lights, keepout areas cannot simply be turned on and off. They are defined in the MagneMotion configuration file and require updating that file and rebooting the system to change. 

Defining Keepout Areas 

Keepout areas are defined in the configuration file on a per motor basis. Each keepout area only applies to upstream or downstream motion. If vehicles will be moving across the keepout area from either direction make sure that both are configured correctly.  

For setting up a keepout area for moving downstream, the “No Move Permission After” parameters need to be set for each motor in the keepout area. The value should correspond to the distance between the start of the motor and the beginning of the keepout area (a value of 5 meters means this parameter is ignored). 

In a keepout area that extends several motors, the first motor in the chain may have a positive value for where the keepout area begins but each motor after it needs to indicate that the keepout area began upstream of it. This means that each downstream keepout area needs to end on the endpoint of a motor. 

Similarly, for defining keepout areas moving upstream simply reverse this process using the “No Move Permission Before” parameter. Here the value means the distance from the start of the motor to the end of the keepout area (a value of -1m means that the motor is not in a keepout area). 

Using Keepout Areas 

For the use case of a lift or other moving track, a keepout area can be used to ensure that a vehicle does not stop halfway on the moving track during normal track operation. 

This will reduce the chance of a mechanical failure where the lift tries to move while a vehicle is in the way. 

Learn more about DMC’s MagneMotion programming expertise and contact us today to get started on your next project. 

The post MagneMotion Guide Part 10: Moving Track appeared first on DMC, Inc..

Part Three: Operators Empowered

August 14, 2024 – 10:00 AM CT (5:00:00 PM CET)

Paul Haikal, Rockwell Automation Commercial Portfolio Manager and Mark Hobbs, Rockwell Automation Software Senior Product Manager, will close out the three-part series with a webinar on empowering operators. The session will include the following:

• Remote access tools allow the timely flagging of issues and the notification of maintenance.
• Out-of-box standardized content ensures consistency across machines and supports simplified operator training, safety, and troubleshooting as well as maintenance.
• Collect, contextualize, and deliver relevant data to operators to enable faster decision-making, minimize downtime, and maximize machine efficiency.

Previous Webinars

This goal of the three-part webinar series on the FactoryTalk Optix portfolio is to provide overview of how this end-to-end HMI solution can revitalize HMI operations across your equipment lifecycle. 

The series deep dives into how best to design and test your HMI projects directly from a web browser with collaborative workflows and version management, create your application once and deploy at scale to many devices, and empower operators with relevant data for faster decision-making.

• Part One: Design & Collaborate Webinar
• Part Two: Deploy Applications at Scale

Learn More About FactoryTalk Optix

Ready to learn more? DMC created a blog series on FactoryTalk Optix, the next generation of visualization software from Rockwell Automation.

• FactoryTalk Optix Series 1 – Getting Started with FactoryTalk Optix
• FactoryTalk Optix Series 2 – Variables, Attributes, Dynamic Links, and Converters
• FactoryTalk Optix Series 3 – NetLogic Overview and Examples

DMC and Rockwell

DMC is a Rockwell Gold System Integrator. We are proud to be recognized for our expertise in implementing the full suite of Rockwell Automation technologies for our customers.

A recent recipient of the 2024 Rockwell System Integrator Award, DMC is always eager to stay updated on Rockwell’s latest developments and technologies, including FactoryTalk Optix.

The post Join Rockwell Automation’s FactoryTalk Optix Webinar on August 14 appeared first on DMC, Inc..