BooTP Helper Device

[TimWilborne 108]

So I buddy of mine has been developing this device and sent it to me to evaluate. It takes the place of the software we use to assign Ethernet addresses during startup of a BooTP enabled device. It is extremely easy to use, took me about 5 minutes to learn. I am seeing it being advantageous to maintenance personnel who have been trained in the basic upload/download of programs but may not dabble enough in Ethernet to understand MAC addresses and BooTPs. Also on top of assigning IP Addresses, it seems to be able to read the IP Address of anything. Just the other week I went into a plant and no one had any idea what the IP Address was of a PLC. I could have quickly plugged this device in and read the IP Address. Perhaps a tool like this would be good for me to carry also Actually when I say read the IP Address of anything that seems to include other Ethernet devices such as computers, wireless adapters, etc. Who else would find a product like this useful? Below is the picture of the prototype. It is not for sale.

[BobLfoot 301]

I am thinking it might have an application for us once or twice a year. Have you tested it with devices that you knew where set at "oddball" IP's. 15.X.X.X , 172.Y.Y.Y etc, rather than jsut the STD 196.168.X.X. Price would need to be 300 to 500 US to be interesting. Love to sneak a peak at the OM Manual when you guys write it TIM.

[TimWilborne 108]

Seems to work with anything. As you see in the image below it read the IP address 15.16.17.18 would is definately not a standard IP Address. It also displays the MAC address of the device

[BobLfoot 301]

Thanks TW was just wondering.

[gravitar 3]

I guess I fall into the "occasional dabbler" category :) So if I'm understanding this, the handheld device acts as BootP server, which meant it can dynamically assign IP addresses to the other devices on the network. (is that right?) And, it also has a "Who Listen" function (for you old-school A-B guys) to let you sniff out IP addresses before you plug in and potentially create a conflict. (am I right on that one too?) I guess I'm not sure how practical that would be. Now granted, I know very little about Ethernet, but it seems to me that you would want the BootP server to be a somewhat permanent device on the network, no? And what is the SOP when it comes to plant ethernet networks? Do corporate specs include IP addresses set aside that are reserved for progeamming terminals? Kind-of like how you can walk up to a DH+ or DH485 and be reasonably sure that node 0 is open? Or do you just never know and have to have some other way of verifying that you won't create a node number conflict?

[BobLfoot 301]

I am not sure what Tim and his buddy envision for this tool, but I'll share how'd we'd use it in my plant. First all Ethernet PLC and HMI use fixed IP address so that a power cycle does not knock them into oblivion. We do not have a full time bootp server since one is not needed. Most out of box Ethernet PLC's and HMI's we use come with Bootp turned on so when we replace one we need either to connect serially or with a Bootp server to set it's identity. Once it has an identity we can download the archive code holding the fixed address. When I was a System Integrator I also would have used it to identify lans when I first visited a site.

[TimWilborne 108]

Right now it is more of a point to point device. So if you have a piece of equipment you are unfamiliar with you could plug directly into it and read the IP Address. It can also assign an IP Address to a device. It makes it much easier for those unfamiliar with Ethernet networks to assign IP Addresses. The idea of making it so that you could plug it into a network and read all IP addresses on a network has been toyed with but I have reservations about doing this. Mainly, if a machine is shutdown when you read the IP addresses on the network, it will come up as being available when it is in fact assigned to a machine...The more I have thought about this idea the less I like it. I would disagree with any BooTP server being permanent on a network. IP Addresses should be statically assigned and not rely on any server to assign its address

[paulengr 44]

