Allen-Bradley Logix Device Driver and String Tags

I’ve googled and searched the forums for some way to directly populate OPC tags with string (ASCII) data from a Rockwell CompactLogix controller, and have come up empty.
We are connecting to the PLC using the Ignition OPC UA Allen-Bradley Logix Device driver.
PLC version is v32.
The PLC is controlling Cognex cameras doing OCR to read data off of parts.
Currently I am having to read the ASCII registers (DATA[X]) as part of a tag value change in a UDT.
If it’s possible to read the string directly as an OPC item tag, I think this would shave a small amount of time from the scanning process, and could eliminate code on the Ignition side.

Anyone have any idea if this is doable?

Edit to add:
BTW, I have tried the “[PLC]StringTag.DATA**,SC10**” (trying to read a 10 character string), but I get a configuration error.

Have you tried just [PLC]StringTag ?

Yes. Not sure what else I’d use. The controls engineer built the PLC UDTs and that is the location of the string data. I’m sure it’s coming from the camera as input registers somewhere, but I don’t have his program or have any insights as to how or where those are being populated.

I could ask him to provide more info on where the data actually enters the process and even get him to do a few tests if need be.
Do you any suggestions on next steps with regards to that?

Well, did the programmer create his own string data type? If so, it must be just like a logix native one, but with a different length. That is, a .DATA array of SINT content, and a .LEN DINT of actual used bytes.

FWIW, my Ethernet/IP module has some string handling options that would suit cases that don’t have a .LEN element, but it isn’t a client driver. /:

May have to address that.

He says he used the “string tool” to setup the tags. It’s been so long since I worked with PLCs I can’t speak to what that might be. The DATA elements are SINT and the LEN is a DINT.

We had this issue the other month where our string tags were being seen as types with a DATA and LEN object. They should be seen as a simple tag without these objects in them in order to be able to read them into ignition as a string. I.e. If the address in your plc [PLC]StringTag, then that’s the address you need to be reading as Phil said.
From memory, I think we solved it by adding the string tag into its own udt. It was a weird one… After that, we no longer saw the DATA and LEN objects, we just saw StringTag with no children

So one of these tags is:
I’ve tried it as it is above, using the “,SC10” appended (that I had see elsewhere in the forums), and a number of other configurations. Using it as shown above does not result in a config error, but also does not result in any data being populated in the tag.

The attached image shows a “test” string tag. This tag is pointed to the string tag shown above. There is ASCII data in the DATA tags for the QC09 camera, but the resulting OPC String tag (aastringTest) has no data. So this does not seem to be working in this particular application.

Something that I’d think should be simple seems to be a tough nut to crack!

When you browse to that tag in the OPC Browser what do you see? Does it have a LEN and DATA member underneath it? What is the OPC Item Path of those dataN tags?

Is .LEN non-zero?

When I saw the DATA and LEN members it was bad news. When I was able to read the string, those members weren’t there. Any idea why they appear sometimes and not others?

Not sure about the legacy driver, but with the v21 driver the LEN and DATA members are always browsable underneath the String tag itself.


Yes, the DATA and LEN elements are there.
Unfortunately it looks like the LEN value is 0 even when there is ASCII data in the DATA elements.
I’ll have to talk to the Controls Engineer and see if he can get that element populated.

Being the curious type I created a string tag in a Rockwell PLC and was able to directly read it. I also created a tag to read the data string and was able to read the ASCII value of the tag. I can read both from a ControlLogix controller. Of course when reading the string tag I read it as a string and when reading the ASCII value I read it as an integer. Not sure what I am missing in the above conversation.Processing: StringSample.docx…

You aren’t missing anything. The root cause of Mike’s trouble was a zero in .LEN.

1 Like

Phil hit the nail on the head. The controls engineer was moving the ASCII data into the DATA elements but was not writing the length value to the LEN element. Once he started populating that the string came through as expected.

Thanks all for your input and dedication to help others! :+1: