Is Micrologix 1100 Obsolete
Bridgette Kubis
We are living in an ever-connected world. It is expected that by 2025, there will beover 75 billion connected devices worldwide. And while personal gadgets, smart homes and smart cities account a largepart of those devices, there is an equally fervent push to digitize andautomate factories as well. One estimatestates that by the end of 2020, 80% of manufacturing companies will adopt sometype of IoT technology. And the sameurgency of adoption is taking place in utilities, transportation and logistics.
In the industrial, warehousing and utilities sectors, much ofthis control is aimed at empowering the automation of equipment to performtasks at a faster, more accurate and more productive rate. And this equipment needs control systems andever improving control technology to adapt to these new requirements.
It is easy to assume that these requirements involve largeand complex buildouts connecting an entire factory or enterprise. And while that is certainly the case forlarger companies, there is still the need for small, compact control systemsthat provide the same level of control as their larger cousins but are builtsmaller for a variety of reasons. Theneed for smaller, or even standalone, control systems include:
Their communications channel allows for simple connections toPCs for full-duplex protocols and for tasks such as uploading and downloading. Whilethe MicroLogix 1000 and 1500 are now obsolete, the 1100, 1200 and 1400 arestill in service.
Introduced in 2011, the Micro 800 Allen-Bradley family represented a completely different architecture and platform than the MicroLogix controllers and is designed specifically for standalone equipment. Envisioned as a product to allow flexibility in purchasing what was needed without unwanted functionality for those types of machines, Micro 800 family products allow users the benefits of a micro PLC at a price comparable to a smart relay.
Both Family groups use Modbus RTU protocolswhere, except for the 810, the Micro 800 group can use ASCII/Binary and CIPSerial along in addition to Modbus RTU server/client. This group also allows Modbus TCP. TheMicroLogix group, however, is more flexible in its available protocols allowingDF1 half-duplex server/client, as well as ASCII. All three have 1761-NET-ENI ethernet/IP.
This nearly doubles the number ofI/Os on the 820 and 830 while allowing as many as 132 on the 870. The base Micro 810 does not have plug inaccess. However, the 810 does allowanalog I/O channels as does the 820, while in the 830 and 850, analog channelsare only available through use of plug ins.
Almost all Micro 800 family productshave higher memory capacity for user program and data space. The low end is the 810 at 2K/2K for programsteps/data bytes. The rest of the 800family is almost double the data capacity compared to the MicroLogix familyalthough actual data bytes vary based on number of pins.
In addition to the use of two different platforms, the Micro 800 and MicroLogix families are different in approach. The Micro 800 was designed to be modular to allow introduction of flexibility based on different needs for an ever-growing list of needs by modern connected equipment.
In contrast, the MicroLogix familyrepresents an older technological reality where functionality was embedded, andavailability depended on how far up the structure in capability and cost theuser wanted to go.
As a result, except for PID loopcontrol, floating point math and a real-time clock, which are all available onall models within both family groups, additional functionality is completelymodular in the Micro 800 group except for the 810 which only supports an LCDdisplay and a USB adaptor..
Additional functionality can beachieved in the Micro 800 group by a wide variety of plug in modules. Using these modules, either additionalprocessing power or additional functionality can be added. It also allows addedcommunication capability as well. Exceptfor the Micro 810 base unit, these modules include:
On the other hand, the embedded features of the MicroLogix family,while not as flexible or affordable as the 800 group, allow small controllersthat can fit into tight spaces for perhaps more rugged environments.
When added to the differences in the software, both MicroLogix and Micro 800 family controllers still each have their use. But while the 800 series group was not intended to be a one to one replacement for the MicroLogix family, as the power of connected factories grows, the use and importance of agile and flexible software platforms will mean that more and more control systems will be built on such platforms, driving a cause for migration from MicroLogix to Micro 800 family products or other Allen Bradley products that can handle the requirements of the modern connected factory.
The implementation and support of Ethernet/IP would be a great add on protocol for the SCADAPack 47x and 57x. This will allow for a great range of products supported where the client has an existing standard in place. This again ties in with DTM's where an EDS can easily be loaded and a DDT automatically created for integration.
I would have to concede on the EDS / DTM for Ethernet/IP CIP devices unfortunately. For the most part they are just not practical to hand create since they have lots of different property types / codes associated with them. It's not a flat address map like Modbus has.
I think the idea would be similar to other Ethernet/IP CIP clients. An EDS file would be imported into RemoteConnect, an instance of such a device could be created and given a 'friendly name', assigned an IP address, and configured for an update rate (RPI).
Ethernet/IP CIP is definitely not the simplest protocol around, but hopefully some of the development done with Geo SCADA Expert could be leveraged for the SCADAPack... (although perhaps the IP for these two product families are owned separately).
Ethernet/IP CIP is certainly gaining momentum right now, as are OPC UA and PROFINET. Which of these three would be the highest priority for you and what types of devices/systems would you use your selection to connect to?
For Ethernet/IP CIP and Profinet, I don't believe it makes much sense to consider a SCADAPack as an Ethernet/IP CIP Server/Slave (i.e. just an IO device). However for the OPC UA, it's the opposite. It makes more sense in regards to OPC UA to have the SCADAPack be a device and not a scanner. And Profinet isn't hugely popular (at least here in AU..), most devices which support Profinet also now support Ethernet/IP CIP.
I would agree with Bevan's priority order. Allen-Bradley devices are everywhere here in the USA and being able to talk to them in their native language would be a definite plus for the SCADAPack line.
There is a large install base of Rockwell Micrologix 1100, 1200 and 1400 PLCs (and even a few SLC500s) within the Water Industry here in NZ in remote type applications, communicating either over legacy serial links or more modern ethernet radio links.
The 1100 and 1200 are now obsolete, with the 1400 likely to end up on the chopping block within the next few years. Rockwell's Micro800 line which is meant to be the replacement for the 1100, is in my opinion at least, not nearly as physically robust or capable when it comes to ease of programming. To make it even less enticing as a replacement for existing 1100s, it does not support messaging to its Micrologix predecessors, i.e. reading and writing of "N" integer files using what I would call "CIP encapsulated PCCC/DF1 protocol". You have to use Modbus TCP, which only the 1400 supports.
If the SCADAPack Dev Team were able to implement Encapsulated PCCC/DF1 in a similar fashion to the MODBUS Scanner functionality in RemoteConnect for the x70 range, that would prove incredibly useful for staged migrations from old Rockwell gear to SCADAPack x70 RTUs.
The ability to act as a DF1 slave device would also be useful, i.e. map SCADAPack tags to a "N" or "B" type file addresses in Rockwell RS500 terminology, allowing a Micrologix, SLC500 or CompactLogix to read values from the SCADAPack without needing to use Modbus TCP (not available on the ML1100 over ethernet, and cumbersome to implement in a CompactLogix).
We are currently having to use the HMIs of migrated sites as a protocol converter and DF1 master, which isn't ideal... especially when some of these systems are getting migrated piecemeal over a number of years.
With a Water Services Reform here looming, I imagine there will be a lot of systems coming under renewed scrutiny around obsolescence, and having the SCADAPack x70 range able to easily integrate into these existing legacy systems would certainly make it much more appealing when it comes to selecting an RTU product.
c80f0f1006