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..

In this scenario, I will be using VMWare as our virtual machine software, RSLogix as our automation software, and an eWON module as our remote access hardware. Other solutions such as Virtual Box, TIA Portal, and Tosibox should have similar setup. However, I will not cover them here.

Step One:

Start eCatcher on your host machine and connect to your remote eWON module. This should add an additional network adapter when you open Network and Sharing Center in your host.

The eWON module should automatically set a static IP address. You can find this by clicking the blue text next to Connections.

Step Two:

Select Properties and find Internet Protocol Version 4. Select that option and click into its properties.

You should see something like this:

Step Three:

Next, you will setup a NAT connection on you VM. To do this, open the Virtual Network Editor. It is important to set this up through the VNE because sometimes issues can result from simply selecting a NAT connection through the Settings tab. The example below is how it should look when set up through the VNE.

Step Four:

Go to the settings tab and make sure that you are connected to the VMNet that we just configured to be NAT.

Just to double check that the network settings were properly applied, hover your mouse over the your network connection in the bottom right corner of your VM. You should see Network Adapter: Custom (VMNetX) in the tool tip.

Step Five:

Go to the Network and Sharing Center of your VM to ensure that your IP settings are set to automatic. It should look like this:

Step Six:

Open your RSLogix Project as well as RSLinx. Inside of RSLinx, go to the Communications tab and click Configure Drivers.

Add a new Ethernet Devices Driver to the Configured Drivers list.

Now, inside of RSLogix, click the Communications tab and select who active. Here, you should find the ethernet driver and the station you entered earlier. 

Select the PIC to complete the process and go online.

FAQ:

Q: Why is browsing the network is taking a such a long time?

A: Try connecting to the PLC directly and not browsing the whole subnet.

Q. My device has a yellow question mark next to it and I can’t go online because the button is grayed out (shown below).

A: This means that you do not have the EDS file installed. By right clicking the device you can select install EDS and then walk through the installation steps.

Learn more about DMC’s Allen Bradley PLC Programming services and contact us with any inquiries. 

The post Connecting to an Allen-Bradley PLC through an eWON Module appeared first on DMC, Inc..

With these newer models, you can easily create configurable tag-based alarms in Logix Designer, which can handle all the logic that was previously contained within the program’s ladder logic. This includes debounce timers, deadbands, and much more. Tag-based alarms also do not contribute to scan time like ALMA and ALMD instructions do, so it is advisable to use them if your PLC and firmware version permit it.

Adding and Configuring Individual Alarms

To add a tag-based alarm for a specific single tag browse under the proper scope, right-click RealAlarm and select “Add Alarm for “[Tag Name].”

This menu should pop up next: 

From here, you can configure the following properties:

• Name: Set the name for the alarm as it will appear in the Logix Designer ‘Alarms’ page and the ‘Alarm Name’ column of the View Designer Alarm Summary object. Note: Alarm names do not have to be unique between two separate owners, but a single owner cannot have multiple alarms with the same name.
• Input: This is the tag associated with the alarm, which is triggered based on this tag’s value in relation to the defined expression.
• Condition: Here you use the “Expression” and “Limit” to determine the conditions under which the alarm is triggered. I’ve set it to trigger when the value of RealAlarm is more than, or equal to, 4800. The “Type” category is mostly just used for organization and clarity for operators. It will be displayed in the Condition column and does not affect the behavior of the alarm.
• On/Off Delay: Configure debounce timers for the alarm to trigger and deactivate respectively. Values are entered in milliseconds and must be divisible by 500.
• Deadband: This is the minimum difference between the input and trigger values that must be met before the alarm can be deactivated. For example, if I set my deadband to 300, then the input would have to fall to 4500 before the alarm can be turned off.
• Severity: Severity ranges from 1 to 1000 and higher values indicate more severe alarms. More severe alarms will be displayed more prominently in alarm-viewing objects and various icons will be used to indicate severity.
• Message: This is the message that will be displayed along with the alarm when activated. This can be a static message, or you can use the editor to tie tags to your message. This allows for a richer and more dynamic display of information (more on this later).
• Associated Tags: Here you can add up to four tags that are relevant to your alarm, which you can use in your message text.
• Shelving: Shelving is sort of like hitting the snooze button on your alarm. Here, you can set the shelve duration and the maximum duration for which it can be shelved.

