I/O Not Responding - #0106, #0315

Join Date
Aug 2007
Location
Saint Augustine, FL
Posts
178
I'm having a ControlLogix/Panelview project with I/O issues.

Issue 1: 16#0106: Module owned and configured by another controller.

This is on the OB16's of a remote rack. That rack has a CPU, but isn't in my I/O tree (yet?), and I believe the error is that the primary rack is trying to, for some reason, set outputs but not allowed, because only that remote can set outputs? I'm not actually trying to set outputs, but i do need to clear the error.

Issue 2: 16#0315: Invalid segment type

EDIT: Nevermind issue 2. I just deleted the connection to this thing, as I evidently didn't need it for what I'm doing.

Do you guys have any hints?
 
Last edited:
Every controller has it's own I/O Config.

The I/O configuration you are seeing is the list of I/O your controller is communicating with.

If you connect to the other controller, you will see the I/O Config and what I/O that controller is communicating with.

The problem is that the other controller already has those I/O modules configured and owned. Two controllers cannot own the same output module.

OG
 
So that error might not be related to your other issues, but this is definitely not a phantom error and could in fact cause problems in your system.

For example....

If you were pull the remote controller from the chassis while leaving the chassis powered up then the controller you are working on would take over ownership of those I/O modules. They would operate based on the program in your controller which likely is not how they were operating before. Then, if the remote cpu is reinserted it would see the problem of those modules being owned and configured by your controller. This can definitely be an issue.

Figure out which PLC actually needs to control those outputs and then remove the modules from the I/O Config in the other controller. You can always add them back in as a "Listen Only" connection so you can see what they are doing but not control them.

As for your other issue with Produce and Consume.....can you fill us in on how the controllers and tags are configured?

OG
 
Sure.

It's a real simple Produce/Consume mechanism, and right out of an example.

On PLC-A, I have a tag called "MASTER_PRODUCE" that's DINT[32], of type "Produce", with a Consumer count of 2, state-change data sending and NOT unicast connections.

On PLC-B, I have a tag called "CONSUMER" that's a DINT[32], of type "Consumed", whos' Producer is "MASTER_CPU" and who's Remote Data is "MASTER_PRODUCE", with an RPI of 20ms. "MASTER_CPU" in the I/O Config tree is the 1756-L61 I previously referred to as PLC-A in this post.

On PLC-A, I set MASTER_PRODUCE[0] to the .ACC of some test timer, just to fill it with some data. On PLC-B, CONSUMER[0] remains at 0, which I believe is wrong.

I have no status, because it won't let me pick anything but DINTs as the data type, even though i've made a UDT with the documented format, though it now occurs to me that i never actually made an instance of it in controller tags...
 
mainstreetmark - your Produce/Consume configuration looks correct to me, so perhaps PLC_A (the Producer) isn't correctly specified in the IO Configuration of PLC_B ??

Also -

What connection are you using, ControlNet or EtherNet ?
Is the I/O light on the Consumer controller flashing ?
 
Last edited:
Thank you for providing such great detail. Very refreshing!

On the Consumer PLC, are you getting a flashing green I/O light with I/O Not Responding" message in the toolbar in RSLogix?

What modules in the consumer PLC are showing the yellow attention symbol? Upon opening the properties of that/those module(s), what error message is displayed on the Connection tab?

OG
 
PLC-B is flashing I/O, with the OB16's of a remote rack being the ones with the warning triangle. The error is the #0106, being the reason for this thread.

PLC-B is reporting I/O OK. In the middle of the night, I had a notion that I might not be JSR-ing to the routine, but alas, I am, so that's not it.

If I manually set a value in CONSUMER[0], it instantly reverts back to zero, as if it never accepted the value (rather than momentarily retaining the value). Is there such a concept as read-only?
 
Progress!

Deleted the tags on either end, and recreated them. The thing filed an "unscheduled" error, so I re-Networx'd it, and now I have "Invalid connection size - Tag: CONSUMER", even though they are both now DINT[15]'s.

At least it's telling me it's not working now...

---
Edit:

Nope... back to no fault, yet no data. The CONSUMER tag's base tag is "MASTER_CPU:MASTER_PRODUCE", and MASTER_CPU's status is "Running" with no fault. Any data I manually write into CONSUMER is immediately overwritten with zero. On PLC-A, MASTER_PRODUCE has non-zero data, and is in RUN mode.
 
Last edited:
For Produced/Consumed data transfer, there is no need for either Controller to be in Run mode, the data should transfer regardless of the operating mode of the controllers.

Both Produced and Consumed tags, and the I/O configuration, must be present and correct before scheduling the network.

I would firstly get rid of all the erros on PLC-B's I/O config. I think what might be happening is that RSNetworx is not scheduling the produced/consumed data because of the connection errors.

From what you have said - you type a value in the consumed tag and it reverts to zero - indicating that it is consuming the value 0 from the producer.

Try taking PLC-A into program mode and manually enter a value into one of the produced tag array elements. It should be produced, and consumed by the consumer.

How many other "connections" do you have - I don't know the size of the project, but is it possible you have used up all of the 250 available.?

Can you Zip and post BOTH files, Consumer and Producer, and I can test this for you on my controllers
 
Let's take a little bit of a step back.

Since you mentioned RSNetworx, that means it's a ControlNet network between the two controllers.