One extra detail to be aware of. Ethernet does not use IP addresses. Let me repeat...Ethernet does not use IP addresses. Almost every Ethernet device has a unique address burned into it called a MAC address. MAC addresses are assigned by the manufacturer. The exceptions are as follows. Hubs and "dumb switches" can't really initiate any traffic of their own so they don't have MAC addresses. To get around some annoying "features" of certain ISP's, most consumer routers have the capability of "MAC cloning"...you can set the MAC address to match some other device in your network. 192.x.x.x and 10.x.x.x address ranges have been set aside as "nonroutable addresses", among a few other ranges. This means that they are by definition NOT allowed out into the "Internet". By definition whatever you do on the other side of your router with these addresses is acceptable. I'll give our corporate network as an example. We have it split into 10.x.y.z. "x" in this case is plant-specific. For instance, my plant is 3. "y" is currently used at our plant as a designator for specific devices. DHCP PC's on network "1". Phones and UPS's on 2. PLC's and controls devices on 3. As we expand into Ethernet/IP devices we've already talked about making "y" correspond to a specific PLC. "z" gets used in hopefully numeric order but there are some holes. The "z" part of things becomes more or less a free-for-all. We try to be careful to keep close track of which addresses are used so that accidents don't happen. In addition, there is a program called "Angry IP Scanner" which is a free software program which will scan all the addresses in a range looking for responses to a "PING". Hopefully (we follow this religiously) all the devices in your network respond to one of the most basic Internet protocols, "PING". Otherwise, without meticulous record keeping, you could assign 2 devices to the same address. In general, I can't think of an address conflict that has happened yet. Corporate IT then has designated 10.3.1.z as our plant dynamic IP addresses. This is useful from their point of view because because PC's tend to come and go. Setup time is always a foremost concern. Most of the time, their networks are set up as essentially a "faceless mass". The only constants are a few servers which have well defined IP addresses and well defined names (via DNS...dynamic name service...the Internet equivalent of the "phone book"). A DHCP or BootP server which is usually the same one as the name server sits on the network and doles out IP addresses as PC's come and go. This completely avoids the whole issue of figuring out how to allocate addresses by just letting some piece of hardware do it. If the DHCP/BootP server goes down, there is NO WAY for a dynamically addressed PC to communicate if it doesn't have an IP address (various MAC-only level communications excepted). With controls hardware, "setup" is just about as involved whether it's configuring a card's IO or configuring the IP address while you're at it. And the IP addresses themselves are pretty well defined. Using a name server or DHCP/BootP for that matter simply creates yet another point of failure...an extra device. Can you imagine trying to get an IT guy out of bed at 1:30 AM when his DHCP server crashed and just shut the production line down because none of the IO can talk to the PLC? It is possible and reasonable to put DHCP or BootP on a centralized HMI (and only one! no redundancy) if that happens to be the structure of your network since the only reason for having Ethernet is to communicate with the HMI. Otherwise, it's asking for trouble. Ok, but when you first get an "unconfigured" device, there's trouble. You have to first figure out just what the heck kind of address it has to be able to set it up. Devices from Acromag and Banner come with a particular default address. To set these up, I usually just change the address in my PC to correspond to the same subnet long enough to set the correct address and then change back to finish the job. Devices from Digi start out using DHCP or BootP and pick up an address. This could be a serious problem. One choice would be to disconnect my PC off the LAN and run a BootP server so that I can control the address that the device boots up with. Another way is to get the MAC off the sticker on the device and call IT and beg them to look up the IP address that it picked up. A third way is that fortunately Digi has a "discover" program that broadcasts a message which all Digi devices respond to. From the program, you can see all Digi devices regardless of MAC address. Devices from AB can ONLY be configured initially through the serial port. I haven't yet come across one which has only an Ethernet port. Then again...I don't have Ethernet/IP based devices in the plant yet. I'll give you one more example but this time it's a different problem. A contractor installed a burner system in the plant. The burner consisted of a SLC 5/05 and a Panelview. Both used Ethernet (older style AB proprietary Ethernet). I know the addresses were set up and everything is working. Everything is attached to a "dumb" switch. With the PLC, it's fairly easy to extract the address out of it. But what address is the Panelview assigned to? It would be possible to extract the information from the serial port if the serial port had not been damaged somewhere along the way. So I'm stuck with extracting everything out of the Ethernet port. A hub is an Ethernet device that takes any packet received on any port and mirrors it to all of the other ports. A switch is a "smart hub". Ignoring managed switches (which just have a bunch of extra features), a switch starts life out as a hub. BUT, it also monitors the packet traffic. Each packet is marked with a source and a destination. It puts all the source addresses in a table called a port map. The port map contains a port number and the corresponding address. When it sees a packet with a destination address that is in the port map, it sends the packet to that specific port, instead of broadcasting it to all ports. Within a few seconds after restarting, a switch will automatically eliminate all the extraneous traffic that a hub creates. So...it is trivial to monitor all the IP addresses on a hub by plugging a device that passively monitors into another port on the same hub. It is also possible to do this on a switch by erasing the port map. It is possible to flood the switch with bogus packets to overload the port map, or even confuse it by transmitting a duplicate MAC address on a port, but the easiest way to do it is to reboot the switch.

