Controllogix Io Modules

[Olivie Inoue]

TheHI 1756-WS and 2WS condition and digitize the weight signals and then transmit the selectable Gross, Net, and/or Rate-of-Change data to the PLC processor. High data resolution allow the modules to tolerate large dead loads and over sizing of the load sensors while retaining a high level of usable resolution.

The modules supply 5 volts of DC excitation to drive up to four 350 ohm load sensors or load cells associated with a single scale (four additional for the 2WS scale). They will support additional load cells with an external power supply.

The HI 1756-WS and 2WS both support the use of the producer/consumer technology in the ControlLogix system to transmit data. This type of communications is an intelligent data exchange in the system where the module produces data without having to be polled.

Quickly and easily configure the HI 1756-WS or 2WS for your application through PLC software on a PC. An HMI face plate makes the modules incredibly easy to use with common weighing functions built in.

The Hardy Process Toolbox is a set of productivity tools that support industrial weighing functions. Each tool saves time, increases accuracy, improves efficiency, or reduces risk in process weighing applications, including WAVERSAVER to eliminate vibration, C2 electronic calibration, and Integrated Technician to name just a few.

Hardy's INTEGRATED TECHNICIAN (IT) core feature helps you troubleshoot your weighing system and diagnose problems from the front of the instrument or via the PLC. These tests display system weights, voltages, and pass/fail displays to help isolate a problem to the instrument, cabling, or sensors, helping to reduce maintenance costs.

AMCI developed the 7260 series modules for applications requiring a direct interface to most sensors that output SSI data.

The resolution of the ControlLogix SSI interface modules are only limited by the resolution of the position sensor used. Additional features include: position preset, count direction, position scaling, and latch inputs that are used to capture the scaled position data.

These modules also incorporate fault diagnostics that constantly monitor system integrity and report any errors to the PLC

AMCI products are uniquely designed to provide the best PLC integration available. Unlike other products that require a separate software package for configuration or operation, AMCI's PLC-based products are programmed using your PLC's software - nothing new to buy or learn!

Our expertise with the leading PLC manufacturers (e.g. Allen-Bradley Schneider, GE, etc) is unmatched when it comes to high performance Specialty I/O, Position Sensing, and Motion Control technology.

Has the issue with bridging to a ControlLogix processor been resolved since this thread was started? I too have a system with two backplanes connected via CNB modules. The path command should do the trick but I find no guidance in the manual.

I am trying to connect a ControlLogix5500 CPU through ControlNet with Ignition Gateway (to expose the data with OPC UA). This is a very similar setup to the one descibed in the previous post. However I am unable to succesfully connect to the CPU module.

The CVE-2023-3595 allows for arbitrary manipulation of firmware memory, which could lead to denial or loss of control, denial or loss of view, theft of operational information, or manipulation of control and manipulation of view for disruptive or destructive consequences, while the CVE-2023-3596 could lead to denial or loss of view or denial of control of the industrial process. These communications modules are part of the ControlLogix system and are present in multiple industrial verticals, including, but not limited to manufacturing, electric, oil and gas, and liquified natural gas.

Rockwell called upon organizations to further secure ControlLogix communications modules from exploitation by updating EN2* ControlLogix communications modules to firmware revision 11.004 and updating EN4* ControlLogix communications modules to firmware revision 5.002. It also recommended network segmentation and implementation of detection signatures.

Additionally, organizations should increase protections of ICS/SCADA networks by implementing regular backup devices to allow for reversion to a clean copy of firmware or a working project; disable unused CIP objects on communications modules, such as unused CIP Email and Socket Objects; block all traffic to CIP-enabled devices from outside the ICS/SCADA network using available security products; and monitor CIP traffic for unexpected content or unusual packets lengths.

Furthermore, system owners should ensure ICS/SCADA networks are baselined and regularly monitored for deviations in network activity. Specifically, system owners can look for potential IOCs (Indicators of Compromise) for ControlLogix communications modules. These include unknown scanning on a network for CIP-enabled devices; unexpected or out-of-specification CIP packets to CIP objects implemented in ControlLogix communications modules, including the Email Object and non-public vendor-specified objects; arbitrary writes to communication module memory or firmware; unexpected firmware updates; unexpected disabling of secure boot options; and uncommon firmware file names.