Let's talk about the 1756-OB16 modules. It sounds as though PLC-A (the one in the chassis with those modules) has normal Module connections to those modules. It owns those modules, so it can set their configuration (fault state, etc) and turn on the output points. Everything's great there.

Turning our attention to the I/O tree setup in the RSLogix 5000 project for PLC-B, there are two common mistakes that we need to avoid.

First, the configuration in PLC-B's I/O tree of the 1756-CNB over in the PLC-A chassis. The default connection type is "Rack Optimization", which allows the discrete I/O modules in that chassis to be controlled by PLC-B efficiently in just one packet.

What you want is a connection type of "None". This means that PLC-B will not attempt to take ownership of the I/O modules in that remote chassis, and you won't get the 16#0106 errors anymore.

Second, the configuration for the PLC-A controller in the I/O tree of PLC-B. The only important part is the Slot number; remember to count starting from zero on the left. You can specify the controller type (1756-L1, -L55, -L6x) and the Revision but those are purely for display and don't affect the connection.

Third, the CIP Connection status for the Producer controller. Create an INT tag called "PLCA_EntryStatusRaw" and a DINT tag called "PLCA_Entry_Status". Create and periodically execute a GSV instruction to read the Module object, the EntryStatus attribute, and store it in PLCA_EntryStatusRaw. Divide that by 4096 and store it in PLCA_EntryStatus.

Now PLCA_EntryStatus will reflect the state of the I/O connection between PLC-B and PLC-A. This connection carries all the Produced/Consumed Tags, and the EntryStatus value will be =4 when it's running correctly. An EntryStatus value of 1,3,5,7 is part of the make/break/fault cycle, and 6 means Inhibited. You can always test it by setting the connection to Inhibited.

Fourth, delete all the Producer tags and create just one to test. It sounds like you might have gotten confused on the name of the Source tag and are transferring data you didn't intend to transfer.

Related to that; are you planning to Produce this data for more than one Consumer ? If so, check carefully the RPI rates for the Consumers. They have to be the same.

Any additional information you can provide can be useful too.
 
Ken wrote
What you want is a connection type of "None". This means that PLC-B will not attempt to take ownership of the I/O modules in that remote chassis, and you won't get the 16#0106 errors anymore.

Im afraid Ken is wrong here, even if you put "None" as your Comm Type, Controller PLC-B will still try to make a connection to the OB16'sin PLC-A's chassis, and the error will persist.

IMHO the OB16's in PLC-A's chassis SHOULD NOT be in the configuration for PLC-B's project AT ALL, unless they are set-up as "Listen Only". You CANNOT "share" output modules between multiple controllers, full stop.

If you are reading any of the Input Modules, you CAN share these between multiple controllers, providing the configuration data is identical in both projects.

And if you ARE reading any of the Input Modules, then you MAY use Rack Optimisation to limit the number of connections you use.

Why are the PLC-A OB16's in the I/O Configuration Tree in PLC-B ?

You only need to put modules that you actually need to use, not all the modules that exist. Having the modules in the tree makes PLC-B attempt to make a "connection" to the module, which it cannot do, since it is already "Owned and Configured by another Controller"

Lastly - If you are only going to have 1 consumer, you should set the number of consumers to 1, not 2.
 
Dave's and I are both right, in our own ways: I was thinking "stop before you put the remote OB16's in the I/O tree of PLC-B" and he was thinking "the 1756-OB16's are already there, and probably set for Module connections".

So, to emphasize Dave's post: Do not put any of the modules or racks located in the PLC-A chassis into the I/O tree of PLC-B except for the PLC-A controller.

The only exception to that rule is if you do want to perform Listen-Only connections. Listen-Only can be even trickier than Produced/Consumed. It's very useful when it's used, but it is uncommon.

I'm going out sailing now. Enjoy the weekend, if you've got one !
 
As I get rolling this morning, I notice the major revision number of the PLCs do not match. We had to roll PLC-A back to v16.7 (due to redundancy requirements?), and PLC-B is at 17.2. I had forgotten we did this.

Would this definitely cause a problem?

---
edit: I'm not able to downgrade my project. When I start a new project (for PLC-B), I can't re-create the I/O tree, due to not being able to choose 1756-L61 for "PLC-A".
 
Last edited:
The revisions of the controllers don't matter. ControlLogix doesn't do any revision checking when establishing Produced/Consumed Tags, even though the connection establishment allows you to specify the controller type and the revision.

If you are able to post the programs (or even stripped-down versions with only the I/O trees) this could be diagnosed quickly, I think.
 

Similar Topics

hello, I have a Maple Systems HMI5103L currently programed and running in conjunction with a AB 2080-LC50-24QWB. everything works fine data is...
Replies
2
Views
708
Have tried to get the tag details from the PLC through python pycomm module.But getting Tag doesn't exist error. Am using pycomm version = 0.11.0...
Replies
1
Views
491
Hi everyone. I worked with RedLion HMI several years, in the last year four CR3000 HMI (10 and 15") had have problems with the touchscreen. All...
Replies
5
Views
1,198
some of the existing ethernet IO modules having problems after adding couple camera(Keyence IV3).Tried swapping the switch with a bigger one...
Replies
5
Views
1,624
Hi every one am working on this machine ,where there is a motor that rotates an arm with high speed when the arm reaches the sensor the motor...
Replies
8
Views
1,982
Back
Top Bottom