[Contr_Conn 4]

I guess statement above is for SLC and PLC5s only: All A-B Logix Ethernet/IP devices are port configurable and coming out of box with BOOTP enabled. Devices like 1794-AENT, 1734-AENT, 1738-AENT have no serial port and must be configured via Ethernet. Devices like 1756-ENBT, 1769-LxxE also coming with BOOTP enabled, but in addition can be programmed via a backplane. Newer devices have "last octet switches"

[TimWilborne 108]

paulengr - What are you trying to get at in your previous post? Either I got completely lost in it or you seemed to miss so key points of my previous post. Let me see if I can get us back in the right direction on exactly what this device is While not directly related to this thread, this is actually a prime example of the target audience of this device. All AB devices I am aware of are initially configurable through the Ethernet port and I have experience with all AB Ethernet devices except the PLC5s. The reason I mention this is that there are many people who think the same thing when in fact it is possible but the traditional Bootp methods are too complicated. With this you could pull the AB, or any device, out of the box, power it up, plug the BooTP Helper in, assign the IP Address, and your ready to download your program over Ethernet. The process takes less than a minute. I hope this clears some things up. Again, this device is intented to be a point to point device.

[BobLfoot 301]

Still unless I am mistaken the 1794-AENT is running Bootp and will need the device or a server every power cycle until RSlinx or RSNetworx hard codes the address into it right?

[Contr_Conn 4]

Not exactly - Rockwell's BOOTP server can "Disable BOOTP" making IP address static (assign IP first). No Linx or Networx require.

[TimWilborne 108]

Always the one to point out the important details old friend. I have a rough draft of the user manual for the device I'm going to go ahead and send you. To answer your question it is capable of disabling Bootp in a device after it has written the IP Address to make it static

[BobLfoot 301]

Sounds great TW - I'll read it.

[gravitar 3]

This has been a very interesting discussion. I've learned a lot about ethernet. Let me play the devil's advocate again though. Does this device do anything that couldn't be done (or would be highly impractical) in software on a notebook? If I follow the discussion, the target audience might be those that wouldn't be comfortable using a notebook, but I dare say their numbers are dwindling.

[BobLfoot 301]

I sure wish I had TW's device tonight. Heres the whole long story in counterpoint to your devils advocation. 1. Some days ago the power savings gremilin turned off one of our palletizing machines. 2. Tonight the Work Order system spit out that machine as due for a routine electrical PM. 3. I assigned to electricians to complete this task. 4 man hours work usually. 4. When they powered up the machine and it's PLC 5/20C with 1785-ENET the PLC was in error without program. 5. They attempted to connect by ethernet and reload the program, but could not succeed. 6. My options at this point. A. Get out an Ethernet Cross Over Cable, Laptop and use BOOTP Server from Rockwell to set an IP. B. USe Bootp Server with my wireless ethernet card and set an IP in the PLC. C. Find a serial cable and a laptop to use RSlinx / RSlogix 5 to download the program. D. Find my 1784-PCMK Card, Laptop and use RSlinx / RSl;ogix 5 to download a new program. 7. Since the Hard Wire Ethernet Port of my laptop is configured for DHCP and for use with the Office Data Network { a different subnet than the PLC} Option A would involve opeing Network Connections and changing a bunch of settings. Option A is a No Go. 8. Since Corporate IT has established a subnet for all wireless access which is not the PLC access and placed routers between them I cannot use the BootP server from my laptop wireless to reach the PLC. Option B is a No Go. 9. Considering Option C or D and I choose D because DH+ is faster than serial 57.6K beats 2400 baud. And also my PCMK Card is on the top of my automation cables drawer. 10. Now I have to insert the card, add a driver to linx, find out my battery is low on charge to I must find extension chords and etc. All Told it took me just over 75 minutes to get the program back into the PLC. With TW's toy I'd of grapped it and an ethernet cable and been done in 10 minutes. 15 if you count reloading the program from the convenience of my office. Just my humble two cents on this matter.