To better demonstrate the functionality of the message editor and dynamic texts, let’s go through a quick example where I add an associated tag and integrate it into our message. To add an associated tag, hover over “Name” and click the button with an ellipsis.

This menu should pop up: 

Select the tag you would like to associate with your alarm. Once added, you’ll see it in the “Associated Tags” menu. For my example, I’ve added a bool that indicates when a valve to the tank is open.

Additionally, you can create an entirely new tag and link it to your alarm by clicking the “New Tag” button in the alarm configuration menu. Now that we’ve added our associated tag, let’s use it in our alarm message. Click the button next to the message text box that says “Editor.” It should bring up a menu that looks like this:

Under the variable dropdown menu, you can select the alarm’s input, any associated tags, or other parameters related to the alarm—and then add them to your message by clicking “<- Add.” I’ve set my alarm to display “Level Exceed High High Limit [Current Level] >= [Configured Limit] Infeed Valve Open [Valve State].” This tells the user that the alarm is triggered, by how much the current value exceeds the alarm trigger value, and whether the infeed valve is open. As you can see, this editor allows for highly configurable and dynamic error messages to be set. Additionally, if someone were to change the limit that triggers the alarm, the message would update automatically.

Once an alarm has been made and configured, you can edit it by going to the alarms page under “Alarm Manager” -> “Alarms” in the controller organizer. You can also directly add alarms from this page by right-clicking anywhere and selecting “Add Alarm.”

Below is an example photo of the alarm summary graphic in View Designer. Higher priority alarms are indicated by a red circle with two exclamation points.

Adding Alarm Definitions

Oftentimes, adding individual alarms can be cumbersome because of the large volume your project requires. In this case, you can save a great deal of time by writing modularized code that makes use of user-defined types (UDTs) and AOIs then configuring alarm definitions based on these. An alarm definition is an alarm linked to the definition of an AOI or a defined datatype, such as a UDT. Whenever an AOI or a defined datatype is created, then alarms will be added for each alarm definition.

There are some exceptions, however. When an InOut parameter, safety tag, or alias tag uses an AOI or a UDT with associated alarm definitions, then alarms will not be generated. This is because alarms are not supported on InOut parameters, safety tags, or alias tags.

It should also be noted that you cannot create an alarm that’s directly linked to a tag from an instance of UDT or AOI. In other words, if you want to have an alarm tied to a tag in an AOI or UDT, then you need to either use an alarm definition or use a separate tag with the original tag’s value and use that for the alarm.

To create alarm definitions, click on the corresponding tab in the controller organizer under “Alarm Manager” > “Alarm Definitions.” Right-click anywhere within this window and select “Add Alarm Definition,” and it will bring up a menu nearly identical to the menu for configuring individual alarms:

From here, you configure the alarms just like you did for the individual tag-based alarms, but with one slight difference. When you click the ellipsis button to assign an input, rather than choosing a specific tag instantiated in your program, you will select a tag from the definition of an AOI or a defined type. When selecting a tag from an AOI, only inputs and outputs to the AOI will be accessible—InOuts and local tags cannot be used here. The selection menu should look like this:

As an example, we’ll make a few alarm definitions using this SCP AOI. This AOI takes in pre-scale and post-scale min and max values, along with an input value to be processed, then scales and outputs that value accordingly. We call this AOI from inside our analog input processing AOI, so any instance of aoiDvc_AnalogInput will trigger the creation of these SCP alarms. Here’s what we have after making a few alarms for SCP’s output.

