PLC4J/X and ControlLogix 5000

AndyPLC · May 3, 2022

I'm attempting to read tags from a 1756L81E(FactoryTalk Logix Echo) controller using the PLC4J api. I have one read and one write bool setup in the controller tags set for external access of read/write and read only, respectively. Using the remote run, I can see/update the tags via Logix Designer. I can also connect to the PLC using the software I have, but when I go to read, I'm getting "Unsupported case for discriminated type" when I get the response.

PLC4J code below:

Code:

try (PlcConnection plcConnection = new PlcDriverManager().getConnection("eip://127.0.0.1")) {

	if (!plcConnection.getMetadata().canRead()) {
		logger.error("PLC connection doesn't support reading.");
		return;
	}

	logger.info("PLC connector connected");

	// Create a new read request:
	PlcReadRequest.Builder builder = plcConnection.readRequestBuilder();
	logger.info("Created Builder");

	builder.addItem("value-1", "%Output_Tag[0]:BOOL:1");

	PlcReadRequest readRequest = builder.build();

	// Register a callback executed as soon as a response arrives.
	logger.info("Make sync request for PLC data");
	PlcReadResponse readResponse = readRequest.execute().get(5000, TimeUnit.MILLISECONDS);
	if (readResponse != null) {
		printPlcResponse(readResponse);
	} else {
		logger.error("An error reading PLC, response is NULL");
	}

} catch (PlcConnectionException e) {
	e.printStackTrace();
}

Output in logs:

Code:

DEBUG o.a.plc4x.java.spi.Plc4xNettyWrapper - Forwarding request to plc CipRRData[sessionHandle=1073741845,status=0,senderContext={0,0,0,0,0,0,0,0},options=0,exchange=CipExchange[service=CipUnconnectedRequest[unconnectedService=CipReadRequest[RequestPathSize=7,tag={-111,10,79,117,116,112,117,116,95,84,97,103,40,0},elementNb=1],backPlane=0,slot=0]]]
DEBUG o.a.p.j.s.GeneratedDriverByteToMessageCodec - Sending bytes to PLC for message CipRRData[sessionHandle=1073741845,status=0,senderContext={0,0,0,0,0,0,0,0},options=0,exchange=CipExchange[service=CipUnconnectedRequest[unconnectedService=CipReadRequest[RequestPathSize=7,tag={-111,10,79,117,116,112,117,116,95,84,97,103,40,0},elementNb=1],backPlane=0,slot=0]]] as data 6f0030001500004000000000000000000000000000000000000000000000020000000000b2002000520220062401059d12004c07910a4f75747075745f5461672800010001000000
WARN  o.a.p.j.s.GeneratedDriverByteToMessageCodec - Error decoding package with content [6f0018001500004000000000000000000000000000000000000000000000020000000000b2000800d200010111030100]: Unsupported case for discriminated type
org.apache.plc4x.java.spi.generation.ParseException: Unsupported case for discriminated type

Any thoughts or Missing information from the post?

Engineerj22 · May 3, 2022

Is that "value-1" trying to send a 1 or a -1?

In the outputs, it looks like it's trying to read 14? tags?

AndyPLC · May 3, 2022

According to docs and examples I've seen, the first field is basically a key. The second is the information about what you are trying to read. The format for the second is:

Code:

^%(?<tag>[a-zA-Z_.0-9]+\\[?[0-9]*\\]?):?(?<dataType>[A-Z]*):?(?<elementNb>[0-9]*)

Perhaps I misread?

drbitboy · May 3, 2022

Engineerj22 said:
... it looks like it's trying to read 14? tags?

If you mean this:

Code:

,tag={-111,10,79,117,116,112,117,116,95,84,97,103,40,0}

That is not 14 tags, those are SINTs as ASCII codes*: 79=O; 117=u; 116=t; ...; 95=_; 84=T; 97=a; 103=g; 40=0 (the zero in [0]?); 0=string terminator, or perhaps the zero in [0]?

Maybe the [0] is not allowed? And the <elementNb> is where the array index should be, so Output_Tag[0] should be

Code:

builder.addItem("value-1", "%Output_Tag:BOOL:0");

? I am only guessing. Also, I would not use the hyphen in the key, so I would use "value_1" instead of "value-1" although it may not matter.

[update: whoops, I found a webpage page that suggests hyphens in the key for .addItem are legal; also [0] is the starting element]

8-bit ASCII -111 (145) is ETC (end transmission block) with thbit 7 set, and ASCII 10 is linefeed (newline), but I have no idea where they come from or what they mean.

* Not strict ASCII i.e. 8-bit not 7-bit, because the -111 at the beginning is presumably ASCII 145 (256-111)

AndyPLC · May 3, 2022

I got rid of the 0, but that first -111(if ETC, not good, I'd assume) and not sure where the 0xa(10) comes from either.

drbitboy · May 3, 2022

this page https://plc4x.apache.org/users/protocols/ethernet-ip.html makes it look like the number of elements comes before the data type, in the colon-separated tag specification:



%{tagname}[{startIndex}]:{numberOfElements}

%{tagname}[{startIndex}]:{numberOfElements}:{DataType}

AndyPLC · May 3, 2022

Gave that one a try, but the PLC4X pulls it out using the regex above.

AndyPLC · May 3, 2022

Ok, plc4x adds those two chars in to meet the CIP message spec. The 0x91 is the data item id(although I couldn't find that item id in the spec) and the 0x0A is the length of the data. So now I suppose I need to see what else the controller may be complaining about.

But much thanks for the help getting rid of the last two chars in the tag!

AlfredoQuintero · May 3, 2022

Could you get a Wireshark trace? You would need a switch with mirroring port function. The Wireshark dissector for EtherNet/IP is great and decodes and comments the CIP package down to the guts of the packet. it may be easier to analyze than the logs you have shown.

AndyPLC · May 3, 2022

Wow, yes it does! Since I'm running the 5000 emulator, I just had to sniff on the loopback. Gave me the error and one google away and I got it. Issue was with the options for the backplane and controller location in the connection string.

AlfredoQuintero · May 4, 2022

that`s good!

PLC4J/X and ControlLogix 5000

AndyPLC

Member

Engineerj22

Member

AndyPLC

Member

drbitboy

Lifetime Supporting Member

AndyPLC

Member

drbitboy

Lifetime Supporting Member

AndyPLC

Member

AndyPLC

Member

AlfredoQuintero

Lifetime Supporting Member

AndyPLC

Member

AlfredoQuintero

Lifetime Supporting Member

Similar Topics