IP problem with Rockwell??

I am using RSLogix 5000 ver 17.01 (also tried 18.02). Our customer requested that we use 223.223.224.xxx for IP address range for the devices.

I tried to use this range for an L32E, 1734-AENT, and 22-comm-e's. All of them give the same error/warning (Ethernet address specified is invalid) when I try to add the devices in the I/O tree in Logix. I then try 222.223.224.xxx and the devices take the address.

Looking up documentation, general info about IP octets state that 223 is a valid class C address. The knowledge base says that only 127 and GREATER than 223 (class d) is invalid for addresses.

Has anyone else ran into this problem? Or is 223 in the first octet not really a valid address?

I just set the IP on a ML1100 223.223.224.215, 255.255.255.0, 0.0.0.0 and it took all this and downloaded fine. I know this isn't the same equipment you have but maybe this will help.

I just loaded the IP address 223.223.224.2 (subnet 255.255.255.0, default gateway 223.223.224.1) into a 1756-ENBT with version 5.1 firmware and it accepted the address.

Try setting the I/O connections for Unicast mode (v18 and higher allow this for some devices) and that might tell us if it's part of the multicast address calculation that's making RSLogix 5000 object.

Verify also that you have the correct subnet mask in the configuration for the root CompactLogix ethernet module.

I'm always a little skittish when managers want to use specific human-readable addresses or unusual address ranges "just because". Use a host file or DNS if you want human-readable host names !

Well, I rebooted my laptop and turned off the wireless network card. I then opened up ver 17.01 and created a new file for an L32 E processsor. I tried to use 223.223.224.2. Unable to use the IP address. I get the error attached (error code on the bottom). So my laptop works as it has all day.

However, then I have my co-worker do the same thing. His laptop works fine. Same version of logix 5000.

I then went to ver 18 and used an L61 and an ENBT card Rev 5.1 and tried the 223 address above. No luck.

So this is a computer specific issue?? That being said. I am the 'rockwell guy' at work here so I know everyone else is running the same software that I am since I download it and distribute it to the other employees usually.

I am out of ideas.

On top of that.... I emailed my original post to our local AB distributer tech guy and he verified the issue on his system, but he also agrees that 223 should be valid.

It was a problem with AOP for Ethernet modules installed with v18 that propagated back to older versions, including v17
As far as I remember it was corrected recently with 19.01 - it will fix v17 and 18 as well.

see v19.01 release notes

I duplicated this with my copy of RSLogix 5000 v18, on a new project with just a 1756-ENBT created in the I/O tree and when trying to enter the IP for a CompactLogix Ethernet daughtercard.

I wouldn't be too surprised if the limit check is incorrect in RSLogix 5000, since it's likely that all the testing was done with far more common IP address ranges.

But that doesn't explain why your co-worker can do it on his machine.

So this is going to have to go to the RSI developers, to explain how the validity check works.

My test OS was VMWare 6.5 running XPSP2.

I guess Ken was busy typing and did not read my message above

I sure was ! Thanks for the post; I didn't know about that.

I'm installing version 19 onto my VM to verify that it changes my machine's behavior.

Thanks for all the help. Issue is resolved.

I read the release notes for ver 19.01 (as stated above). It clearly stated it fixed an issue with using 223.xxx.xxx.xxx addresses for an EN2T and EWEB modules (obviously there are many more that are affected).

I downloaded and installed ver 19.01. My software behaves as expected now. I can use 223.xxx in version 19 and in ver 17 (for our customer).

The reason my co-worker didn't have this problem is everyone else here is only up to ver 17.01. I am the only one who installed version 18, which apparently broke something which is now fixed in version 19.

Again, thanks for the help.