Allen Bradley Firmware v20 and prior

It came to my attention that the latest version of Ignition (7.6.1) now includes the following legend for Allen Bradley Logix controller drivers:
[ul][i]* Connect to CompactLogix firmware v20 and prior processors.

  • Connect to ControlLogix firmware v20 and prior processors.[/i][/ul]

Is there a protocol change in v21+ that is not supported by Ignition included drivers?

Thank you in advance.

Yes, that's exactly right.

We're working on a new Logix driver that will support v21+, but it's still early stages and I can't really even give you an estimate of when it will be finished.

[quote=“Kevin.Herron”][quote=“everardohr”]
Is there a protocol change in v21+ that is not supported by Ignition included drivers?
[/quote]

Yes, that’s exactly right.
[/quote]

Care to elaborate on the details of the protocol change? I do a great deal of low-level work with Ethernet/IP and I hadn’t noticed this.

(I did run into a protocol issue with recent A-B processors, but it affected all firmware versions on the newer processors.)

[quote=“pturmel”][quote=“Kevin.Herron”]
Care to elaborate on the details of the protocol change? I do a great deal of low-level work with Ethernet/IP and I hadn’t noticed this.

(I did run into a protocol issue with recent A-B processors, but it affected all firmware versions on the newer processors.)[/quote][/quote]

There’s been no changes to EIP or the encapsulation of CIP within EIP - that’s all the same.

But, to make a long story short, the old vendor-specific CIP service that let you read tag data directly from memory offsets no longer works, and there’s a new vendor-specific CIP service that allows you to read tag data based on “Symbol Instance IDs”.

Just want to bump this thread and receive an update on the progress for firmware rev. 21 support. Until such time as this issue is resolved, reverting the controller firmware to 20.xx will resolve the issue?

Progress is slow, but happening :slight_smile:

And yes, you can revert to 20.xx, or simply use Kepware or another OPC server.

I’m not a communication driver developer, but I’ve dealt with the fallout from some bad EtherNet/IP driver implementations.

The publicly documented and supported methods for reading and writing ControlLogix Tags don’t include RA’s internal methods for optimization and direct memory block access; that was an advantage that Rockwell held back for themselves, and they use it to make RSLinx Enterprise and features like RSTrend run fast and efficiently. Part of the reason was for competitive advantage, and part of it was so that they could modify and improve that mechanism without supporting a bunch of third parties who had built their interfaces on it.

Competitors promptly commenced to reverse-engineering the protocol and methods. Several competitors had a fatal flaw: they did not check for re-optimization or edit events and would sometimes do a physical memory write to a memory location that had previously been allocated to a Tag, but was now allocated to user ladder code memory. Whammo, red light, major controller fault. I’ve been in the middle of some of the finger-pointing matches. It was… ugly.

Inductive Automation chose to be more careful. You’ll see that when there’s an edit to the controller, the OPC-UA driver stops and re-loads the memory map.

And now that RA has changed that mechanism (remember, they planned to do so from the beginning), IA has to adapt to it. I am very encouraged that they are taking it seriously.

Can I take it from this discussion that the IA ControlLogix driver currently uses logical (memory based) addressing rather than symbolic (tag based) addressing? Will this be the case for the new (v21 and later) driver, or are you being forced to use symbolic addressing?

The new driver reads using the CIP services updated in firmware v21 to allow using the symbol’s instance ID.

When connected to a v20 or prior firmware it will use symbolic addressing, however I’m not sure if I’ll allow connecting to a v20 and prior Logix in the initial release since we’ll still have the current AB driver around.

What does using a symbol’s instance ID mean? Symbolic addressing seems a backward step as it can be more than 8 times slower than logical addressing.

Each tag (Symbol) in the controller is assigned an instance ID. Instead of building an EPath comprised of AnsiDataSegments (symbolic addressing), you build an EPath that contains two LogicalSegments - the Symbol class ID and the Symbol’s instance ID. This is only available in v21 firmware.

Symbolic addressing being a step backwards and up to 8 times slower than logical addressing is irrelevant because logical addressing is no longer allowed in v21. You’ll get CIP error as a reward for your efforts. (0x0F privilege violation, I think…)

Thanks for that information Kevin. Would you say that using the instance ID is more akin to symbolic addressing or logical addressing? Will it have an impact on performance?

The reason I questioned about your planned use of symbolic addressing is because you said the driver would fall back to that for V20 firmware, whereas the current driver would seem to use logical addressing. Why not use the instance ID for V21 and up and logical addressing for V20 and back?

[quote=“AlThePal”]Thanks for that information Kevin. Would you say that using the instance ID is more akin to symbolic addressing or logical addressing? Will it have an impact on performance?

The reason I questioned about your planned use of symbolic addressing is because you said the driver would fall back to that for V20 firmware, whereas the current driver would seem to use logical addressing. Why not use the instance ID for V21 and up and logical addressing for V20 and back?[/quote]

I don’t have any performance measurements yet, but using the instance ID is more similar to logical addressing.

I’m not really interested in implementing logical addressing in the fallback case because it’s undocumented and its use is not advised by AB. It’s also much more dangerous, especially when the program is being changed, if you ask me.

My focus for the new driver is correctness/safety first, even if the cost is performance. The old driver has a long history of bugs and other issues, some of it due to being reverse engineered. It will still be available if the performance hit when connected v20 controllers has too great an impact for your project.

The new Logix driver will be a separate module, with slightly different addressing/item paths than the old driver, so switching to it will be a very intentional (and optional, unless you upgrade your firmware to v21) move that you can then measure and make sure it works for your project.