CompactLogix flashing red ok, with a couple twists

interesting thread, I also have the same question

It shows the proper MAC address as sending a request, but when I try to assign an IP

Click to expand...

it's been a while since I've used BootP – but I'm 99.99% sure that you have to enter the MAC address – AND – the desired IP address when you first start up BootP ... specifically, you need BOTH addresses typed into BootP BEFORE you fire up the processor ...

and you didn't answer my question: WHERE are you getting the MAC address from? ... from a paper label on a chip on the processor? ...

The other thing w/ BOOTP, I've never had much luck disabling it via the utility. I just set an IP and then use RsLinx once I can connect to force it over to a static address instead.

MAC address is listed on the PLC on a sticker, and for BootP/DHCP for when is used to work the SOP was:
PLC is running
Isolate computer and PLC from network.
Start up BootP/DHCP and watch for the MAC address to show up in the Request History
double click and fill in the desired IP, hit OK
wait for the MAC address to show up in the Request history with the newly assigned IP listed next to it
disable BootP/DHCP
Done!

Get through to filling in the IP and hitting OK, then it fails. No presetting the MAC or IP until you see it in the Request history.

Bobogrammer said:

MAC address is listed on the PLC on a sticker, and for BootP/DHCP for when is used to work the SOP was:
PLC is running
Isolate computer and PLC from network.
Start up BootP/DHCP and watch for the MAC address to show up in the Request History
double click and fill in the desired IP, hit OK
wait for the MAC address to show up in the Request history with the newly assigned IP listed next to it
disable BootP/DHCP
Done!

Get through to filling in the IP and hitting OK, then it fails. No presetting the MAC or IP until you see it in the Request history.

Click to expand...

Same with me, with the same results (socket error)

Dravik said:

The other thing w/ BOOTP, I've never had much luck disabling it via the utility. I just set an IP and then use RsLinx once I can connect to force it over to a static address instead.

Click to expand...

This is a great idea... I'm going to try this next time. I thought that the PLC wouldn't appear in linx until after BootP was disabled, but I don't recall ever actually checking to see.

Thanks Dravik!

That's a good idea Dravik, but I don't think it's going to be a working fix for me. I think the socket error is preventing communication from the PC to the PLC. If I remember right from a Google hunt the 10065 socket error is a windows error about no path to target. But on the good chance I'm incorrect in my thinking hows does one force a PLC over to a static IP?

LoganB I'm pretty sure if you can set it's IP it'll show up in Linx. Disabling BootP locks in the IP address so in the event of a power cycle the PLC will not send requests for a new IP. If the BootP isn't disabled and the IP hasn't been forced static it will lose it if power is lost.

Yup, that's my understanding as well. I just never thought to look in linx to see if the IP address had been accepted by the PLC. Whenever I assign the IP address in BootP, it always shows up on the relationship list correctly, and continues to show as it propagates future BootP requests, so there's a chance the IP address was sent correctly. I always get the socket error when I attempt to send a "disable BootP" command after assigning the IP address. If you see the device in linx after you assign the IP address, you can right click on the device and configure it to disable DHCP/BootP and assign it a static address, same as if you are able to see it via the USB driver.

Do you have another PC? ANY PC.... load RSLinx on another PC get the IP address loaded to the PLC than go back to your first PC after the static IP address is set

LoganB said:

...I thought that the PLC wouldn't appear in linx until after BootP was disabled...

Click to expand...

Hi LoganB,

All BOOTP is doing in the client device, when it does not yet have an IP address, is sending UDP packet requests looking for a BOOTP Server to assign an IP address to the device. BOOTP Server software, if working properly, will automatically detect the device MAC address. Once an IP address has been assigned, and BOOTP is still enabled, it is doing nothing, again, because an IP address has now been assigned. It does not continue sending requests. You should only see the IP address assigned against the device MAC address in BOOTP Server software. Only when the device is power cycled will BOOTP, being still enabled, then clear the IP address from internal memory and start sending UDP request packets again.

In other words, leaving it enabled will have no effect on the device's ability to start using its newly assigned IP address. After the IP address is assigned, you can immediately go to RSLinx Classic and start an Ethernet driver and browse to the device, if it is connected correctly.

EDIT: Bobogrammer has also alluded to this fact since I started typing.

I'm heading home now for the evening so I don't have time to get into the bones of this thread, unfortunately, but do a search here for my name & BOOTP or I think member ASF & myself & BOOTP? I recall one thread where we both outlined many causes of BOOTP Server not playing nicely.

I have other things you can check to do with the USBCIP driver issue but I'll post again later on that, if I have time.

Regards,
George

Using Rslinx to assign the IP, would this be done when linx is running as an application or a service? I don't think I've seen the IP either way but it'd be good to know which one I'm supposed to look at.

Last run in with BootP it wouldn't even reflect that I had assigned an IP to the MAC address. I wonder if SQL servers are involved with BootP at all, had some issues with SQLs awhile ago.

Just use your USB with another PC... see the video below it may help, its just with a USB adapter but same concept

http://youtu.be/FkO2BBuuwJw

Very informative video Genius, one question though. Is there a particular reason to not Auto-negotiate port speed and duplex? I only know what speed is so if the program would know best about duplexing shouldn't I let PLC take the wheel?

Yes auto is the best, not sure why mine was not other then... too many shots of tequila

I appreciate all the help everyone, as soon as I can get in to implement these ideas I'll give you an update!