Issues Configuring Modules

Ran into a new problem today that I thought I would share. It seems some updates to Windows, Java, and/or possibly AB software are preventing us the ability to disable BOOTP/DHCP in our 1792ES Safety Modules. The only solution I have been able to find is to break out an old laptop with old software and use it instead of my normal one.

I am running Win7 Enterprise, SP1, 64-bit. Java is 8. RSLinx Classic is 4.00.01. BootP DHCP Tool is 3.02.00. This same problem has shown to exist on our new Win10 laptops with fully updated software, too.

Using BootP, I am able to successfully set the IP address in the module and I can see it with RSLinx, but none of the three methods for telling it to disable DHCP are successful. I get a message back telling me the command is rejected. Similarly, when attempting to change the module properties in RSLinx, I get a similar error message. Finally, when attempting to use the built-in web page, I get a rejection notice from Java that each and every page is blocked because Java "can not verify self-signed Deployment Rule Set jar".

I've tried all of the Java security bypasses and the suggestions from ABs knowledgebase, but as I said, the only way I've been able to get past this is to use an old laptop with old software.

Just wanted to share this.

Ok. I have isolated the problem a bit. It seems to be in the BOOTP-DHCP Server V3.02.00.

When making the old laptop work in the office, I did a factory reset on the 1792ES module on my desk and then went through the procedure to enable DHCP to allow configuration using BootP-DHCP Server V2.3.2.0. Everything worked and I was able to use it to disable BootP and DHCP. I was then able to go online with both RSLinx and IExplorer and Enable/Disable DHCP at will.

I then took the same laptop out to the module on the machine and WITHOUT doing a factory reset (since it was still in DHCP mode after a failed attempt with the V3.02.00 software) and attempted to disable DHCP. No luck, not with either RSLinx or IExplorer. This made me to wonder if something in the failed BootP configuration process had locked out the module.

So I did a factory reset on the machine's module and was then able to do a successful configuration. I was then able to and Enable/Disable DHCP with all three methods, again at will. Suspicion apparently confirmed.

So I went back to my normal laptop, unistalled BootP V3.02.00, and downloaded and installed a copy of BOOTP-DHCP Server V2.3.2. After a factory reset on my office module, I was able to successfully configure and then, as with the machine's module, I was able to Enable/Disable DHCP with both BootP and RSLinx (but not with IExplorer because Java still won't let me get to the embedded web page).

So, as best I can determine, the problem appears to be in the new version BOOTP-DHCP Server V3.02.00

Is it possible that you had a safety controller who took the module ownership as soon as IP address was assigned? Then this will explain that all worked after module reset.
We just used 1732ES with latest BOOTP server and saw the similar issue when controller was on. Once we turned PLC off and used 888 reset, all worked.

Contr_Conn said:

Is it possible that you had a safety controller who took the module ownership as soon as IP address was assigned? Then this will explain that all worked after module reset.
We just used 1732ES with latest BOOTP server and saw the similar issue when controller was on. Once we turned PLC off and used 888 reset, all worked.

Click to expand...

No, I’m certain this is not the case for at least three of the four modules I tried this with. All three of those were on my training bench and all stayed physically disconnected from a network and processor throughout the process. I didn’t do the initial connection on the machine’s module, so I can’t say for sure on that one. Two of three bench units have been configured and reconfigured multiple times during training classes so I am pretty comfortable with the procedure for the 1792ES modules.

Just for my curiosity I will grab another module for a test.
Since “set static” is just a simple CIP message, it will need easy to compare the message between versions.
I know we had the error originally, I still have text messages from another engineer, but all was resolved next morning with turning controller off.
I will keep you posted.

Thank you for pointing to this.

I can confirm that BOOTP server 3.02.00 does not make IP static on 1732ES module. It assigns IP address using DHCP but making Static does not do anything
In fact Wireshark does not even show the CIP packet coming out.

I did not try the old version, but I did try this http://plctools.com/ethernet-ip-address-explorer-dhcp-and-bootp-server/ and it worked without any issues.

I also tried 3.02 with 1734-ANETR/B and see same results.

Once set using any of the BOOTP utilities, I usually use RSLinx to change a modules configuration from dynamic to static. Also, I disable my WI-FI connection, that has cleared up difficulties when they occur also.

jstolaruk said:

Once set using any of the BOOTP utilities, I usually use RSLinx to change a modules configuration from dynamic to static. Also, I disable my WI-FI connection, that has cleared up difficulties when they occur also.

Click to expand...

Unfortunately, that doesn't work either. I tried using both RSLinx and IExplorer and the module's built-in webpage and neither of them could accomplish the job. It seems the new BOOTP utility causes the device to reject that setting change which, in turn, requires another factory reset before even the old verson will work again.

Steve Etter said:

Unfortunately, that doesn't work either. I tried using both RSLinx and IExplorer ...

Click to expand...

This worked for me in RSLinx 4.00
I tested that, this is how we actually did it last week.

I'm using RSLinx 4.00.01, too, and I couldn't get it to make the DHCP to Static change on two different modules after their IPs were set via BOOTP 3.02.00.

Looks like TN 948444 has workaround solution:
Use Tools Menu instead.

Contr_Conn said:

Looks like TN 948444 has workaround solution:
Use Tools Menu instead.

Click to expand...

Yeah, I found and tried that, too. It didn’t work for me. The response was an instantaneous error.

No Errors with 1732ES for me