Produced/Consumed tags Error 16#0100

Hi All:

I am having trouble reading some produced/consumed tags recently. These tags had been working without issue for a while, but recently I am unable to read them at all.

I have 9 separate tags being read on the connection and 6 out of the 9 are updating without issue. The other 3 do not respond at all. In the I/O configuration, the producing controller shows faulted and the status alternates as follows:

1. Connecting
2. Code 16#0203 - Connection Timed Out
3. Code 16#0100 - Connection Request Error - Module in Use

I have tried resetting the EN2T cards and re-downloading the programs with no luck.

These tags are only being consumed by 1 controller. Anyone have any ideas as to what could be going on?

Thanks!

Are they both control logix CPUs?

How many other CIP connections do the EN2T cards have?

Any errors shown on the EN2T webpage? Just type their IP address into your web browser whilst connected to it. Can get some useful diagnostics from it.

Hi Rob:

Thanks for the reply. Yes both, controllers have ControlLogix L74 processors.

As for the CIP Data:

The consuming EN2T has the following CIP connection info:

Maximum Total Observed 137
Maximum Total Supported 259

The producing EN2T has:

Maximum Total Observed 47
Maximum Total Supported 259

So it does not seem to be exceeding the allowed CIP connections. Also, I don't see any errors in either card.

I forgot to mention that in the IO config, the remote EN2T card does not show faulted, however the remote (producing) controller shows faulted in the IO with the messages I specified in the previous post.

Thanks again for the help.

They aren't part of a redundant system are they?

Just looking over those error codes and it looks like the amount of time taken for the data packets to be produced onto the network is the issue.

Is there a lot of heavy comms from the en2t? Drives, other CPUs?

I've had the same issue with an ENBT card, showed enough CIP connections but the CPU in the ENBT was running at 100%. Upgraded the card to an EN2T and this solved the issue.

In my situation I had 13 L32 CPU's in the ENBT's ethernet tree.

No, the system is not redundant.

Most of the traffic comes from several SCADA clients reading information from the processor, however this is spread over 3 seperate ethernet cards. Looking at the diagnostics, it doesnt seem like any of the cards are at max connections. I tried pointing to a different EN2T card on the producing controller and have the same exact issue.

Anyways, I ended up changing the tags to get the information via MSG instruction since I don't have much time to take the controller offline to troubleshoot the PC connection. With the MSG instruction, it is working fine.

Ill update later on if I identify whats going on. Thanks again/

http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm011_-en-p.pdf

Possibly worth a read from page 32 onward.

One thing I have observed is where a local I/O module was set to the minimum RPI, and the backplane comms became a bottleneck.

No amount of ENBT, EN2T, 10MB/s, 100MB/s, or even Fibre comms is going to help when everything has to go over that same backplane, which I believe runs at only 5MB/s, the same speed as ControlNet.

You might also like to consider the notion of consolidating your 9 Produced/Consumed tags into a lower number of UDT tags to reduce the number of tags that are exchanged. Construct your own UDTs, but keep your UDT size <= 500 bytes.

daba said:

You might also like to consider the notion of consolidating your 9 Produced/Consumed tags into a lower number of UDT tags to reduce the number of tags that are exchanged. Construct your own UDTs, but keep your UDT size <= 500 bytes.

Click to expand...

Is the recommended UDT size limit related to the Produced/Consumed aspect? Or UDTs in general?

What is the benefit/problems avoided by staying under 500 bytes?

Mispeld said:

Is the recommended UDT size limit related to the Produced/Consumed aspect? Or UDTs in general?

What is the benefit/problems avoided by staying under 500 bytes?

Click to expand...

A produced/consumed tag has a maximum size limit of 500 bytes, thats it... A UDT in general can be up to 2MB size limit, but you will not be able to produce consume them.

Packing your data into 500 byte UDTs whenever possible just makes most efficient use of network bandwidth, not just in terms of size of the data-block but in reducing the number of connections to maintain open.

daba said:

A produced/consumed tag has a maximum size limit of 500 bytes, thats it... A UDT in general can be up to 2MB size limit, but you will not be able to produce consume them...

Click to expand...

Thanks, good limit to know before finding out the hard way.

cycle power

s

Click to expand...