Legacy CompactLogix driver and v20.19

I currently have a trial Gateway setup on my laptop.

Ignition: v7.9
Laptop: Windows 7
Network: Cable connected directly to PLC, Bridged network connection through VM Virtual Network Adapter on 172.22.108.xxx subnet

CompactLogix v20.11, connects fine in Gateway, can open and drag tags from OPC browser to Tags folder, but all tags come in as Unknown Quality and “Null” value. I am thinking it is something simple but I don’t know if I’m doing something wrong.
It is because the gateway is in trial mode? The trial is not expired when I’m trying to get the tags to update. Thanks in advance for the help.

Are you using the Legacy C’Logix Driver?

I also use a VM but I set mine on NAT and not on Bridged. I don’t know if that will help, but I’ve connected to both CompactLogix processors and ControlLogix with that setup. I use the Allen-Bradley Logix Driver.

I’m using a legacy CompactLogix Driver. I can try NATing the NIC and see if that changes anything. Does the gateway running in Trial mode have anything to do with it?

Update: NAT does not change the tag status in the designer.

Solution: Wrote a value into the “Null” field of the tag, and the tag updated in the PLC.
Value then showed correctly on the screen. Some kind of bug I guess? I still have the Quality shown as “Unknown” though, so I will have to disable the masking. to see it correctly. The data quality goes “GOOD” for about 1 second as the tag is written to, then goes back to “UNKNOWN”.

Update: Seeing “write” events work correctly, reads all fail.

Are there any errors in the gateway logs?

Same read error in logs:
Read Request error. Status Code: ABResponseStatus{code=15}, First Item: Gloabl.PID_SP, Transaction: ####

With transaction number incrementing by 2 every time it tries. I’m only trying to connect to 1 tag at the moment so I can troubleshoot the issue. Sent in a service ticket as well.

Typically status 0x0F (15) means you’re either:

  • Reading a tag that does not have the correct External Access set
  • Using the legacy driver on a firmware version 21+ or >20.11
1 Like

Unfortunately, tag is read/write, and firmware is definitely 20.11 (CPX L32E doesn’t allow firmware above 20).
I’ll keep looking. I’m thinking it has to do with some kind of traffic between my base and VM going through the custom NIC I created.

It’s not, you’re getting a privilege violation status code from the PLC here.

It might be worth the effort to set up a second device connection in Ignition using the newer Logix driver and see if that works.

Thanks Kevin. Tried that right away, and the driver never connects. I’m going to set up a separate gateway on my base machine and just see if I can get the tags to read. As a matter of curiosity, where did you find those status codes? Is that a Rockwell code set that Ignition is reading from the PLC?

0x0F is a general status code defined by the CIP specification.

In your case it’s being returned by the PLC as a response to Ignition invoking the read tag service.

If the new driver works and the old one doesn’t you should double/triple check the firmware is really 20.11 and not some other 20.xx or 21+ version.

Thanks Kevin,
You solved the issue. I upgraded the CPLX to 20.19, the highest I could download, and used the Logix Driver, not the Legacy one. everything is working now. Thank you for your help. I assumed 20.19 was considered v20 and below, but I guess in this case Rockwell must have done something/upgraded the CIP communications? Thanks again.

They changed something midstream in the 20.xx series that turned off the direct memory access way of accessing tags, which is how the legacy drivers work.

As one other note, that would be a good note to add to the Legacy CompactLogix Driver, that v20.19 etc actually use the newer communication methods.

1 Like

Related to this, I’m not sure if it deserves its own thread, but we’re talking to a FW20.19 AB ControlLogix using the new driver which works, but comms is incredibly slow. It is taking 5s or more to write to tags. I’m not seeing any errors reported by the driver, but is there anything else I can check?

It’s slow because they disabled the direct memory access but, AFAIK, did not also add the new API from v21 for accessing tags via an instance id. So the way the driver works for these awkward later 20.xx versions is via the old and slow symbolic access where it literally has every tag name in ASCII in each request. It’s very slow, as you’ve seen.

If I can find some spare time in the next week or so I’ll flash one of our controllers to 20.19 to verify the v21 API is definitely not there.

1 Like

If you are able to, we were able to speed up the communications by using RSLinx Gateway as an OPC server and going that route instead of direct access through the Ignition OPC comms. There wasn’t a big difference when we only had a few tags, but once we got over 400 AOI’s each with over 100 items, the comm speed changed. The RSLinx Gateway sped up the communications considerably.

1 Like

Awesome, thanks for the fast response. We’ve downgraded to FW20.18 with the old driver now and it’s back to normal (fast) comms speed :slight_smile:

We don’t have a licence for RSLinx Gateway on this site so this isn’t an option for us here, but good to know for the future. Cheers