Additionally, in both cases, there exists the potential to corrupt the information used for incident response and recovery. The attacker could potentially overwrite any part of the system to hide and stay persistent, or the interfaces used to collect incident response or forensics information could be intercepted by malware to avoid detection. The exploitation of this type of vulnerability renders the communication module untrustworthy, and it would need to be de-commissioned and sent back to the vendor for analysis.

To identify affected systems, industrial cybersecurity vendor Tenable has released plugins for Tenable OT Security (formerly Tenable[dot]ot), Tenable Vulnerability Management (formerly Tenable[dot]io), Tenable Security Center (formerly Tenable[dot]sc), and Tenable Nessus.

Rockwell Automation has provided patches for all affected products, including hardware series that were out of support, the company said in its advisory. Detection rules have also been provided. Customers using the affected products are encouraged to evaluate and implement the mitigations provided. Additional details relating to the discovered vulnerabilities, including products in scope, impact, and recommended countermeasures.

Warmboot is a software reset of the module that also causes the unit to reload its configuration.Coldboot is a hardware reset of the module which has the same effect of powercycling the module.In-Chassis modules which are configured via ladder logic must be reset before the confi...

ProSoft Technology does not sell nor directly support any 1756-MVI modules that have COMPLI protocol installed. This protocol is still available from Allen-Bradley through their affiliate, GMS, in Sweden. For further information and technical support on 1756-MVI modules with the ...

When a ProSoft AOI is initially installed, the User-Defined Data Types (UDT's), controller tags, and AOI logic is imported into the existing program. You will need to remove these in a certain order:1. Delete the ProSoft card from the I/O configuration in Slot X.2.&nb...

I'm looking at automating an existing plant which currently has zero controls, so starting from scratch. The process isn't complicated but the equipment is a bit spread out over a two story facility. We're thinking about using a CompactLogix 1769-L32, physically located as central as possible, with ten four-slot 1734 Point I/O blocks. My concern is that many Allen Bradley controllers limit the number of I/O modules you can add to the project. Like some 1756 controllers are limited to 30 local and remote I/O modules, CompactLogix controllers may be limited to 16 local and who knows how many remotes, etc. I can't find anything that spells it out explicitly in the Design Considerations Manual. The CompactLogix 5370 User Manual only says it supports, "a limited number of Point I/O modules that can be used as local modules". Nothing about networked modules. The CompactLogix Selection Guide clearly defines the number of network nodes, but nothing about the number of modules.

Does anyone have any direct experience with this much Point I/O in a CompactLogix environment? I'm thinking that we're in an age of counting nodes, rather than modules but don't want to order the hardware without being 100% sure.

@ElectronGuru you're not going to be concerned with module count, what you want to look for and it is in the manuals is the connections count. Each module and/or each rack depending on Rack Optimization. I know we hooked a controllogix L6x to 128 Gppro HMI back in the day and it took 7 ethernet modules because of connection counts per ethernet module. You'll find your CPU has a connection limit and ethernet port has a connection limit as well and they aren't the same. You'll also learn or take my word that once you're over 25% of limit things get sluggish at at 50% they get flaky.

The link to the point IO racks was made with an MDS i-Net 900 MHz radios (one master and 5 slaves). Distance was a couple of miles. It worked great until the trees leafed out and the signal dropped out. I had to go back and raise the antennas

Side-note: When going down this rabbit hole I found that the 1756-L8 controllers controllers have completely abandoned connection counts in lieu of Node limits. I'm wondering now if performance on the L8s deteriorates as quickly with added nodes as it does with connections.

Electron the easiest way is to build a project and add the AENTs. It will then tell you what the max module limit is. Again, as mentioned by others, you'll want to use rack optimization to reduce the connections.

It's very empirical and not particularly scientific, but we once built a system using an -L33ERM that did motion control of a single-axis Kinetix 6500 along with two PowerFlex 525 drives, an SMC valve bank, a Red Lion HMI, and a data exchange link with a ControlLogix -L71, all over the same Ethernet port. There were zero issues with communications lag or anything. The servo was a linear motor that was constantly cycling (synchronized with pneumatic cylinders controlled by the valve bank) and would move back and forth with one direction a fast move and the other direction having a slow section in the middle. Performance was flawless.

3a8082e126