Now if we instantiate the SCP or aoiDvc_AnalogInput AOIs anywhere in the code, these four alarms will be created for each instance. As an example, I’ve added an aoiDvc_AnalogInput in the Controller Tags and Main Program Tags and an SCP instance in the Controller Tags. We get the following result on our Alarms page:

(Note that because “Required” was not checked off in our alarm definition, the “Use” column is not checked off for any of the created alarms. Always remember to check off “Use” for any alarms you want active in your system.)

Even though these alarms are all identical upon instantiation, we can still edit them after they’re created without affecting the alarm definition. For instance, maybe you want AI_2’s high alarm limit to be 80 instead of 90. Simply double-click the alarm and adjust the limit from the configuration menu.

If you need to make changes to your alarm definition after you’ve created it, then you should be aware that changes to some properties, but not all, will be pushed to related instantiated alarms. Changes to the name, type, expression sign, message, and associated tags will be pushed to existing alarm instances. Changes to the limit, on and off delays, dead band, severity, and shelving durations will not be pushed to existing alarms and each alarm must be edited individually. Lastly, the input tag used for an alarm definition cannot be edited at all after creating the alarm definition.

Accessing Properties of Alarms

Another advantage of tag-based alarms is that many of the associated properties can be accessed from your program. This utility has many benefits like using your alarm’s status, fault state, or another property in your controls, or adjusting properties like the on/off delay, limit, or enabled/disabled state from the HMI. When planning out your program, it is important to remember that properties for tag-based alarms that are local within an AOI will not be accessible outside of that AOI’s logic. However, they will still be accessible from the HMI (provided they are configured for external access). The syntax for accessing these properties is as follow:

[Tag Name].@Alarms.[Alarm Name].[Property]

If an owner has alarms that were generated via alarm definitions, then it will also have a set of properties related to its collection of alarms, like the number of unacknowledged alarms or the name and type of its highest severity alarm. For these properties, the syntax is as follows:

[Tag Name].@AlarmSet.[Property]

Other Configurable Alarm Properties

So far, we have only discussed the items within the ‘General’ tab of the alarm configuration menu. There are still three tabs, which I’ll give a brief overview of:

The “Class/Group” tab lets you define classes and groups for your alarms. These are mainly just used to help organize your alarms based on function, type of alarm, what piece of equipment the alarm is related to, or practically any categorization that fits your application. Classes and groups can help organize your alarms during both design and runtime.

The “Advanced” tab allows you to configure some key properties that affect the behavior of your alarms. The “FactoryTalk View Command” is a command that is executed when someone selects the alarm on an alarm viewing graphic then clicks a button to execute the command. From this tab, you can also choose whether an alarm latches or requires acknowledgment before it will go away. For more on how to set these commands, I recommend checking out Rockwell’s guide to Alarm and Event Configuration

From the “Status” tab you can see various statistics related to an alarm. Additionally, you can acknowledge, shelve, disable, or reset an alarm from Logix Designer.

Conclusion

Tag-based alarms can be an extremely useful tool to save you time programming and reduce the scan time of your program. However, there are a few key things to consider when implementing them:

• Tag-based alarms are only usable with newer models of PLCs. You’ll need at least firmware V31 and one of the following products:
  • Compact GuardLogic 5380
  • CompactLogix 5380
  • CompactLogix 5480
  • ControlLogix 5580
  • GuardLogix 5580
• Alarm-definition alarms will not be created for InOut parameters, safety tags, or alias tags.
• When making alarm definitions for an AOI, only inputs and outputs can be tied to alarms.
  • InOuts and local tags will not be accessible for use as the alarm input
• Tag-based alarms cannot be configured for an individual component tag of an AOI or UDT.
  • You must create an alarm definition for the AOI or UDT
• The properties of tag-based alarms can be read and written in your program and HMI, provided external access has been set appropriately.

Learn more about DMC’s Rockwell PLC and HMI programming expertise and contact us to get started on your next project. 

The post Utilizing Tag-Based Alarms in Logix Designer appeared first on DMC, Inc..