Problem downloading in RSNetworx for Devicenet

Hi All!

I added a combination I/O module 1794 IE4 XOE2/B to the end of 1794 RIO devicenet node. In RSNetworx for Devicenet V11 (CPR9) for some reason the 1794 IE4 XOE2/B (combo analogue module) default was selected to have the flex configuration setting of 0 input words and 2 output words.



I changed the configuration to 4 input words and 2 output words. But the new settings would not download. An error message for each slot appeared; "Address 01: [Slot 00] Communication Error(0xC) 'Error response received: [0x040c, 0x00ff]. Object state conflict.', SCIA(0x10, 0x7D, 0x1, 0x8)" through to slot 07. 07 is the slot that has the Combo Module requiring the change.




I tried doing various things like; put the processor into program mode. Inhibit the device net scanner via RSLogix.
Any ideas?

Cheers!

The adapter will reject any configuration change if there has been an I/O connection established since the last reboot. Even when you disable or break the connection, the adapter still considers itself in an I/O relationship and won't accept a change.

I don't know if that's admirable loyalty or terrible stubbornness, but it's a common issue with the 1794-ADN. That can be a tricky module.

1. Inhibit the 1794-ADN in the Scanlist of the DeviceNet Scanner by un-checking the Active checkbox for its entry.
   
2. Power cycle the 1794-ADN completely.
   
3. Download the new 1794-ADN configuration.
   
4. Un-Inhibit the 1794-ADN in the DeviceNet Scanner scanlist.

Ken Roach said:

The adapter will reject any configuration change if there has been an I/O connection established since the last reboot. Even when you disable or break the connection, the adapter still considers itself in an I/O relationship and won't accept a change.

I don't know if that's admirable loyalty or terrible stubbornness, but it's a common issue with the 1794-ADN. That can be a tricky module.

1. Inhibit the 1794-ADN in the Scanlist of the DeviceNet Scanner by un-checking the Active checkbox for its entry.
   
2. Power cycle the 1794-ADN completely.
   
3. Download the new 1794-ADN configuration.
   
4. Un-Inhibit the 1794-ADN in the DeviceNet Scanner scanlist.

Click to expand...

Interesting. Yes it did seem like something like that. The give away was "Object state conflict" the state being that something is still being polled.

I will give that a try thanks!

Hi All!


I finally got to attempt a download changes to the 1794 IE4 XOE2/B (combo analogue module) sitting on the end of a 1794 devicenet node. I did the following before the download


1) Inhibit the devicenet scanner module using the check box within RSLogix 5000 program whilst online. turned off/on the PLC. Ensured the devicenet card displayed "idle" The download to the node failed, then


2) In RSNetworx for Devicenet uncheck the "node active" box in the scanner list, then re download the scanner list. turned off/on the PLC. The download to the node failed again.


I did not turn off/on the power to the actual node though.

I attached a jpg of the error messages;


Cheers

The power cycle is a necessary step for the 1794-ADN to accept an I/O connection request with a new size.

It is terribly stubborn in that way.

Ken Roach said:

The adapter will reject any configuration change if there has been an I/O connection established since the last reboot. Even when you disable or break the connection, the adapter still considers itself in an I/O relationship and won't accept a change.

I don't know if that's admirable loyalty or terrible stubbornness, but it's a common issue with the 1794-ADN. That can be a tricky module.

1. Inhibit the 1794-ADN in the Scanlist of the DeviceNet Scanner by un-checking the Active checkbox for its entry.
2. Power cycle the 1794-ADN completely.
3. Download the new 1794-ADN configuration.
4. Un-Inhibit the 1794-ADN in the DeviceNet Scanner scanlist.

Click to expand...

Ken, you are the best!!!
This helped me today, while the other time I spent on the phone with AB FOUR HOURS (even after reading this topic)!
What I would like to add, in case someone stumbles across this issue, is take screenshots of your mapping info before deleting the node from the scanlist - you will save a lot of headache