[Ken Moore 23]

Bob's story is typical. TW, I have a question for you, could this be ported to a PC? Maybe something to consider later on. If you had a piece of software that could sniff out the IP address versus a piece of hardware, I see a market for that as well. You could have three different "packages", the device alone, the software alone, and Both. Just a thought, may not be doable.

[TimWilborne 108]

Ken, I sent an email to the developer to get an answer to your question. While I know nothing about the hardware of this device my initial guess would be yes. But then you would have a whole new bag of concerns such as compatiblity issues with operating systems, hardware, configuring firewalls, not having administrative rights to configure your Ethernet port, etc. However it is a thought, I will let you know what he says Gravitar - Bob's post was a good example of an application for it, does that help?

[Ken Moore 23]

I think it would be a nice thing to have. You approach a PLC with unknown IP address, you already have your laptop with you, because you're going to make a program change, rather than hooking up the device, you just fire up the software. Mfg. cost would be much less, just a CD burner. Piracy would be a concern though.

[TimWilborne 108]

Ken, got a response back from the developer. His thoughts were about the same as mine but he did offer an alternative solution. The devices primary purpose is to assign IP Addresses. A side feature of the device was the ability to read IPs. The thought behind this was when replacing a device, one could read the IP out of the old device, save it to the BooTP Helper, and then write it to the new device. This way there was no chance of a typographical error when entering the IP Address. Also, since I just mentioned it, it has the ability to save the IP Address. Right now it has the storage space for 10 IP Addresses but this could easily be expanded. So if someone were assigning an IP Address, they could log it in this IP history, then when they reported it to the network administrator they could look at the device and know for sure the IP Address they assigned. But anyway, he suggested a product such as Ethereal or Wireshark to capture the packets. You could use this to discover the IP Address

[Ken Moore 23]

Okay, forget the software, sounds like a dead end. Now on to the device features. What is the power supply? I assume some type of battery. Beware, I'm just thinking out loud here and this may not be a worthy suggestion. But how about being able to power the device from a laptop USB port. Not "connected", just powered, sort of like one of those USB powered reading lamps. Example: You go on the road, arrive at customer's facility. You haven't used your device in a while, but have it in your travel bag. You need to use it, and the battery is dead. No problem, you fire up your laptop, plug the power cord into a USB port, and you're back in business.

[BobLfoot 301]

Great Point Ken - Batteries always die jsut before you need them most.

[TimWilborne 108]

The device is powered off of two AA batteries. It has both a real On/Off switch and a power save mode for those who forget to turn the device off. The power save mode does not turn the power off, but like most devices it reduces the power consumption. In this case it reduces it by 95% Thanks again Ken for your input. I have emailed the developer your question, but I'm going to agree that this is a good idea if it is possible. The main problem with it is right now there is no external power connector. I don't know how hard it would be to add one. The device is 5VDC powered, which matches the power output of a USB port. I can't find a good specification on how many mA a USB port can supply. Does anyone know what is typical of a laptop?

[Ken Moore 23]

Did a quick search and I believe the USB standard calls for 100mA as the standard output, but then I found another reference that stated 100 was normal, but upto 500mA was allowed.

[panic mode 246]

If I recall 500mA should be no problem (some USB cables allow tapping power from more than one port in emergency). Btw. I don't think BootP would need more than some 50mA